Archives For Lavoro

Il messaggio che compare a video è poco eloquente, eppure segnala un evidente problema nato durante l’installazione di un software.

KB3172605 and/or KB3161608 are installed in your system. Please uninstall KB3172605 and/or KB3161608 before installing this driver.

Scoprirò in seguito che si tratta di un driver, quello bluetooth per l’esattezza. Una rapida ricerca nei forum di Microsoft ed ecco che salta immediatamente fuori la segnalazione (ce ne sono diverse altre, una in particolare è palese). Non sono il solo a lamentarlo (e fin qui era stata semplice, perché alcuni utenti in ufficio mi avevano detto di aver visto la stessa finestra comparire a tradimento da un paio di settimane), si tratta di un errore che nasce dall’accoppiata Microsoft e Lenovo System Update (in alcuni configurazioni viene anche chiamato “Lenovo – Aggiornamento e driver“, nda).

Lenovo: modificare il BIOS eliminando il Secure Boot (UEFI)

Ho fatto ulteriori ricerche, tutto sembra essere partito a luglio dello scorso anno (Microsoft yanks buggy speed-up patch KB 3161608, replaces it with KB 3172605 and 3172614), si parla -appunto- dei driver bluetooth di Intel. Microsoft ha rilasciato un paio di KB che quasi certamente avrai anche tu sulla tua macchina Lenovo, la quale però tenterà di far installare alla sua utility una nuova versione del driver durante uno dei controlli settimanali pianificati di default, i due KB di Microsoft non possono però coesistere (in questo ordine) con il fix ordinato da Lenovo:

KB3172605, KB3161608 e Lenovo System Update

KB3172605 and/or KB3161608 are installed in your system. Please uninstall KB3172605 and/or KB3161608 before installing this driver.

Partendo dal thread sul forum di Microsoft, pare che qualcuno sia uscito fuori dal tunnel disinstallando le KB manualmente, facendo seguire poi l’aggiornamento del driver così come richiesto (da Lenovo System Update), e lasciando poi che Windows Update facesse nuovamente il suo lavoro (cioè reinstallasse i due KB): answers.microsoft.com/thread/bd93ab91-5d9b-434a-a10e-d6574ca97180.

Prova ora a immaginare circa 500 macchine con lo stesso problema, capisci bene che è letteralmente impensabile intervenire così come riportato dall’utente nel forum. Potrei chiedere al nostro WSUS di rimuovere i due pacchetti e tenerli fermi (per il momento), lasciare che System Update lavori, rilasciare nuovamente i due KB. Ho notato però, dopo diversi test e ricerche, che non tutti i System Update propongono l’aggiornamento come “Critical“, a causa del fatto che alcune macchine non hanno precedentemente aggiornato quel driver (non arrivato quindi alla versione interessata dal problema), rendendo di fatto inutile questo metodo:

KB3172605, KB3161608 e Lenovo System Update 1

Ho scelto quindi di tenere fuori dai giochi il Lenovo System Update, non impedendo certo il suo utilizzo, ma andando a staccare quella che è la schedulazione che viene creata di default su ogni macchina Lenovo (la puoi verificare tu stesso avviando l’applicazione e facendo clic su Pianifica aggiornamenti). Per operare ho scelto di creare una GPO ad-hoc, ti spiego rapidamente come replicare nel tuo ambiente aziendale. Se sei un utente casalingo e vuoi risolvere rapidamente il problema, salta all’ultimo paragrafo dell’articolo :-)

Goodbye System Update

Il Lenovo System Update ha due schedulazioni predefinite che partono al logon dell’utente e una volta a settimana. La seconda è quella che si occupa del download e dell’installazione degli update definiti critici. Teoricamente ogni utente può scegliere di modificare questo comportamento andandolo a variare dall’applicazione stessa (come spiegato poco fa), la mia modifica segue il suggerimento di questo articolo e inibisce all’utente tale possibilità.

Regedit, XML, GPO

Il metodo è sempre lo stesso. La chiave di registro da modificare è la HKLM\SOFTWARE\Wow6432Node\Lenovo\System Update\Preferences\UserSettings\Scheduler (su un sistema a 32 bit si salterà la \Wow6432Node\), il valore è lo SchedulerAbility, che cambierà da YES a NO.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Lenovo\System Update\Preferences\UserSettings\Scheduler]
"SchedulerAbility"="NO"

[HKEY_LOCAL_MACHINE\SOFTWARE\Lenovo\System Update\Preferences\UserSettings\Scheduler]
"SchedulerAbility"="NO"

La chiave, trasformata in XML, darà questo risultato (non è indentato, lo so):

<?xml version="1.0" encoding="UTF-8"?>
<Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Disable Lenovo System Update"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="HKEY_LOCAL_MACHINE"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="SOFTWARE"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Wow6432Node"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Lenovo"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="System Update"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Preferences"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="UserSettings"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Scheduler"><Registry clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}" name="SchedulerAbility" status="SchedulerAbility" image="7" changed="2017-01-16 16:01:08" uid="{8D71093F-6362-7087-5ED8-94EDBD7719C6}"><Properties action="U" displayDecimal="0" default="0" hive="HKEY_LOCAL_MACHINE" key="SOFTWARE\Wow6432Node\Lenovo\System Update\Preferences\UserSettings\Scheduler" name="SchedulerAbility" type="REG_SZ" value="NO"/><Filters/></Registry></Collection></Collection></Collection></Collection></Collection></Collection><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Lenovo"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="System Update"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Preferences"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="UserSettings"><Collection clsid="{53B533F5-224C-47e3-B01B-CA3B3F3FF4BF}" name="Scheduler"><Registry clsid="{9CD4B2F4-923D-47f5-A062-E897DD1DAD50}" name="SchedulerAbility" status="SchedulerAbility" image="7" changed="2017-01-16 16:01:08" uid="{0D58379E-C99A-0B72-264C-4143F8AD0680}"><Properties action="U" displayDecimal="0" default="0" hive="HKEY_LOCAL_MACHINE" key="SOFTWARE\Lenovo\System Update\Preferences\UserSettings\Scheduler" name="SchedulerAbility" type="REG_SZ" value="NO"/><Filters/></Registry></Collection></Collection></Collection></Collection></Collection></Collection></Collection></Collection>

A questo punto è tutto in discesa. Dal Group Policy Management Editor crea la nuova GPO e naviga in Computer ConfigurationPreferencesWindows SettingsRegistry. Copia il codice XML che vedi qui sopra e incollalo direttamente nella finestra del Group Policy Management Editor (nella parte destra, quella del Registry), otterrai un risultato simile a quello in figura :-)

KB3172605, KB3161608 e Lenovo System Update 2

A questo punto potrai assegnare la GPO ai domini che ti interessano (mantieni il filtro di sicurezza su Authenticated Users). Non appena questa andrà ad applicarsi ai PC gestiti, nessuno più lamenterà l’anomalia (e le operazioni schedulate spariranno da Windows).

Come lo risolvo sul mio PC di casa?

Scarica la chiave di registro che trovi sul mio spazio box: app.box.com/s/v4xhf99dx8lxjbi5c0qir2l4gzhtgvpo.

Fai doppio clic sul file scaricato, conferma la modifica delle informazioni di registro e verifica che ora il tuo Lenovo System Update non effettui controlli e installazioni autonome (puoi controllarlo aprendo l’applicazione e facendo clic su Pianifica aggiornamenti, che ora dovrebbe essere completamente disabilitato).

KB3172605, KB3161608 e Lenovo System Update 3

Inutile dirlo, ma è chiaro che il mio è un work-around e non una soluzione al problema che spero Lenovo possa gestire in qualche maniera, basterebbe far saltare fuori una soluzione per mettere a posto l’anomalia e nulla più, nulla che poi non si possa gestire tramite GPO o un sistema di distribuzione software (almeno spero). Io continuerò a tenermi aggiornato tramite forum di Microsoft e Lenovo, aggiornerò questo articolo in caso ci fossero novità.

Buon lavoro! :-)

È un problema che ho affrontato qualche tempo fa e che inizialmente mi ha dato un po’ di grattacapi, salvo poi trovare casi molti simili che mi hanno aiutato a risolvere l’anomalia. Il disco di un PC si satura e la colpa è della cartella C:\Windows\Temp, invasa da file senza estensione, dal nome che comincia sempre per cab_. Perché accade? Il problema viene generato da una installazione di alcuni aggiornamenti (da Windows Update) evidentemente non andata a buon fine, non del tutto almeno, nonostante la schermata preposta di Microsoft dica che tutto va bene.

Windows: l'invasione dei CBSPersist e dei cab_ (C:WindowsTemp)

Facendo un po’ più di attenzione, si scopre che in realtà di cartella che occupa spazio ce n’è un’altra. Teoricamente dovresti trovare anomala anche la C:\Windows\Logs\CBS, all’interno della quale dovresti trovare dei file CAB veri, e un file di log dalla dimensione decisamente robusta (CBS.log). L’anomalia parte proprio da qui. Partiamo con le opportune presentazioni (recuperate con una semplice ricerca):

CBS stands for “Component-Based Servicing” and it basically is the way components get installed and uninstalled during updates. It is the reason you see “Stage 1”, “Stage 2”, and “Stage 3” during the Service Pack 1 install (for example). “Stage 2” and “Stage 3” exists for the registry keys and files that are normally locked during regular operation.

Tutto chiaro? Un log in cui ogni aggiornamento di Microsoft va a scrivere e tiene traccia di ogni movimento. Un log destinato –per forza– a crescere, e che per un comportamento assolutamente standard va a ruotare, sospendendo la scrittura, finendo in un CAB che ne riduce (di parecchio) la dimensione, e infine ne prepara uno nuovo in cui tornare a scrivere, per poi ricominciare il giro ancora e ancora.

Se per qualsivoglia motivo questo procedimento non fila liscio, il CBS.log diventa più grande del previsto, ingestibile e –soprattutto– impossibile da mettere in un CAB nei tempi previsti. Il risultato? Cartella Temp di Windows piena di tentativi falliti di comprimere quel log, cartella CBS che si ingigantisce.

Diverse le fonti dove ho trovati informazioni in merito e persone capitate nello stesso vortice, ne ho selezionate tre che mi hanno aiutato:

Riepilogando, tutto questo può accadere in qualsiasi momento e -in base alla capacità del disco e lo spazio libero da poter sfruttare- potresti accorgertene a mesi (o forse anni) di distanza. Io ho scoperto di essere soggetto al problema solo perché un utente ha lamentato poco spazio libero e mi ha fatto scoprire l’anomalia. Le operazioni da affrontare per resettare il procedimento di scrittura e archiviazione del CBS.log è questo:

  • Fermare il servizio Windows Update.
  • Rinominare la cartella della Software Distribution (C:\Windows\SoftwareDistribution).
  • Cancellare ogni file in C:\Windows\Temp (ovviamente ignorando quelli in uso e che faranno comparire il classico errore a video di impossibilità di cancellazione, nda).
  • Riavviare il servizio di Windows Update.
  • Fermare il servizio Trusted Installer.
  • Cancellare ogni file in C:\Windows\Logs\CBS.
  • Riavviare il servizio Trusted Installer.
  • Forzare una ricerca aggiornamenti di Windows Update (direttamente via prompt).

Visto che questa cosa potrebbe capitare ad altri client in futuro, ho pensato di tradurla in codice batch, da dare in pasto anche al Kace di Dell (tanto per fare un esempio). Il tutto intervallando alcuni secondi di pausa prima di poter eseguire l’operazione successiva (dando così modo al client di non saltare alcun passaggio fondamentale):

sc stop wuauserv
ping 127.0.0.1 -n 7 > NUL
cd \Windows\
move SoftwareDistribution SoftwareDistribution_old
del /S C:\Windows\Temp\* /Q
FOR /D %%p IN ("C:\Windows\Temp\*.*") DO rmdir "%%p" /s /q
sc start wuauserv
rd /S /Q C:\Windows\SoftwareDistribution_old
sc stop TrustedInstaller
ping 127.0.0.1 -n 7 > NUL
del /S C:\Windows\Logs\CBS* /Q
sc start TrustedInstaller
ping 127.0.0.1 -n 5 > NUL
wuauclt.exe /detectnow

Così facendo ho risolto il problema e liberato spazio sul disco. Ho fatto queste modifiche al sistema mesi fa e il problema non si è più presentato (a me, ma anche ad altri utenti che nel frattempo ho rilevato nella nostra rete).

Facile (soprattutto se si ha un aiuto nella software distribution) fare un’analisi all’interno della rete aziendale e cercare le macchine che soffrono la stessa anomalia ma che ancora non hanno saturato il disco, basterà cercare nella cartella C:\Windows\Temp una forte presenza di cab_, così da portarsi avanti ed evitare che il problema si presenti agli occhi dell’utente.

Estote parati (cit.).

G

Abbiamo già trattato l’argomento, ci torno sopra perché –dopo gli ultimi aggiornamenti del software di Manage Engine– l’aspetto di ServiceDesk è decisamente cambiato (in meglio) e mi ha fatto nascere una nuova esigenza, in realtà nell’aria già da tempo. Si tratta della possibilità di fare un refresh manuale della pagina.

Nulla di particolare sotto al sole, sia chiaro, giusto un’aggiunta che può tornare utile avere a portata di clic oltre che di tastiera (in quel caso basta un F5). Ho scelto di inserire il nuovo pulsante subito prima del “Close“.

ServiceDesk: una toolbar personalizzata sempre in vista 1

Per lanciare un aggiornamento della pagina ho utilizzato un semplice window.location.reload(), che si integra quindi nel codice di un nuovo pulsante. Per poter far stare tutto su una sola riga, ho aumentato le dimensioni (larghezza) della toolbar, portando il valore a 310 pixel. Nello specifico, questo è il codice del nuovo pulsante:

// REFRESH
'<input type="button" title="Refresh" class="formStylebutton" style="width:auto;height:18" onclick="window.location.reload()" value="Refresh" name="refreshButton"> ' +

Ho rilasciato perciò una nuova versione del CustomScripts.js, disponibile come sempre su Gist, te la propongo qui di seguito per comodità:

Ne approfitto per ricordarti che lo script dovrà essere inserito in [TUOSERVERSDP]\ServiceDesk\custom\scripts, e che forzando un aggiornamento della pagina (del tuo HelpDesk) dovresti notare subito la novità, senza la necessità di riavviare il software.

Per commenti, nuove idee o suggerimenti riguardo possibili miglioramenti del codice attualmente proposto, l’area commenti è a tua totale disposizione!

G

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!

Che in realtà non è proprio il messaggio completo che compare a video, si tratta di qualcosa che dovrebbe assomigliare molto più a questa immagine (anche su sistemi in italiano, poiché richiamata da programmi installati probabilmente in inglese):

The program can't start because api-ms-ecc

Nel mio specifico caso si è trattato di un errore comparso in occasione dell’apertura del File Manager di 7-Zip, ho trovato una discussione in merito proprio nel forum di supporto, illuminante direi.

Try to google that error message. There are some suggestions how to fix it.
For example, from adobe site:
On Windows 7 SP1 computers with Office 2016, the following error message appears when Acrobat launches:
“The procedure entry point ucrtbase.terminate could not be located in the dynamic link library api-ms-win-crt-runtime-l1-1-0.dll.”
This issue is related to the Office 2016 installation, as it does not always install the VS2015 runtime on Windows 7 computers.
A workaround is to install the VS2015 runtime manually. Once the runtime is installed, Acrobat should launch without this error message.
To the top
Solution: Install Microsoft Visual C++ (x64) runtime
Download Microsoft Visual C++ 2015 runtime from Microsoft Download Center. Install it by double-clicking the downloaded file – vc_redist.x64.exe (on 64-bit computers) and vc_redist.x86.exe (on 32-bit computers).

La risoluzione è quindi semplicissima: installa il Microsoft Visual C++ runtime, per sistemi a 32 o 64 bit. Si trovano entrambi (dovrai solo scegliere l’architettura in base a quella di installazione del tuo sistema operativo) all’indirizzo microsoft.com/it-it/download/details.aspx?id=48145.

Una volta installato il pacchetto, noterai l’immediata risoluzione dell’anomalia. Ora nessun programma (che fa uso del runtime) dovrebbe dare ulteriori errori.

Oggi si torna a parlare di ServiceDesk e di un piccolo particolare che non apprezzo particolarmente nelle sue ultime versioni: la toolbar bassa che propone i comandi rapidi per lavorare sui ticket compare esclusivamente se gli stessi superano un certo numero, costringendo il tecnico a uno scroll verso il basso, parlo di questa:

ServiceDesk: una toolbar personalizzata sempre in vista

Ho provato a chiedere lumi al forum della Community, per capire se ci fosse la possibilità di ritoccare qualcosa nella configurazione del software, e permettermi di tenere quella toolbar sempre visibile. Ho ricevuto un due di picche e nello stesso momento un suggerimento davvero ottimo: forums.manageengine.com/topic/show-bottom-toolbar, cito di seguito

Create your own toolbar.
Check:  http://sdpadmins.pl/49/dodajemy-cos-od-siebie-do-sdp-customscripts/#more-49

Te la facilito (il sito web è in polacco e ho usato un Google Translate per fare il lavoro sporco): qualcuno in ManageEngine ha ben pensato di includere la possibilità di richiamare uno script personalizzato (JS) per iniettare live alcune modifiche all’interfaccia principale, secondo necessità degli utilizzatori del prodotto. Cosa vuol dire? Vuol dire che con qualche riga di codice è stato possibile ottenere comunque il risultato sperato, nonostante non sia quello previsto da fabbrica. Ho creato una toolbar personalizzata e con posizione fixed in base alle indicazioni dell’utente che mi ha indicato la retta via.

Un piccolo telecomando di collegamenti rapidi posto in basso a destra nella schermata di ServiceDesk Plus ti permetterà di richiamare le funzioni più utili dello stesso, senza la necessità di avere 50 ticket nella stessa schermata, evitando così i molteplici movimenti e clic di mouse per arrivare allo stesso risultato tramite i pulsanti originali del software. Ho caricato il risultato funzionante su Gist:

Lo script è in grado di riconoscere l’URL attuale e far comparire la barra esclusivamente durante la visualizzazione dei ticket (quella tabellare, WOListView.do), la ricerca (SeachN.do) e la vista tabellare in seguito a chiusura di un ticket (CompleteRequest.do), il tutto sfruttando un semplice array che dietro un ciclo for verificherà ogni volta il contenuto dell’URL visitato nel momento dell’esecuzione dello script.

Un tocco di abbellimento (si fa quel che si può) via CSS, poi una serie di funzioni secondo me fondamentali, riproducendo esattamente ciò che fanno i pulsanti della toolbar proposta da fabbrica: Pick Up del ticket, Merge, Delete e Close. Ho incluso anche l’Edit ma l’ho tenuto commentato, non è il tipo di edit che mi interessa (richiama quello multiplo, non quello del ticket specifico) e probabilmente lo modificherò in futuro, non necessario esclusivamente perché viene già proposto un pulsante di Edit in corrispondenza di ogni singolo ticket riportato in visualizzazione tabellare.

Per poter funzionare, questo codice andrà salvato in un file nominato CustomScripts.js, che dovrà trovarsi nella cartella [TUOSERVERSDP]\ServiceDesk\custom\scripts. Non è necessario riavviare il servizio relativo a ServiceDesk Plus, ti basterà fare un aggiornamento forzato della pagina web visitata in quel momento (CTRL+R o Shift + F5, in base al browser utilizzato).

Come ogni cosa da me realizzata o ritoccata, non è certo priva di errori e può essere sicuramente migliorata. Se hai proposte o critiche, l’area commenti è a tua totale disposizione.

Buon lavoro!