1 25/05/2026 10 min

Quando una Task Sequence SCCM/MECM diventa difficile da leggere, il problema non è solo capire “cosa fa”, ma ricostruire chi dipende da cosa: step condizionali, package, application, script, driver package, reboot, variabili, collection, boundary, boot image e riferimenti indiretti. Se devi cambiare una TS in produzione, il punto non è aprire l’editor e scorrere: devi prima costruire una mappa affidabile delle dipendenze, altrimenti rischi di rompere un ramo usato solo in certe condizioni o di perdere un prerequisito che l’interfaccia nasconde bene.

Da dove partire: la Task Sequence non è un blocco unico

In Configuration Manager una Task Sequence è un contenitore logico, ma il suo funzionamento reale dipende da oggetti sparsi in più punti del sito: contenuti distribuiti, riferimenti a package, application model, immagini di avvio, driver package, account, variabili, condizioni e, spesso, oggetti esterni come script in share o file su content library. Se cerchi le dipendenze solo dentro l’editor della TS, vedi l’elenco degli step; se cerchi bene, scopri che metà delle relazioni utili è fuori dall’editor.

Il metodo corretto è lavorare su tre livelli: referenze dirette nella TS, contenuti e oggetti collegati nel sito, e dipendenze operative emerse dall’esecuzione reale nei log. Questo approccio riduce i falsi positivi: un package citato in un passo non è necessariamente usato in tutti i deployment, e una variabile definita nella TS può essere sovrascritta da collection, media, prestaged content o policy.

Le fonti da interrogare: console, WMI e log

Per trovare dipendenze e riferimenti conviene partire dalla console, poi passare ai log del client e, se serve, alle query WMI o SQL. La console ti dà il grafo “dichiarato”; i log ti dicono il grafo “effettivo”. In mezzo c’è la parte più importante: capire se un riferimento è statico, condizionale o ereditato.

I punti tipici sono questi:

  • Editor della Task Sequence: elenco degli step e delle condizioni.
  • Properties della TS: riferimenti a boot image, OS image, package e variabili.
  • Distribuzione contenuti: DP, DP group e stato del content.
  • Log client: soprattutto smsts.log, che mostra il ramo realmente eseguito.
  • Query WMI/SQL: utile quando devi fare inventario su più TS o automatizzare l’analisi.

Se il tuo obiettivo è fare troubleshooting o change controllato, il percorso minimo è: identificare la TS, estrarre gli step, elencare i riferimenti, verificare la distribuzione del contenuto e confrontare tutto con un’esecuzione reale.

Dipendenze dirette dentro la Task Sequence

Le dipendenze dirette sono quelle che puoi leggere nello step stesso. In una TS classica trovi almeno cinque categorie: package/program, application, script, driver package e immagini. Ogni categoria ha una modalità diversa di riferimento e una diversa fragilità.

Gli step “Run Command Line” e “Install Package” puntano spesso a package classici. Qui il riferimento utile non è solo il nome, ma il PackageID e il contenuto distribuito. Se il package è stato aggiornato ma non redistribuito su tutti i DP, la TS può apparire corretta e fallire comunque in fase di esecuzione.

Gli step “Install Application” introducono un altro livello: la TS richiama una application, ma la vera dipendenza include deployment type, detection method, requisiti, supersedence e contenuti referenziati dall’application. Se una application cambia detection method, la TS non cambia, ma il comportamento sì.

Gli step relativi ai driver sono più insidiosi: un driver package può sembrare un riferimento semplice, ma può nascondere problemi di contenuto, architettura, boot image e compatibilità hardware. Quando una TS fallisce in fase di imaging, spesso il riferimento “colpevole” non è lo step in sé, ma il driver package distribuito male o non aggiornato nel boot scenario corretto.

Per gli script, il riferimento può essere interno al package, a un file in content library o a un percorso UNC. Qui serve prudenza: se lo script legge da share esterne, la dipendenza non è tutta in ConfigMgr. Devi verificare permessi, reachability, autenticazione e, se necessario, il contesto di esecuzione del sistema locale.

Le condizioni: la parte che spesso falsifica l’analisi

Molti cercano “dipendenze” e si fermano ai riferimenti espliciti. È un errore: in una TS le condizioni determinano quali rami sono vivi. Un passo può essere presente ma non eseguibile per quel client, in quel momento, con quelle variabili. Quindi il riferimento esiste, ma non è operativo.

Le condizioni da controllare sono tipicamente su:

  • variabili TS, come _SMSTS* o custom variables;
  • membership di collection o query di targeting;
  • architettura, modello hardware o manufacturer;
  • stato del dispositivo, presenza di file o chiavi di registro;
  • esito di step precedenti, soprattutto in rami con Continue on error.

Qui il log è decisivo. smsts.log mostra quali condizioni sono state valutate e perché un ramo è stato saltato. Se il tuo inventario di dipendenze dice che un package è usato, ma in esecuzione il ramo non viene mai raggiunto, hai una dipendenza teorica e non operativa. Questa distinzione evita di inseguire problemi che non esistono nel percorso reale del client.

Come leggere smsts.log senza perdere tempo

Il file chiave è C:\Windows\CCM\Logs\smsts.log sul client in fase di OSD, oppure il log equivalente nell’ambiente di WinPE durante il deployment. Se usi CMTrace, il vantaggio è immediato: timestamp, livello e contesto sono più leggibili. Quello che ti interessa non è leggere tutto, ma trovare tre cose: step avviato, step fallito, e motivo per cui un branch è stato preso o saltato.

Un modo semplice per restringere il campo è cercare il nome della TS, il nome dello step o il PackageID. Quando trovi la riga giusta, controlla se il log indica download contenuto, validazione policy, risoluzione variabili o esecuzione di un comando. Se il fallimento avviene prima dell’esecuzione reale, spesso il problema è un riferimento mancante; se avviene durante lo step, il problema è più spesso contenuto, permessi o prerequisiti dell’host.

In un troubleshooting serio, il log del client va sempre letto insieme allo stato del contenuto nel sito. Una TS che “sembra” dipendere da un package può in realtà fallire perché il DP non ha ricevuto il contenuto, il boundary group non è corretto o il client sta scaricando da un punto non previsto.

Query utili per estrarre riferimenti in blocco

Se devi analizzare una singola TS, la console basta spesso. Se devi lavorare su più TS, serve un’estrazione ripetibile. In quel caso puoi usare query WMI o SQL, a seconda di quanto vuoi restare supportato e quanto ti serve dettaglio.

Con WMI puoi leggere gli oggetti di Task Sequence, i passi e alcuni riferimenti. Con SQL puoi correlare più tabelle e fare inventario trasversale, ma devi conoscere bene il modello dati e accettare il fatto che alcune informazioni sono più facili da interpretare via WMI che via join complicate. Se il tuo obiettivo è manutenzione operativa, spesso è più sano partire da WMI e usare SQL solo per report o auditing.

Un esempio pratico è cercare tutte le TS che richiamano un certo package o una certa application. Questo è utile prima di rimuovere contenuti obsoleti: non basta vedere che un oggetto non è più distribuito in console, devi sapere se è ancora referenziato da una TS nascosta in una collection poco usata o in una sequenza legacy tenuta per rollback.

Se non hai già una query pronta, il punto di partenza è chiaro: estrai la lista delle TS, poi i passi, poi i riferimenti ai package/application. Se manca un campo o una classe WMI nel tuo ambiente, il modo corretto per chiudere il gap è verificare il namespace root\SMS\site_<SiteCode> e l’oggetto specifico con Get-CimClass o con la documentazione del provider in uso.

Un approccio pratico per mappare dipendenze e riferimenti

Se vuoi un metodo ripetibile, lavora così: prima fotografa la TS, poi costruisci la lista dei riferimenti, infine valida l’esecuzione reale. In pratica:

  1. Apri la TS e annota ogni step che richiama package, application, script, driver o image.
  2. Per ogni step, registra il tipo di oggetto, l’ID e l’eventuale condizione.
  3. Controlla che il contenuto associato sia distribuito e in stato corretto sui DP necessari.
  4. Verifica eventuali variabili usate nei branch e la loro origine.
  5. Confronta la teoria con smsts.log su un client reale o in ambiente di test.

Questo metodo sembra banale, ma evita il classico errore: cambiare un oggetto “a valle” senza accorgersi che è referenziato da più TS o da più rami della stessa TS. È qui che una mappa delle dipendenze fa risparmiare tempo, soprattutto quando devi fare change controllato con finestra stretta.

Dipendenze nascoste: boundary, contenuto e account

Ci sono riferimenti che non compaiono come step della TS ma condizionano il risultato. Il primo è il boundary group: se il client non trova il DP corretto, i contenuti della TS restano teoricamente validi ma praticamente irraggiungibili. Il secondo è l’account usato per l’accesso a risorse esterne, se la TS deve leggere share, file o script remoti. Il terzo è la configurazione del boot environment, perché una TS può dipendere da una boot image che a sua volta deve contenere driver e componenti corretti.

Qui non basta chiedersi “la TS è corretta?”. La domanda giusta è: tutto ciò che la TS presume esista è davvero disponibile nel contesto di esecuzione? Se la risposta è no, la dipendenza è rotta anche se l’oggetto in console sembra sano.

Quando conviene usare la console e quando automatizzare

Per una singola analisi, la console è più rapida e meno soggetta a errore. Per un audit ricorrente, la console non basta: serve uno script che esporti riferimenti, condizioni e contenuti. La scelta dipende dal problema. Se stai verificando una TS appena fallita, parti dal log e dalla console. Se devi fare pulizia di oggetti non più usati, automatizza l’inventario.

In ambienti grandi, la vera utilità dell’automazione non è solo trovare chi usa cosa, ma evitare la rimozione accidentale di oggetti ancora vivi in una sequenza poco visibile. Una dependency map aggiornata è il miglior rollback preventivo: ti dice quali oggetti toccare con cautela e quali no.

Checklist operativa prima di modificare una Task Sequence

Prima di cambiare una TS, verifica sempre questi punti:

  • identità della TS e scope di deployment;
  • step che referenziano package, application, script o driver package;
  • condizioni che attivano o saltano i rami;
  • stato di distribuzione dei contenuti sui DP;
  • log di un’esecuzione reale o di test;
  • eventuali dipendenze esterne a ConfigMgr, come share o script remoti.

Se una di queste informazioni manca, il gap va chiuso prima del change. Il modo corretto non è “provare e vedere”, ma recuperare il dato preciso: nel log, nel campo della console, nella query WMI o nello stato contenuti del sito.

Conclusione operativa: la mappa vale più dell’editor

Trovare dipendenze e riferimenti delle Task Sequence SCCM non significa solo elencare oggetti collegati. Significa ricostruire il percorso reale dell’esecuzione, distinguere tra riferimenti statici e rami effettivi, e controllare che tutto ciò che la TS assume disponibile lo sia davvero nel client, nel content distribution e nel contesto di rete. Se lavori così, riduci i guasti da change, leggi meglio i fallimenti e puoi anche fare pulizia del vecchio senza tirarti addosso effetti collaterali inutili.