Come aggiungere il supporto HTA all'immagine di avvio SCCM MDT

Quando l’HTA serve davvero nel boot image MDT/SCCM

Il supporto HTA in un’immagine di avvio MDT/SCCM non è un dettaglio cosmetico: serve quando la sequenza di task deve mostrare interfacce HTML Application dentro WinPE, tipicamente per raccogliere parametri, guidare l’operatore o presentare logica condizionale che non vuoi affidare a semplici prompt di testo. Senza i componenti giusti, il deployment parte lo stesso, ma le pagine HTA falliscono appena vengono invocate. Il sintomo classico è un wizard che non si apre, uno script che si interrompe o un errore VBScript/COM poco utile per chi sta davanti alla console.

La cosa importante è questa: non stai “installando HTA” sul server SCCM. Stai preparando il boot image WinPE perché contenga i componenti necessari a eseguire le applicazioni HTML nel contesto del pre-OS. In pratica, devi lavorare sul boot.wim o sul boot image distribuito da Configuration Manager, aggiungere i pacchetti WinPE corretti, aggiornare l’immagine e poi ridistribuirla ai punti di distribuzione. Se salti un passaggio, il problema non emerge in console ma al momento del boot, cioè quando il rollback è più costoso.

Dipendenze reali: non basta WinPE “base”

HTA in WinPE dipende da più pezzi, e confonderli è il modo più rapido per perdere tempo. La base è l’ambiente WinPE corretto per la tua versione di ADK, poi servono i componenti opzionali che portano dentro il supporto scripting e la shell necessaria a far girare l’interfaccia. In molte build, il problema non è l’HTA in sé ma l’assenza del motore script o di librerie correlate, oppure un boot image non rigenerato dopo l’aggiunta dei moduli.

Il punto operativo è semplice: se il wizard MDT usa file .hta, .vbs o chiamate a mshta nel contesto WinPE, devi assicurarti che il boot image contenga i pacchetti WinPE di scripting e supporto HTML compatibili con la tua versione di ADK. Con versioni recenti, il naming dei componenti cambia rispetto alle guide vecchie, e proprio lì spesso nasce la confusione. Non fidarti di procedure scritte per ADK di anni fa senza verificare i pacchetti effettivamente presenti nella tua installazione.

Preparazione corretta del boot image in SCCM

Se il boot image è gestito da Configuration Manager, il flusso pulito è lavorare dal nodo dell’immagine di avvio, aggiungere i componenti WinPE necessari e poi rigenerare il contenuto. In genere il percorso è quello del console tree di SCCM sotto Software Library, poi Operating Systems, quindi Boot Images. Da lì apri le proprietà del boot image usato da MDT e controlli i tab relativi ai componenti opzionali. Se invece lavori direttamente sul boot.wim in un laboratorio o su una procedura standalone, il principio non cambia: mount, add-on dei pacchetti, commit, rebuild e test su un media pulito.

Prima di toccare il contenuto, fai una copia del boot image o esporta la versione corrente. Non è paranoia: è la differenza tra un cambio reversibile e una giornata spesa a ricostruire un’immagine che prima funzionava. In ambiente SCCM conviene annotare anche il package ID del boot image e l’ultima data di update, così sai esattamente cosa hai cambiato quando devi fare troubleshooting.

Pacchetti da aggiungere: cosa controllare e in che ordine

La sequenza precisa dipende dalla versione di ADK/WinPE, ma il criterio non cambia: devi includere i moduli di WinPE che abilitano scripting e componenti UI richiesti da MDT. Nella pratica, i pacchetti più rilevanti sono quelli che portano supporto a WMI, Scripting, HTA e, se usi funzionalità avanzate, anche PowerShell e .NET correlati. Se il task sequence usa solo una HTA semplice, il focus è sul runtime che permette l’esecuzione di pagine HTML Application nel pre-boot.

Non fare assunzioni del tipo “ho già WinPE quindi HTA funziona”. WinPE può essere perfettamente avviabile ma incapace di eseguire il tuo wizard. La verifica va fatta sui componenti presenti nell’immagine, non sull’idea astratta che “WinPE supporta tutto”. In più, se usi un boot image x64, i pacchetti devono essere coerenti con architettura e versione del kit. Mischiare componenti di release diverse produce errori subdoli: l’immagine si aggiorna, ma l’HTA resta non funzionante.

Procedura operativa consigliata

Il modo più sicuro è procedere per passi piccoli e verificabili. Prima prepari l’ambiente ADK/WinPE sul server di amministrazione, poi modifichi il boot image, infine verifichi in una VM isolata che l’HTA venga effettivamente renderizzata. Evita di fare tre cambi insieme: se qualcosa si rompe, non capisci se il problema è il pacchetto mancante, il boot image non rigenerato o il task sequence che punta a un file sbagliato.

Se lavori da console SCCM, il flusso tipico è questo: apri le proprietà del boot image, aggiungi i componenti WinPE richiesti, aggiorni l’immagine di avvio e fai distribuire il nuovo contenuto ai distribution point. Dopo l’update, non dare per scontato che tutti i DP abbiano il nuovo wim: controlla lo stato di distribuzione e l’eventuale aggiornamento in corso. Un boot image modificato ma non distribuito equivale a nessun cambio dal punto di vista dei client che fanno PXE o boot da media.

Se invece lavori da file system, il ciclo è più esplicito. Monti il WIM, aggiungi i pacchetti con gli strumenti di servicing, smonti con commit e poi rigeneri il contenuto in SCCM o nel media MDT. In questo caso il controllo finale non è solo che il file esista, ma che il boot.wim aggiornato sia quello effettivamente pubblicato e usato dal punto di avvio.

Esempio di controllo dei componenti nel boot image

Per capire se il problema è davvero la mancanza dei componenti, conviene ispezionare il contenuto del WIM e i log del servicing. Un esempio utile è montare l’immagine e verificare la presenza dei pacchetti installati:

dism /Get-WimInfo /WimFile:C:\WinPE\boot.wim

Se vuoi vedere i pacchetti applicati a un indice specifico, il controllo più diretto è:

dism /Mount-Wim /WimFile:C:\WinPE\boot.wim /Index:1 /MountDir:C:\Mount
 dism /Image:C:\Mount /Get-Packages
 dism /Unmount-Wim /MountDir:C:\Mount /Commit

Il risultato atteso è la presenza dei componenti WinPE legati a scripting e HTA. Se non li vedi, il wizard non potrà funzionare. Se li vedi ma il problema persiste, il passo successivo è il log di distribuzione e il test in avvio.

Verifica nel task sequence: il punto dove spesso si rompe tutto

Molti amministratori sistemano il boot image ma lasciano invariato il task sequence. Il risultato è un ambiente che avvia correttamente WinPE, ma non trova il file .hta, non carica il percorso giusto o punta a uno share non raggiungibile nel contesto di rete del pre-boot. Quindi la verifica non deve fermarsi al boot: devi controllare anche i riferimenti nel task sequence e nel deployment share, se usi MDT integrato.

Il controllo minimo è banale ma efficace: il file HTA esiste nel percorso previsto, il percorso è accessibile dal contesto di WinPE e la sequenza lo richiama con il nome corretto. Se il file è in `Scripts`, `Tools` o in una cartella personalizzata del deployment share, verifica che la replicazione sia completata e che il client stia pescando la versione aggiornata. Un errore di path è molto più comune di un problema di rendering HTA.

Se usi variabili di ambiente o logica condizionale dentro la HTA, testa anche i casi limite: variabile non valorizzata, input vuoto, rete non disponibile, linguaggio non previsto. Le HTA in MDT spesso funzionano nel caso felice e falliscono appena cambiano le condizioni operative. Un wizard robusto non deve dipendere da un solo ramo di esecuzione.

Log da guardare quando l’HTA non parte

Il troubleshooting serio parte dai log, non dalle ipotesi. In SCCM/MDT, i punti utili sono i log di WinPE e quelli della task sequence. Se il problema è nel boot image o nella distribuzione, lo vedi nei log di aggiornamento e di distribuzione contenuti nella console o nei log del distretto di gestione del contenuto. Se invece il problema è l’esecuzione della HTA, devi guardare i log del task sequence nel pre-boot e il messaggio di errore generato dallo script che lancia l’interfaccia.

Il segnale che cerchi è uno di questi: file non trovato, componente non registrato, errore di esecuzione script, o apertura della finestra seguita da chiusura immediata. Se la HTA non compare proprio, il problema è quasi sempre a monte: componente mancante, path sbagliato o task sequence che non arriva al punto di esecuzione. Se compare ma è vuota o incompleta, allora devi guardare la logica interna della pagina e le dipendenze script.

Un controllo pratico utile è aprire una shell in WinPE e lanciare manualmente il punto di ingresso della HTA, se il tuo ambiente lo consente. Così distingui subito tra problema dell’orchestrazione e problema dell’applicazione. Se il lancio manuale funziona e la task sequence no, il colpevole è quasi sempre il ramo di esecuzione o la variabile usata per costruire il path.

Rollback pulito: come tornare indietro senza sporcare l’ambiente

Ogni modifica al boot image va trattata come change controllato. Il rollback migliore è ripristinare il boot image precedente o disabilitare temporaneamente la distribuzione del nuovo contenuto, poi rimandare in produzione solo dopo aver verificato il fix. Se hai esportato il WIM prima del cambio, il rollback è diretto: ripubblichi la versione precedente e ridistribuisci ai DP. Se hai lavorato in SCCM, puoi anche tornare alla configurazione precedente dei componenti opzionali e rigenerare l’immagine.

Il blast radius è limitato se il boot image è usato da una sola task sequence, ma aumenta subito se quel boot image è condiviso tra più flussi di deployment. Per questo conviene sapere in anticipo quali deployment dipendono da quell’immagine. Se il rollback è necessario, non cambiare anche il task sequence nello stesso momento: prima rimetti in piedi il boot path, poi fai il resto con calma.

Controllo finale prima di considerare il lavoro chiuso

La verifica finale non è “il file è stato copiato”. Devi vedere tre cose: il boot image aggiornato è distribuito, WinPE avvia correttamente l’ambiente, la HTA si apre e completa il flusso previsto. In una VM di test, il comportamento corretto è che la finestra HTA appaia senza errori, le variabili siano valorizzate e il passaggio successivo della task sequence prosegua normalmente. Se una di queste tre condizioni manca, il problema non è risolto.

Se vuoi ridurre il rischio di regressioni, conserva una copia del vecchio boot image, annota i pacchetti aggiunti e salva il percorso esatto del file HTA richiamato dal task sequence. In ambienti grandi, questo è più utile di una nota generica nel change record: quando qualcuno ti chiede cosa è stato toccato, hai già la risposta pronta e verificabile.

Assunzione operativa: il reader sta lavorando su SCCM con MDT integrato, boot image WinPE x64 e necessità di mantenere il cambio reversibile senza interrompere i deployment esistenti.