Archives For Command

Ti è mai capitato di preparare una macchina “template” da catturare e clonare su diverse altre macchine dello stesso modello? Qui continuamente, ed è tutto ciò su cui si cerca di basare il rilascio di nuove postazioni. Avere un solo modello Desktop e uno laptop (o comunque un numero quanto più limitato) aiuta a gestire meglio il parco macchine aziendale, è risaputo ed è una pratica di quelle buone, da cercare di mantenere il più possibile nel tempo.

Tralasciando però quella che è la pippa mentale relativa alla teoria delle buone pratiche, passiamo al succo dell’articolo e al problema specifico da risolvere: un SysPrep fallito, con tanto di messaggio di accompagnamento simile (in realtà potrebbe essere identico) a quello riportato nel titolo dell’articolo.

Microsoft Windows

Di motivi per far fallire un SysPrep ne esistono diversi, ma un paio sono quelli più comuni e sono quelli a cui possiamo fare riferimento insieme (con relativa soluzione), e onestamente non ho idea del perché io abbia lasciato nel dimenticatoio questo articolo (la bozza era del 2014, fa un po’ te). Provo a dargli una svecchiata, magari è la volta buona che va in pubblicazione :-)

Hai finito le cartucce

Con Windows 7, contrariamente a Windows 10, avevi a disposizione un massimo di 3 Rearm di sistema (il Rearm serviva a terminare un intervallo di utilizzo di sistema privo di attivazione, cominciandone uno nuovo e permettendoti di estendere il tuo periodo “di prova” di Windows, ciò è alla base dei periodi trial di Microsoft tutt’oggi, sia per Windows che per Office). Questo era ciò che nel libro di teoria potevi trovare pressoché ovunque, ma che come ogni medaglia, dava il meglio di sé voltando la prima faccia. Un SysPrep comprendente un parametro di Rearm, andava a dare un’occhiata a quello che era il contatore di sistema, che puoi facilmente richiamare ancora oggi eseguendo il comando slmgr.vbs -dlv (come suggerito anche nel forum di Microsoft):

A fatal error occurred while trying to sysprep the machine

Lo screenshot qui sopra fa riferimento a quel vecchio sistema 7 che dovevo mandare in SysPrep nel 2014, e che riportava uno zero in corrispondenza della voce “Numero di ripristini di Windows rimanenti“, era proprio lui a impedirmi di portare a termine il mio compito. Come si aggirava e si aggira tutt’oggi (se hai ancora a che fare con Windows 7, nda) l’ostacolo? Semplice. Si va a modificare la chiave di registro che ne controlla il contatore.

Per farlo però, ti occorre mandare in recovery il sistema, premendo F8 durante l’avvio dell’OS e selezionando la voce relativa alla partenza avanzata di Windows (Advanced Boot Options), quella che ti permette di avere un prompt dei comandi. Dal prompt dovrai semplicemente fare tre operazioni relative al registro di Windows:

reg load HKLM\MY_SYSTEM "%~dp0Windows\System32\config\system"
reg delete HKLM\MY_SYSTEM\WPA /f
reg unload HKLM\MY_SYSTEM

Se la modifica va a buon fine, potrai riavviare la macchina e rilanciare il comando slmgr.vbs -dlv per verificare che il contatore sia tornato a mostrare un numero di possibili Rearm positivo. Se Windows dovesse richiederti il Product Key, ignora il passaggio e recuperalo in seguito, anche via prompt dei comandi, sempre passando per il slmgr.vbs. Il comando completo per passare un Product Key al sistema è slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX dove, chiaramente, dovrai andare a sostituire la serie di “X” con il codice in tuo possesso. Se non lo hai, utilizzane uno a tempo (scadono entro un mese):

  • Windows 7 Ultimate: D4F6K-QK3RD-TMVMJ-BBMRX-3MBMV
  • Windows 7 Professional: HYF8J-CVRMY-CM74G-RPHKF-PW487
  • Windows 7 Home Premium: RHPQ2-RMFJH-74XYM-BH4JX-XM76F
  • Windows 7 Home Basic: YGFVB-QTFXQ-3H233-PTWTJ-YRYRV
  • Windows 7 Starter: 7Q28W-FT9PC-CMMYT-WHMY2-89M6G

A tutto questo c’è un’alternativa che ti permette di bypassare il contatore dei Rearm e fare SysPrep perdendo un po’ meno tempo. È riportata in un articolo che mi è tornato molto utile in passato (questo: mickitblog.blogspot.it/2011/08/fatal-error-occurred-while-trying-to.html), questo il riassunto:

  • Nel file Unattend.xml cerca e cancella il parametro skiprearm=1
  • Nel regedit, naviga in HKLM\SYSTEM\Setup\Status\SysprepStatus, quindi cerca e imposta GeneralizationState a 7
  • Da un prompt dei comandi, lancia prima un msdtc -uninstall, fai seguire poi un msdtc -install
  • Torna nel regedit, naviga in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform, quindi cerca e imposta il valore SkipRearm a 1
  • Togli il cavo di rete dalla macchina (e disconnettila dal WiFi, se connessa)
  • Rilancia il SysPrep.

E se invece è un problema di profilo?

Può capitare anche questo, ed è il secondo caso più comune. Hai preparato il sistema, sei partito da un’immagine già esistente, da fondamenta già gettate e apparentemente ben solide ma, all’ultimo minuto, il SysPrep va in errore per cause apparentemente sconosciute, strane da interpretare. Potresti scoprire che in realtà si tratta di un vecchio profilo locale rimosso, ma rimasto “appeso” nel registro di sistema. Se ne parlava in un vecchio thread nel forum, tra le possibili soluzioni: social.technet.microsoft.com/Forums/windows/en-US/2aa9466d-a203-4f3e-80d9-f1ae6d11f6c5/sysprep-failed-at-microsoftwindowsshellsetup?forum=w7itproinstall

È ancora una delle vie d’uscita poco considerate, ma che possono toglierti le castagne dal fuoco. Avvia il regedit, naviga in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList. Noti nulla di strano? Se qui compare un profilo non più presente sulla macchina, la CopyProfile prevista dal tuo file XML unattend non potrà mai andare a buon fine, generandoti l’errore a video.

Cancella la chiave di registro (intera) relativa al profilo non più esistente. Riprova ora il SysPrep, molto probabilmente andrà a buon fine e tu potrai concludere il lavoro.

Cosa dice Microsoft

Raccoglie qualche riferimento all’interno di un documento ufficiale di Support, che tu stesso puoi leggere puntando il browser a support.microsoft.com/en-us/help/929828/an-error-message-occurs-when-you-run-sysprep-generalize-in-windows-vis, probabilmente però questo non riuscirà a dare risposta alla tua domanda e difficoltà, ma questa è un’altra storia.

Ciò che mi auguro è che l’articolo, rispolverato e rimesso più o meno in ordine, possa darti realmente una mano in caso di difficoltà con questo ottimo strumento che è SysPrep.

Buon lavoro!

Condividi l'articolo con i tuoi contatti:

Sembra che ci siano dei problemi con le ultime release di Office 2016 (ProPlus, la versione installabile offline per chi ha un abbonamento Office 365) relativi alla possibilità di scalare di versione tramite il solito OfficeC2RClient.exe, quello di cui ti ho parlato già in passato (qui: gioxx.org/2016/03/17/office-365-proplus-2016-modifica-versione-installata).

OS X: da Microsoft Office 2011 a 2016, cosa disinstallare

Stiamo conducendo dei test in ufficio, riguardanti un possibile problema dell’ultima versione di Microsoft Access. Una incompatibilità con un database già esistente e che funzionava perfettamente fino a una release fa (la 1705 Build 8201.2102 del 13 giugno scorso). La cronologia delle versioni è disponibile su support.office.com/en-us/article/Version-and-build-numbers-of-update-channel-releases-ae942449-1fca-4484-898b-a933ea23def7#bkmk_bydate, e come tu stesso potrai notare, la 1706 è quella del 28 giugno, la build “problematica” è la 8229.2073).

Provando a richiamare l’eseguibile di OfficeC2RClient.exe, si ottiene un popup fin troppo chiaro. Office è aggiornato, l’operazione è quindi conclusa lì, ignorando la richiesta originale:

OfficeC2RClient.exe /update user updatetoversion=16.0.8201.2102

Office 16.0.8229.2073 (1706): problemi di rollback

Come non bastasse, provando a disabilitare i nuovi aggiornamenti dall’interfaccia grafica (Account di OfficeOpzioni di aggiornamentoDisabilita aggiornamenti), la modifica non sortisce alcun risultato, a prescindere che il programma venga avviato da utente semplice o da amministratore. Un bel quadretto complessivo, utile.

Il tutto viene discusso nella community di Microsoft, uno tra i tanti thread lo trovi all’indirizzo social.technet.microsoft.com/Forums/office/en-US/684e7f2d-560b-480a-8c8d-cc6f6fcbca28/office-2016-updates-roll-back?forum=Office2016ITPro, allo stato attuale non c’è una risposta risolutiva.

E quindi?

E quindi non c’è alternativa. Se ti serve tornare indietro a una precedente versione, non puoi fare altro che disinstallare completamente il prodotto e fare un download tramite C2R puntando direttamente a ciò che ti serve. Parti con disinstallazione e riavvio macchina. Io ti consiglio di accelerare i tempi e passare dal tool ufficiale che si occupa di tutto: aka.ms/diag_officeuninstall.

Una volta fatto, scarica il tool di deploy C2R da microsoft.com/en-us/download/details.aspx?id=49117, scompattalo (basta eseguirlo, ci pensa lui) e sostituisci il file di configurazione XML che permette scaricamento dati e installazione a bordo PC. Se vuoi, questo è file XML già pronto che puoi usare per prenderti i dati dai server di Microsoft:

<Configuration>
 <Add OfficeClientEdition="32" Channel="Current" Version="16.0.8201.2102 ">
 <Product ID="O365ProPlusRetail">
 <Language ID="it-it"/>
 </Product>
 </Add>
 <Updates Enabled="TRUE" Channel="FirstReleaseDeferred"/>
 <Display Level="None" AcceptEULA="TRUE"/>
 <Logging Name="OfficeSetup.txt" Level="Standard" Path="%temp%"/>
 <Property Name="FORCEAPPSHUTDOWN" Value="TRUE"/>
 <Property Name="PinIconsToTaskbar" Value="FALSE"/>
</Configuration>

Il resto è storia già conosciuta: setup.exe /download per scaricare i dati, setup.exe /configure quando hai terminato il download e sei pronto a eseguire l’installazione. La versione 16.0.8201.2102 pesa 1,86 GB su disco.

Una volta installato, ricorda di disattivare gli update, se ti serve.

Update

A tal proposito, non lo avevo incluso nell’articolo originale, se il pulsante per disabilitare gli aggiornamenti via interfaccia grafica di Office non ti dovesse funzionare, puoi sempre copiare, incollare ed eseguire questa stringa in un prompt dei comandi di DOS.

REG ADD HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Office\16.0\common\officeupdate /v enableautomaticupdates /t REG_DWORD /d 0 /f

Questo ti permetterà di andare a modificare la chiave di registro che obbliga Office a non aggiornarsi.

 

Condividi l'articolo con i tuoi contatti:

È 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.
  • Cancellare ora la cartella SoftwareDistribution precedentemente rinominata, non serve più, Windows Update provvederà a crearne una nuova in totale autonomia (dovrebbe già averlo fatto in fase di avvio del servizio, come da passaggio precedente).
  • 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

Update

Ho aggiunto il passaggio relativo alla cancellazione della cartella SoftwareDistribution rinominata (nella lista delle operazioni manuali da compiere), come da commento di GDB, che ringrazio per avermelo fatto notare.

Condividi l'articolo con i tuoi contatti:

Uno di quei problemi che, a lanciare una ricerca nei forum di Microsoft, escono quasi più risultati di una equivalente azione mirata a conoscere le misure di una showgirl. In seguito all’aggiornamento a Office 2016 (anche se non immediato), in ufficio abbiamo iniziato a notare una quantità di richieste di login superiore al dovuto.

Ora, che ogni tanto scada l’accesso al proprio account Office 365, ci può assolutamente stare. Che questo diventi però un’abitudine a ciascuna chiusura e riapertura programma (anche a distanza di pochi secondi) non è normale.

Office 2016: prima di partire e primi passi con ...

Ho provato a fare un reset dell’installazione, ho provato a cambiare profilo, ho cercato riferimenti in merito, nulla di fatto. Nei forum Technet c’è molta confusione, troppe informazioni spesso sbagliate. Sono arrivato a qualcosa di concreto, ho trovato finalmente un articolo che riproduce l’errore e lo risolve (questo: meyermed.com/2014/02/fixing-the-error-onenote-needs-a-password-to-sync-this-notebook-click-here-to-enter-your-password) e ho risolto l’anomalia sulla mia postazione, memorizzando le credenziali di Outlook ancora una volta e lasciando che OneNote tenesse la cache dell’autenticazione nel Gestore Credenziali di Windows.

Office 365: continue richieste di login da OneNote (e non solo) 1

Per poter replicare rapidamente la soluzione su più postazioni, ho scritto qualche riga di batch così da poterla dare in pasto al Kace di Dell e lanciarla agilmente ogni volta che ne ho bisogno. Funziona su Windows 7, 8.1 e anche 10:

cmdkey.exe /list > "%TEMP%\CredMan.txt"
findstr.exe MS.Outlook* "%TEMP%\CredMan.txt" > "%TEMP%\CredMan_Tokens.txt"
findstr.exe MicrosoftOffice15_* "%TEMP%\CredMan.txt" >> "%TEMP%\CredMan_Tokens.txt"
findstr.exe MicrosoftOffice16_* "%TEMP%\CredMan.txt" >> "%TEMP%\CredMan_Tokens.txt"
FOR /F "tokens=1,2 delims= " %%G IN (%TEMP%\CredMan_Tokens.txt) DO cmdkey.exe /delete:%%H
del "%TEMP%\CredMan.txt" /s /f /q
del "%TEMP%\CredMan_Tokens.txt" /s /f /q

Traducendolo in soldoni, il batch esporta le credenziali attualmente presenti nel Gestore Credenziali di sistema, ricerca tutto ciò che riguarda Office 2013 (15), 2016 (16) e Outlook. Per ciascuna corrispondenza andrà a rimuovere quel riferimento in Windows. Al termine –ovviamente– cancellerà l’esportazione precedentemente eseguita.

Ho creato un pacchetto eseguibile del batch sopra riportato e l’ho caricato sul mio spazio Box, nel caso tu voglia scaricarlo direttamente: app.box.com/s/siespaz9aqi3vzowetsjnovnw15z5eoi.

Dopo aver eseguito la pulizia, come già detto, dovrai autenticarti nuovamente su Outlook ma anche su OneNote se fai uso di Notebooks salvati su OneDrive personale o business (non servirà farlo su Excel o Word, hai già attivato la suite Office, non serve fare altro). Salvo errori, se l’autenticazione andrà a buon fine, ricompariranno le voci relative alle credenziali Office 16 nel gestore Windows, queste possono (e devono) essere lasciate lì.

Cheers.

Condividi l'articolo con i tuoi contatti:

sourcecode-vbscriptSai già come funziona, di tanto in tanto apro il cassetto degli attrezzi, utilizzo uno script e poi penso che potrebbe essere interessante per qualcun altro sul web, quindi decido di condividerlo con te che sei dall’altra parte del monitor e che stai forse svolgendo un mestiere simile al mio.

Qualche tempo fa ho rimaneggiato un po’ di codice per realizzare un piccolo VBScript che fosse in grado di ritoccare la descrizione di un PC da remoto, senza che l’utente si accorga di nulla, collegandomi in maniera amministrativa grazie alla rete di dominio.

Da un’idea e realizzazione originale di Rob Dunn (il suo sito web non esiste più, nda), il codice qui di seguito mostra un popup a video che legge l’attuale descrizione di un PC (raggiunto tramite hostname o IP) e permette contestualmente di modificarla.

' PC Description Changer per Windows Xp+
' GSolone 2015 v 0.3
' Basato su script originale di Rob.Dunn (www.theitoolbox.com)
' Ultima modifica 17122015
'
' - accetta da prompt dei comandi il nome macchina (o IP) da raggiungere (es. PCDescription.vbs 127.0.0.1)
' - Windows XP e 2003 richiedono un riavvio macchina per poter mostrare poi la description corretta.
' - il servizio di remote registry deve essere attivo e occorre anche avere le permission WMI)
' - lo script tronca oltre i 48 caratteri forniti come testo della descrizione PC
'
' LO SCRIPT VA ESEGUITO COME AMMINISTRATORE MACCHINA O DI DOMINIO!

Dim strDescription, strComputer, reg, objRegistry
Dim ret, msg, ValueName 

Const HKLM = &H80000002

if WScript.Arguments.Count = 0 then
    'Richiesta IP o hostname macchina da modificare
    strComputer = InputBox("PC Description Changer (Win Xp +)" & vbCR & vbCR & "VA ESEGUITO COME ADMIN LOCALI O DI DOMINIO!" & vbCR & vbCR & "Inserisci il nome macchina o indirizzo IP da raggiungere (vuoto o clic su Annulla per uscire dallo script)" & vbCR, "PC Description Changer", "W7-TEST")
else
    'Se l'indirizzo IP / Hostname mi è stato passato da riga di comando, posso procedere direttamente
    strComputer = Wscript.Arguments(0)
end if

if strComputer = "" then wscript.quit

on error resume next

Set reg = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

if err.number <> 0 then 
  msgbox "Problemi di connessione al database WMI di " & strComputer & ".  Verifica che il PC sia acceso e che tu abbia tutti i permessi per poter effettuare l'operazione",16,"Errore di connessione a '" & strComputer & "'" 
  wscript.quit  
end if

on error goto 0 

Set objRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2").ExecQuery("Select Description FROM Win32_OperatingSystem")


For Each object In objRegistry
    strDescription = object.Description 
Next 

value = inputbox("Inserisci una nuova descrizione per '" & strComputer & "' (o fai clic su Annulla per terminare lo script):","PC Description Changer",strDescription)

If value = strDescription then wscript.quit

key = "SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters"
ValueName = "srvcomment"

If Len(Value) > 48 Then Value = Left(Value, 48)
ret = reg.SetStringValue(HKLM, key, ValueName, value)

if ret <> 0 then msgbox "Aggiornamento remoto fallito."

All’interno del codice c’è anche qualche rapida istruzione (in parte riproposta a video) per guidarti all’uso o a capire cosa può andare storto. Ricorda che il servizio di Remote Registry deve essere attivo sulla macchina di destinazione (e l’account che lancia lo script deve avere i permessi per amministrarla, vale quindi lanciarlo da un prompt dei comandi elevato), altrimenti si incorre in popup di errore come questo:

VBS: cambiare la descrizione di un PC da remoto

Tutti i test sono stati condotti su Windows 7, 8.1 e 10. In passato l’ho usato anche per macchine XP senza battere ciglio, spero però per te che tu non abbia più quel SO in giro ;-)

Per dubbi o chiarimenti, citofonare nell’area commenti.

Cheers.

Condividi l'articolo con i tuoi contatti: