Deployment VM Windows Server 2022 con SCVMM su Hyper‑V 2019: come sbloccare la personalizzazione che va in timeout

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.

Indice

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:

  1. VMM clona il VHDX o istanzia il differencing disk dal template.
  2. VMM inietta o associa un file unattend.xml costruito dal Guest OS Profile selezionato.
  3. 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).
  4. 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.

AreaVerificaIndicazioni
VMMServer 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‑VSupporto ufficiale al guest Windows Server duemilaventidue.Gli host duemiladiciannove supportano guest duemilaventidue; verifica anche i driver e il firmware del server fisico.
LibraryCondivisione accessibile dal VMM e dagli host; refresh completati senza errori.Controlla permessi NTFS e share; evita file bloccati o versioni “miste” del template.
SQLDatabase 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:vm L’opzione /mode:vm ottimizza 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.xml incompatibile.
  • 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\VMMLogs sul 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.log e setuperr.log. Qui si vede se la fase di generalize/specialize è andata in errore.
  • Log di setup del sistema: C:\Windows\Panther\UnattendGC\setupact.log per problemi di unattend.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

FunzioneProtocolloPortaNote
WinRM HTTPTCPcinquemilanovecentottantacinquePredefinito per la gestione remota non cifrata su rete interna controllata.
WinRM HTTPSTCPcinquemilanovecentottantaseiRichiede 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.

  1. Conferma la salute dell’ambiente: VMM aggiornato, host allineati, library senza errori.
  2. Rigenera il template: avvia la VM master, applica aggiornamenti, esegui i comandi per WinRM, poi Sysprep con generalizzazione e spegnimento. Cattura di nuovo.
  3. Allinea il profilo: seleziona Windows Server duemilaventidue come Guest OS, usa profilo minimale.
  4. 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.
  5. Leggi i log: analizza setupact.log in Sysprep e UnattendGC per eccezioni esplicite.
  6. Rete: passa a DHCP, elimina rename delle NIC, verifica il vSwitch e le VLAN.
  7. 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

OsservazioneCausa probabileAzione consigliata
Console del guest ferma su OOBEUnattend incompleto o non applicatoRigenera template, verifica Generalize e profilo minimale
Guest operativo ma non raggiungibileWinRM disabilitato o firewall attivoAbilita remoting nel master, abilita regole firewall
Errore su join al dominioDNS o orologio non coerentiUsa DHCP iniziale, controlla NTP e DNS
Timeout ricorrente sempre allo stesso stepBug noto risolto in Update RollupAggiorna VMM e management server
Stallo quando assegni IP staticoIP Pool non valido o NIC renameProva con DHCP, rimuovi rename, verifica Logical Network

Playbook rapido per uscire dallo stallo

  1. Aggiorna management server VMM con l’ultimo Update Rollup e riavvia i servizi.
  2. Convalida library, share e permessi; esegui un refresh completo.
  3. 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.
  4. Cattura nuovamente il template in VMM, impostando come Guest OS Windows Server duemilaventidue.
  5. Distribuisci con un Guest OS Profile minimale e rete in DHCP.
  6. 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\VMMLogs filtrati per la VM interessata.
  • File setupact.log e setuperr.log da Sysprep\Panther e Panther\UnattendGC del 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.

Indice