1 19/05/2026 11 min

Creare una capture di Windows 7 con SCCM 2012 R2

Con SCCM 2012 R2 la capture di Windows 7 non è un esercizio da wizard e via. Se l’obiettivo è ottenere una immagine di riferimento riutilizzabile, il punto non è solo “fare la cattura”, ma preparare una macchina pulita, minimizzare la personalizzazione locale e chiudere bene il ciclo con Sysprep, WinPE e una task sequence dedicata. Il dettaglio che fa la differenza, quasi sempre, è la disciplina operativa: ambiente di build separato, rete stabile, driver essenziali e nessuna app che lasci residui nel profilo o nel sistema.

Il flusso corretto, in pratica, è questo: prepari una macchina di riferimento con Windows 7, installi solo ciò che deve davvero stare nell’immagine base, avvii una task sequence di capture che esegue Sysprep e riavvia in WinPE, e poi salvi il file WIM su una share accessibile dal server SCCM o su un percorso di rete autorizzato. Se salti uno di questi passaggi, il risultato tipico è una capture inutilizzabile, o peggio un’immagine che sembra buona ma fallisce al primo deployment.

Prerequisiti che non puoi ignorare

Prima di toccare la console SCCM, verifica che il contesto sia quello giusto. Windows 7 deve essere gestito con una versione di SCCM che supporti correttamente il tuo scenario, e il boot image deve essere coerente con architettura e driver della macchina di riferimento. In ambienti reali, il problema non è quasi mai la capture in sé: è il mismatch tra WinPE, storage controller, scheda di rete o configurazione della task sequence.

  • Server SCCM 2012 R2 operativo e console amministrativa accessibile.
  • Boot image WinPE aggiornata con i driver necessari per rete e storage.
  • Share di rete con permessi di scrittura per l’account usato dalla task sequence o dal computer in WinPE.
  • Macchina di riferimento Windows 7 pulita, idealmente in workgroup o in un OU dedicata, senza software non necessario.

Se non hai chiaro quale account scriva il file WIM, fermati qui e verifica il punto nel Distribution Point o nel percorso di salvataggio della capture. Il problema classico è tentare di salvare su una share che accetta la connessione ma blocca la scrittura. Il test minimo è banale e va fatto prima della task sequence:

net use Z: \\SERVER\ShareCapture /user:DOMINIO\utente *
echo test > Z:\write-test.txt

Se il file di test non viene creato, la capture fallirà più avanti con un errore poco utile. In quel caso il fix è lato permessi NTFS e share, non lato SCCM.

Preparare la macchina di riferimento

La macchina da catturare deve rappresentare il baseline, non un desktop già usato per settimane. Su Windows 7 questo significa installare update, framework e componenti base, ma evitare software che generi identificatori univoci o che si registri in modo aggressivo al primo boot. La regola pratica è semplice: tutto ciò che non vuoi vedere in ogni client finale non deve stare nella capture.

  1. Installa Windows 7 dalla sorgente standard che intendi usare come riferimento.
  2. Applica gli update necessari al tuo standard interno.
  3. Installa eventuali runtime o applicazioni comuni che devono essere presenti su ogni endpoint.
  4. Rimuovi software temporaneo, tool di test, agent non previsti e file personali.
  5. Verifica che il profilo amministrativo locale sia pulito e che non ci siano processi in avvio automatico non richiesti.

Qui c’è un errore frequente: installare troppo. Una capture “comoda” all’inizio diventa una zavorra dopo sei mesi, quando devi aggiornare un componente e non sai più se stai correggendo un problema dell’immagine o di una personalizzazione aggiunta in fretta. Se puoi, tieni la base sottile e lascia il resto a task sequence di deployment o a post-installazione applicativa.

Prima della capture conviene anche controllare lo stato del sistema con strumenti nativi. Non serve inventare diagnostica: basta verificare che il sistema non abbia errori evidenti in coda e che lo spazio disco sia sufficiente per Sysprep e per la scrittura temporanea del WIM.

dir C:\
wevtutil qe System /c:10 /f:text
wevtutil qe Application /c:10 /f:text

Gli eventi recenti non devono mostrare errori ripetuti su servizi critici, driver o disco. Se emergono warning o errori ricorrenti, risolvi prima quelli. Fare capture su una base già sporca è il modo più rapido per congelare un problema dentro l’immagine.

Creare la task sequence di capture in SCCM 2012 R2

In SCCM 2012 R2 la capture si gestisce con una task sequence dedicata. L’idea è: eseguire Sysprep, riavviare in WinPE, montare la rete e salvare il file WIM. La console offre il percorso guidato, ma il punto operativo è controllare ogni variabile che possa cambiare il comportamento della macchina durante il passaggio da Windows avviato a ambiente di preinstallazione.

  1. Apri la console SCCM e vai in Software Library > Operating Systems > Task Sequences.
  2. Crea una nuova task sequence di tipo Build and Capture a reference operating system, se disponibile nel tuo template, oppure una sequenza personalizzata equivalente.
  3. Seleziona la boot image corretta per l’architettura della macchina di riferimento.
  4. Definisci il percorso di output del file WIM su una share raggiungibile da WinPE.
  5. Controlla che l’account usato abbia i permessi necessari su share e NTFS.

Il dettaglio che spesso viene sottovalutato è la boot image. Se la boot image non vede il controller di rete o il disco, la task sequence sembrerà partire ma si fermerà al primo punto in cui deve parlare con la rete o accedere al sistema. La verifica pratica è semplice: dalla console, distribuisci la boot image al Distribution Point e, se necessario, aggiorna i driver prima del test.

Se vuoi controllare in modo più rigoroso la parte di WinPE, vale la pena verificare i driver inseriti nella boot image e la loro compatibilità con il firmware della macchina. In ambienti misti, un problema di driver NIC è abbastanza comune da giustificare un test preventivo. Quando avvii in WinPE, devi poter vedere il disco e raggiungere la share; il resto è secondario.

Sysprep: il punto in cui la capture si vince o si perde

Sysprep non va trattato come un passaggio automatico senza conseguenze. Su Windows 7, una macchina con installazioni incoerenti, update pendenti o componenti già “consumati” da precedenti tentativi può fallire o produrre un sistema non generalizzato come ti aspetti. Il comportamento da osservare è il seguente: la task sequence deve lanciare Sysprep, il sistema deve spegnersi o riavviarsi secondo il flusso previsto, e poi deve entrare in WinPE senza errori di accesso al disco o alla rete.

Se Sysprep fallisce, non andare a tentativi. Leggi i log nel percorso standard di Windows e cerca il punto esatto di rottura. I file utili, in questo scenario, sono quasi sempre quelli di Sysprep e setup, e il percorso da controllare è quello classico sul sistema di riferimento:

C:\Windows\System32\Sysprep\Panther\setuperr.log
C:\Windows\System32\Sysprep\Panther\setupact.log

Se trovi riferimenti a app non supportate, servizi bloccanti o errori di generalizzazione, la correzione va fatta sul sistema di riferimento prima di ripetere la capture. Il rollback più sicuro, quando il tentativo è fallito a metà, è ripristinare la VM o la macchina fisica a uno snapshot pulito. Se non hai snapshot, devi rifare la preparazione da capo. È scomodo, ma è più veloce che inseguire uno stato incerto.

La regola pratica: una capture buona nasce da una macchina noiosa. Più la reference machine è “creativa”, più la task sequence diventa fragile.

Verifiche in WinPE e salvataggio della WIM

Quando la macchina entra in WinPE, il test reale è triplice: rete, storage e scrittura del file. Se uno dei tre manca, la capture si interrompe o produce un file incompleto. In questa fase i log della task sequence sono la fonte primaria, non il pannello grafico. Il file più utile, in genere, è il log della sequenza in WinPE, che puoi leggere su X: o su `SMSTS.log` quando disponibile.

type X:\Windows\Temp\SMSTSLOG\SMSTS.log

Se il file non è in quel percorso, cerca il log nei path standard di SCCM in WinPE o nell’ambiente temporaneo della task sequence. Il punto non è il path esatto in astratto, ma l’abitudine di leggere il log prima di cambiare configurazione. Se la connessione alla share fallisce, vedrai un errore di accesso; se il disco non è visibile, il problema è quasi certamente nella boot image o nei driver; se la task sequence si interrompe dopo Sysprep, torna ai log di Windows 7.

Una volta che il file WIM viene scritto, verifica che la dimensione sia plausibile rispetto al contenuto installato. Un file troppo piccolo o sospettosamente stabile rispetto a un’immagine precedente può indicare un export incompleto o una cattura interrotta. Il controllo minimo è banale:

dir \\SERVER\ShareCapture\Win7-Ref.wim

Non basta vedere che il file esiste. Devi aprirlo in SCCM o nel tool di gestione immagini che usi nel tuo flusso e confermare che sia importabile senza warning. Se il WIM viene generato ma non importato correttamente, il problema potrebbe essere nella trasmissione, nel file system della share o nella corruzione del file durante la scrittura.

Driver, aggiornamenti e pulizia: cosa lasciare dentro e cosa no

Con Windows 7 è facile esagerare con driver e pacchetti. La reference image deve contenere ciò che è comune a tutti i client target, non quello che serve a una singola postazione. I driver specifici, soprattutto per hardware eterogeneo, è più sensato gestirli fuori dalla capture e iniettare quelli corretti in fase di deployment. Questo riduce il rischio di conflitti e di aggiornamenti inutili dell’immagine base.

  • Dentro la capture: componenti di base, update approvati, runtime comuni, eventuali strumenti standard aziendali.
  • Fuori dalla capture: driver specifici per modello, agent che si registrano con identità univoca, tool temporanei, software di test.
  • Da verificare sempre: avvio automatico, servizi residui, scheduled task non voluti, cache di installer.

Un controllo utile è ispezionare le chiavi di avvio automatico e i servizi installati, ma senza trasformare la macchina di riferimento in un laboratorio di tuning. Devi soltanto confermare che non ci sia roba che si riaccende da sola al primo avvio dell’immagine distribuita. Se trovi un servizio non previsto, la correzione va fatta prima della capture, non dopo.

Problemi tipici e come falsificarli velocemente

  1. Sysprep fallisce. Verifica `setuperr.log` e `setupact.log` nel path di Sysprep. Se compaiono errori su app o generalizzazione, il problema è nella reference machine, non nella task sequence.
  2. WinPE non vede rete o disco. Controlla la boot image e i driver inseriti. Se in WinPE non ottieni indirizzo IP o non vedi il volume, il fix è lato driver o boot image.
  3. La WIM non viene salvata. Testa la share con `net use` e una scrittura manuale. Se fallisce, è un problema di permessi o connettività, non della capture.

Queste tre verifiche coprono la maggior parte dei casi reali. In un ambiente ben tenuto, la capture non dovrebbe richiedere interventi creativi: o funziona, o ti dice con abbastanza chiarezza dove si è rotta. La parte difficile è evitare di cambiare tre cose insieme, perché così perdi il riferimento e non capisci più quale modifica ha introdotto il guasto.

Struttura operativa consigliata

Se devi ripetere spesso questa attività, conviene standardizzare il processo. Una sequenza pulita e ripetibile vale più di una capture “eroica” fatta una volta sola. Il flusso che funziona meglio, nella pratica, è questo: preparazione della reference machine, snapshot o backup, test dei permessi sulla share, verifica boot image, esecuzione della task sequence, lettura log, import del WIM, prova di deployment su una VM di test.

  1. Prepara la macchina di riferimento e congelane lo stato con snapshot o backup.
  2. Verifica accesso alla share di destinazione con un test di scrittura.
  3. Conferma driver e boot image per WinPE.
  4. Lancia la task sequence di capture.
  5. Leggi i log se qualcosa si ferma.
  6. Importa la WIM e fai un deployment di prova su un target di laboratorio.

Il deployment di prova non è un optional. Una capture che si importa senza errori può comunque fallire al primo avvio se contiene driver sbagliati, servizi anomali o una generalizzazione incompleta. Il test finale deve arrivare almeno fino al primo logon e alla verifica di base di rete, storage e avvio servizi.

Conclusione operativa: cosa conta davvero

Creare una capture di Windows 7 con SCCM 2012 R2 non è un problema di interfaccia, ma di controllo del processo. Se la macchina di riferimento è pulita, la boot image è corretta, la share è scrivibile e Sysprep non incontra ostacoli, la capture è normalmente lineare. Quando invece uno di questi elementi è ambiguo, il risultato si sporca subito e ti costringe a inseguire errori secondari.

La regola che conviene tenere a mente è semplice: osserva prima di modificare, cambia una cosa alla volta, e conserva sempre un punto di ritorno. In questo tipo di attività il vero risparmio di tempo non è fare più in fretta la capture, ma evitare di rifarla tre volte per colpa di una share, di un driver o di un Sysprep lasciato a metà.