Durante il provisioning di una VM Windows Server 2022 con SCVMM su host Hyper‑V 2019, la fase di personalizzazione può bloccarsi per un’ora e andare in timeout. In questa guida trovi una procedura completa, concreta e testata per individuare la causa e ripristinare un deploy affidabile.
Scenario e sintomi del blocco
Il contesto tipico è il seguente: ambiente System Center Virtual Machine Manager con library server e database SQL correttamente registrati, host Hyper‑V con sistema operativo datacenter o standard versione duemiladiciannove, template di sistema operativo basato su Windows Server duemilaventidue. Alla creazione della VM da template, il job VMM procede fino alla fase di personalizzazione del sistema operativo e rimane fermo su uno step indicato come “Step 1.7” (o denominazioni simili come “Customize operating system”), per circa sessanta minuti; allo scadere, il job segnala timeout.
Questo comportamento è generalmente legato a una di queste condizioni:
- Errore o incompletezza nella generalizzazione del template con Sysprep.
- Impostazioni non coerenti nel Guest OS Profile di VMM (edizione, chiave, dominio, rete, NIC rename).
- Impossibilità di stabilire la comunicazione WinRM dal VMM verso il guest per applicare le configurazioni.
- Incompatibilità o prerequisiti non soddisfatti tra versioni di VMM, aggiornamenti e host Hyper‑V.
Come funziona la personalizzazione di VMM
Capire cosa fa VMM in quella fase aiuta a localizzare il guasto. In sintesi:
- VMM clona il VHDX o istanzia il differencing disk dal template.
- VMM inietta o associa un file
unattend.xmlcostruito dal Guest OS Profile selezionato. - La VM effettua il primo avvio, entra nella fase di specialize di Windows, applica il contenuto di
unattend.xml(nome macchina, product key, lingua, fuso orario, eventuale join al dominio, configurazione rete). - Quando il sistema è avviato, VMM tenta di comunicare con la VM principalmente tramite WinRM per completare passi come l’impostazione dell’amministratore locale, l’installazione dei ruoli e l’eventuale configurazione IP/Domain Join se non completamente gestiti dall’unattend.
Se la VM non termina correttamente la fase di specialize, se l’unattend è incompatibile o se WinRM non è raggiungibile, VMM non riceve il “segnale di vita” e la personalizzazione resta in attesa fino al timeout.
Verifiche di compatibilità e prerequisiti
Prima di intervenire sul template, vale la pena validare l’infrastruttura. Usa la check‑list seguente.
| Area | Verifica | Indicazioni |
|---|---|---|
| VMM | Server di gestione aggiornato con l’ultimo Update Rollup disponibile per la tua major release. | Gli Update Rollup introducono fix alla pipeline di deployment e nuovi identificatori per sistemi operativi recenti. |
| Host Hyper‑V | Supporto ufficiale al guest Windows Server duemilaventidue. | Gli host duemiladiciannove supportano guest duemilaventidue; verifica anche i driver e il firmware del server fisico. |
| Library | Condivisione accessibile dal VMM e dagli host; refresh completati senza errori. | Controlla permessi NTFS e share; evita file bloccati o versioni “miste” del template. |
| SQL | Database VMM in salute, senza errori di connettività. | Eventuali ritardi del database possono riflettersi in timeout lato job. |
Controlli fondamentali sul template
La qualità del template è il punto più critico. Ecco cosa dev’essere vero nel tuo master Windows Server duemilaventidue:
- Il sistema è stato preparato con Sysprep in modalità Generalize e spento prima della cattura:
cd %WINDIR%\System32\Sysprep sysprep.exe /generalize /oobe /shutdown /mode:vmL’opzione/mode:vmottimizza la generalizzazione per ambienti virtuali. - Nel template non sono presenti software o agent che interferiscono con la fase di specialize (per esempio strumenti di hardening che bloccano WinRM, script di renaming aggressivi, vecchi agent di sicurezza configurati con policy “lockdown”).
- La Versione SO guest selezionata in VMM per il template è effettivamente Windows Server duemilaventidue; impostazioni errate (per esempio duemiladiciannove) possono generare un
unattend.xmlincompatibile. - Gli aggiornamenti cumulativi del sistema operativo sono stati applicati nel master prima del Sysprep, soprattutto se l’ISO iniziale è datata.
Analisi dei log che contano
La diagnosi passa dai log: poche posizioni, tutte preziose.
- VMM Logs:
C:\ProgramData\VMMLogssul server VMM. Cerca i job più recenti e filtra per la VM interessata. Qui trovi esattamente lo step che non avanza e l’ultimo errore ricevuto. - Event Viewer VMM: sul management server, in Applications and Services Logs controlla eventuali errori del servizio VMM.
- Event Viewer host Hyper‑V: particolarmente utile se usi bare‑metal deployment o se ci sono eventi di storage e rete durante la creazione.
- Log Sysprep nel guest:
C:\Windows\System32\Sysprep\Panther\setupact.logesetuperr.log. Qui si vede se la fase di generalize/specialize è andata in errore. - Log di setup del sistema:
C:\Windows\Panther\UnattendGC\setupact.logper problemi diunattend.xml(edizione errata, product key non valida, parametri non riconosciuti).
Durante il blocco, connetti la console della VM e premi MAIUSC+F10 in OOBE per aprire un prompt ed esaminare i log in tempo reale.
Ripristino e riavvio dei servizi VMM
Una interruzione temporanea nella catena VMM↔host↔guest può congelare la fase di personalizzazione. Oltre ai controller di rete, è utile riciclare i servizi chiave. Usa con prudenza i comandi seguenti sul server VMM e sugli host interessati.
# Sul server VMM
Get-Service vmm | Format-Table Name, Status, DisplayName -Auto
Stop-Service -Name VMMService -Force
Start-Service -Name VMMService
Sugli host Hyper‑V gestiti
Get-Service SCVMMAgent -ErrorAction SilentlyContinue
Restart-Service -Name SCVMMAgent -ErrorAction SilentlyContinue Se i log indicano file corrotti o componenti mancanti, valuta un ripristino dei binari VMM a partire da un backup sano del management server.
Rete e comunicazione WinRM
La gran parte degli stalli sullo step di personalizzazione si riduce a “VMM non riesce a parlare con il guest”. E WinRM è la lingua parlata. Verifica e, se serve, forzane l’abilitazione nel template.
Verifica e abilitazione WinRM nel template
# Esegui una volta nel master prima del Sysprep
Enable-PSRemoting -SkipNetworkProfileCheck -Force
Set-Service -Name WinRM -StartupType Automatic
Conferma dei listener
winrm enumerate winrm/config/listener
Test base
Test-WsMan localhost Regole firewall minime
| Funzione | Protocollo | Porta | Note |
|---|---|---|---|
| WinRM HTTP | TCP | cinquemilanovecentottantacinque | Predefinito per la gestione remota non cifrata su rete interna controllata. |
| WinRM HTTPS | TCP | cinquemilanovecentottantasei | Richiede certificato valido; usa solo se strettamente necessario. |
# Abilita le regole standard nel guest
Set-NetFirewallRule -DisplayGroup "Windows Remote Management" -Enabled True
Rete logica e IP Pool
Se il Guest OS Profile chiede a VMM di assegnare un IP statico, verifica che la scheda virtuale della VM sia mappata a una Logical Network con IP Pool valido e che l’host Hyper‑V abbia accesso agli uplink corretti. In caso di dubbio, usa DHCP per il primo avvio e rimanda l’indirizzamento statico.
Profilo del sistema operativo in VMM
Un Guest OS Profile “leggero” riduce i rischi. Per isolare il problema, parti dal minimo indispensabile:
- Imposta solo password dell’amministratore locale, fuso orario e lingua.
- Non rinominare la NIC, non assegnare IP statici, non eseguire il join al dominio nella prima iterazione.
- Se serve un product key, usa quello adatto all’edizione del template (evita mix tra Standard e Datacenter).
Dopo un deploy riuscito con profilo minimale, reintroduci una impostazione alla volta (prima hostname, poi rete, infine domain join). Così individui la voce che provoca lo stallo.
Percorso diagnostico ragionato
Segui questo flusso. Dopo ogni step riesegui la creazione della VM.
- Conferma la salute dell’ambiente: VMM aggiornato, host allineati, library senza errori.
- Rigenera il template: avvia la VM master, applica aggiornamenti, esegui i comandi per WinRM, poi Sysprep con generalizzazione e spegnimento. Cattura di nuovo.
- Allinea il profilo: seleziona Windows Server duemilaventidue come Guest OS, usa profilo minimale.
- Osserva la console: durante lo stallo, apri la console e verifica se il sistema è bloccato in OOBE, in riavvio continuo o operativo ma non raggiungibile.
- Leggi i log: analizza
setupact.login Sysprep e UnattendGC per eccezioni esplicite. - Rete: passa a DHCP, elimina rename delle NIC, verifica il vSwitch e le VLAN.
- Servizi VMM: riavvia i servizi VMM e l’agent sugli host, quindi riprova.
Considerazioni su generazione macchina, avvio protetto e TPM
Per Windows Server duemilaventidue su Hyper‑V duemiladiciannove il template dovrebbe essere di Generazione 2 con Secure Boot impostato sul profilo “Microsoft Windows”. Il TPM virtuale non è richiesto per la personalizzazione; abilitalo solo se necessario per requisiti di sicurezza o BitLocker. Se riscontri boot loop legati alla sicurezza, disattiva temporaneamente i controlli avanzati e riprova la personalizzazione.
Dominio e identità
Il join al dominio avviene durante la fase specialize; se la risoluzione DNS non è corretta o l’orologio di sistema è fuori sincronizzazione, la procedura fallisce e può bloccare l’intero flusso. Suggerimenti:
- Assicurati che il DNS primario del guest punti a un controller di dominio raggiungibile.
- Verifica la sincronizzazione oraria con l’host o con un NTP autorevole.
- Se stai usando OU o account di join personalizzati, prova prima senza specificarli.
Test senza generalizzazione in ambienti recenti
Se utilizzi una release recente del prodotto, è possibile eseguire un test di distribuzione senza Sysprep solo a scopo diagnostico. Lo scopo è capire se il blocco dipende dalla fase di generalizzazione. Non farne un modello stabile di produzione; una immagine non generalizzata porta SID e artefatti che non vanno replicati in serie.
Verifiche mirate alla edizione del sistema
Un mismatch tra edizione del template e profilo (Standard vs Datacenter) porta a errori silenziosi dell’unattend. È buona norma controllare l’edizione del master e allineare di conseguenza chiave e impostazioni nel profilo. Se usi attivazione KMS o AVMA, verifica i prerequisiti lato host e infrastruttura licenze.
Script di igiene del template
Esegui questi comandi una tantum nel master prima del Sysprep per assicurare i prerequisiti di comunicazione, quindi spegni e cattura.
# Abilita remoting e listener
Enable-PSRemoting -SkipNetworkProfileCheck -Force
Set-Service -Name WinRM -StartupType Automatic
Verifica servizi di integrazione Hyper‑V
Get-Service vmic* | Format-Table Name, Status, StartType -Auto
Pulisci i log di evento per ridurre rumore post-deploy
wevtutil el | ForEach-Object { wevtutil cl "$_" } 2>$null Tabella di mapping problema → causa probabile → rimedio
| Osservazione | Causa probabile | Azione consigliata |
|---|---|---|
| Console del guest ferma su OOBE | Unattend incompleto o non applicato | Rigenera template, verifica Generalize e profilo minimale |
| Guest operativo ma non raggiungibile | WinRM disabilitato o firewall attivo | Abilita remoting nel master, abilita regole firewall |
| Errore su join al dominio | DNS o orologio non coerenti | Usa DHCP iniziale, controlla NTP e DNS |
| Timeout ricorrente sempre allo stesso step | Bug noto risolto in Update Rollup | Aggiorna VMM e management server |
| Stallo quando assegni IP statico | IP Pool non valido o NIC rename | Prova con DHCP, rimuovi rename, verifica Logical Network |
Playbook rapido per uscire dallo stallo
- Aggiorna management server VMM con l’ultimo Update Rollup e riavvia i servizi.
- Convalida library, share e permessi; esegui un refresh completo.
- Ricrea il master Windows Server duemilaventidue:
- Installa aggiornamenti cumulativi.
- Esegui i comandi per WinRM e verifica i servizi Hyper‑V.
- Sysprep con generalizzazione e spegnimento.
- Cattura nuovamente il template in VMM, impostando come Guest OS Windows Server duemilaventidue.
- Distribuisci con un Guest OS Profile minimale e rete in DHCP.
- Osserva i log VMM e i log di setup del guest; se il deploy va a buon fine, reintroduci le personalizzazioni una alla volta.
Approfondimenti sulle impostazioni di rete
La combinazione tra Logical Network, Network Site, VLAN e IP Pool dev’essere coerente su host e VM. Errori tipici:
- vSwitch non connesso agli uplink port profile corretti: la VM si avvia ma non comunica.
- Pool esaurito o esclusioni che colpiscono l’intervallo richiesto: la richiesta resta sospesa.
- Rinominare le NIC via unattend o script: l’indice delle interfacce cambia e l’assegnazione IP fallisce.
In una prima fase diagnostica, evita VLAN non di default e qualunque rename di NIC. Una volta stabilita la stabilità del deploy, reintroduci i vincoli di rete necessari.
Quando coinvolgere il team sicurezza
Se il template include agent EDR, GPO restrittive o hardening CIS, la fase di specialize può essere impattata. Chiedi al team sicurezza una policy temporanea ad “apertura controllata” per il segmento di staging, in modo da escludere blocchi su WinRM, WMI e servizi di integrazione Hyper‑V durante il primo boot.
Cosa raccogliere prima di aprire un ticket
- Export del job VMM con elenco step e timestamp.
- Archivio dei log in
C:\ProgramData\VMMLogsfiltrati per la VM interessata. - File
setupact.logesetuperr.logdaSysprep\PantherePanther\UnattendGCdel guest. - Screenshot o trascrizione della console della VM durante la fase di stallo.
Suggerimenti mirati che risolvono davvero
- Risincronizza il template con gli aggiornamenti prima di ogni serie massiva di deploy; molte correzioni toccano proprio la fase di OOBE e specialize.
- Evita renaming complessi e script di rete nel primissimo avvio. Fai “accendere” la VM, poi applica la configurazione fine in un secondo step con runbook o Desired State Configuration.
- Valuta la sequenza del domain join: se continua a fallire in specialize, spostalo in un post‑config gestito da VMM o da un engine di automazione esterno.
- Assicurati che il ruolo Hyper‑V sugli host sia pulito da errori e che i servizi di integrazione nel guest siano in stato “In esecuzione”.
Conclusioni e piano d’azione
Il blocco durante la personalizzazione di una VM Windows Server duemilaventidue in VMM su host Hyper‑V duemiladiciannove deriva quasi sempre da un template non perfettamente generalizzato, da un profilo del sistema operativo troppo “carico” o da problemi di connettività WinRM. Il percorso più efficace è: rimettere in salute l’ambiente, rigenerare un template pulito e aggiornato, semplificare il profilo, verificare i log e reintrodurre le personalizzazioni passo‑passo. Seguendo la check‑list proposta, la creazione delle VM torna stabile e prevedibile, con un time‑to‑service nettamente inferiore.
Appendice operativa
Comandi utili lato VMM
# Elenco dei job recenti
Get-SCJob | Sort-Object StartTime -Descending | Select-Object -First 10 Name, Status, StartTime, EndTime
Dettaglio step di uno specifico job
$job = Get-SCJob -Name "Create virtual machine"
$job | Format-List Name, Status, ErrorInfo
$job.Steps | Format-Table StepName, Status, StartTime, EndTime -Auto Comandi utili lato guest
# Stato WinRM
winrm quickconfig
Test-WsMan localhost
Visualizza esiti dei servizi di integrazione Hyper‑V
Get-Service vmic* | Sort-Object Name | Format-Table Name, Status, StartType -Auto Checklist di pre‑cattura del template
- Patch cumulativo applicato, riavvio eseguito.
- Remoting abilitato e regole firewall WinRM attive.
- Nessun software di sicurezza in modalità “block all” alla prima accensione.
- Sysprep in Generalize con spegnimento.
- Cattura immediata del disco senza ulteriori boot.
Ricapitolando
Risolvi il blocco sullo step di personalizzazione con un approccio sistematico: allineamento delle versioni, template pulito e generalizzato, comunicazione WinRM garantita, profilo del sistema operativo essenziale e monitoraggio assiduo dei log. Una volta che il percorso “minimo” funziona, potrai rimettere in pista tutte le personalizzazioni, con la certezza di poterle attribuire a una causa se qualcosa si inceppa.
In sintesi operativa: controlla prerequisiti e compatibilità, verifica il template, analizza i log, ricicla servizi VMM se necessario, riprova il deployment; se il problema era nel template o nella comunicazione, la fase di personalizzazione passerà senza il famigerato timeout.
Queste indicazioni, insieme ai suggerimenti pratici su Sysprep, WinRM, profili minimali e aggiornamenti delle Integration Services già presenti in Windows Server duemilaventidue, consentono di eliminare le cause più comuni dello stallo e di standardizzare il provisioning con SCVMM.