1 25/04/2026 9 min

Quando SCCM restituisce l’errore 80070002 nella creazione dei supporti, il punto non è quasi mai “SCCM rotto”: il problema è che il wizard non riesce a trovare uno o più elementi attesi nel contenuto da esportare. In pratica stai chiedendo al site server di impacchettare file, dipendenze o metadati che, in quel momento, non sono dove il sistema si aspetta di trovarli.

Il caso tipico è il supporto per OSD o per task sequence, ma la stessa logica vale anche per altri media in Configuration Manager: il contenuto è stato spostato, non è stato distribuito correttamente, il percorso locale del Distribution Point non è coerente, oppure la cache di package source contiene riferimenti vecchi. L’errore è generico, quindi va trattato per layer: prima si verifica il contenuto, poi il DP, poi il wizard di media creation.

Che cosa significa davvero 80070002 in questo contesto

80070002 corrisponde al classico “file non trovato”. In SCCM non indica necessariamente che manca un file sul client: più spesso il file manca sul server di origine, nel package source, nel content library del Distribution Point, oppure il percorso configurato nel media wizard punta a una destinazione non valida.

La parte scomoda è che il wizard di creazione supporti non sempre espone il nome del file mancante in modo chiaro. Per questo conviene ragionare per probabilità:

  • Content source mancante o incoerente: il package o l’application punta a file che non esistono più nel percorso di origine.
  • Distribuzione incompleta sul DP: il contenuto non è presente nel Distribution Point o è in stato fallito/pendente.
  • Path o permessi del supporto: il wizard non riesce a scrivere il media o a leggere i file intermedi perché il percorso è errato o bloccato.

    • Se vuoi una lettura rapida: 80070002 = il media builder sta cercando qualcosa che non trova. Il lavoro vero è capire dove manca quel pezzo.

    Prima verifica: il contenuto esiste davvero dove SCCM lo si aspetta

    La prima cosa da controllare è il package, l’application o la task sequence coinvolta. Non partire dal media wizard: se il contenuto a monte è incoerente, il supporto fallirà di nuovo anche dopo un retry.

  • Apri la console SCCM e vai in Software Library → Application Management oppure Operating Systems, in base all’oggetto usato nel media.
  • Verifica lo stato di distribuzione del contenuto su Distribution Points: deve risultare Success e non In Progress o Failed.
  • Se il media include package legacy, controlla il Content Source del package: il percorso deve esistere e contenere i file attesi.

    • Se hai accesso al file system del site server o del server che ospita il source, verifica anche il percorso fisico. Un errore banale ma frequente è un source path spostato, rinominato o su share non più raggiungibile.

    PowerShell esempio di controllo rapido lato source, da adattare al tuo oggetto:
Test-Path "D:\Sources\SCCM\Package01"
Get-ChildItem "D:\Sources\SCCM\Package01" | Select-Object Name

    Se il percorso non esiste, hai già la causa più probabile. Se esiste, il problema si sposta sulla distribuzione o su una dipendenza non risolta.

    Controlla il Distribution Point e la content library

    Quando il source è corretto ma il supporto fallisce comunque, il sospetto va sul DP. Il media wizard pesca i contenuti dal site database e dal content store; se il DP ha un contenuto corrotto, incompleto o non aggiornato, l’errore può essere identico a quello di un file mancante.

  • In console, apri il nodo Monitoring → Distribution Status → Content Status.
  • Individua il package o l’application coinvolta e verifica il dettaglio: i punti da guardare sono Success, In Progress, Failed.
  • Se c’è un DP specifico in errore, controlla il log distmgr.log e, se necessario, smsdpprov.log sul site server.

    • Il sintomo utile non è solo “failed”: cerca il nome del file o del componente che non viene copiato. Spesso il log riporta un path che non esiste più, oppure una dipendenza non presente nel package source.

    Log utili sul site server:
- distmgr.log
- pkgxfermgr.log
- smsdpmon.log
- smsdpprov.log

    Se il DP è fuori allineamento, la correzione più pulita è ridistribuire il contenuto. Evita di “forzare” il media creation finché il content status non è pulito: stai solo ripetendo l’errore con meno visibilità.

    Log da leggere per isolare il punto di rottura

    Per questo errore non basta sapere che “ha fallito”. Serve localizzare il layer. I log più utili dipendono da dove si rompe il flusso.

  • distmgr.log: problemi di distribuzione contenuto, copia file, source path, package inconsistente.
  • pkgxfermgr.log: trasferimento dei package verso i DP.
  • smspxe.log e log correlati, se il media è per scenario PXE/boot legato a task sequence.
  • CreateMedia.log o log del wizard equivalente: il punto esatto in cui la creazione del supporto fallisce.

    • Se il wizard mostra solo 80070002 ma il log indica un file specifico, hai già il bersaglio. Se il log è vago, il problema può essere a monte nel content status o nel source path.

    Un approccio pratico è confrontare il nome del package che fallisce con il suo source folder. Se nel source mancano file rispetto a quanto dichiarato nel package, SCCM non può inventarseli.

    Cause frequenti che vedo davvero sul campo

    Ci sono alcuni pattern che ricorrono spesso. Non sono teorie: sono i casi che, in genere, fanno perdere più tempo del dovuto perché il messaggio finale è sempre lo stesso.

  • Source path spostato o ripulito: una share di rete viene riorganizzata, ma il package in SCCM continua a puntare al vecchio percorso.
  • Dipendenze non incluse: il media include application o task sequence con riferimenti a contenuti secondari non distribuiti.
  • DP non aggiornato: il contenuto è stato modificato ma non ridistribuito, oppure la vecchia versione è rimasta in cache.
  • Permessi insufficienti: l’account usato per leggere il source o scrivere il supporto non ha accesso al percorso.
  • Path troppo lungo o caratteri problematici: meno comune, ma ancora capace di far fallire la copia in alcuni scenari.

    • Una nota pratica: quando il problema nasce dopo una modifica apparentemente innocua, come il rename di una cartella o il refresh di un package, la causa è quasi sempre un riferimento rimasto appeso da qualche parte. SCCM è molto bravo a conservare metadati vecchi, ma non li sistema da solo.

    Come correggere in modo ordinato senza creare danni collaterali

    La correzione migliore è quella che non altera altro oltre al contenuto rotto. Se tocchi package, source e DP insieme senza tracciare cosa hai cambiato, poi non sai più quale passo ha risolto o peggiorato il problema.

  • Verifica il source folder: accertati che il percorso configurato nel package esista e contenga i file previsti.
  • Riposiziona o ripristina i file mancanti: se il source è incompleto, reintegra i file corretti dalla fonte originale.
  • Ridistribuisci il contenuto: forza un aggiornamento verso i DP interessati, senza cambiare altro.
  • Riprova la creazione del media: usa lo stesso wizard e lo stesso set di oggetti per verificare che il problema sia effettivamente rientrato.

    • Se il contenuto è stato aggiornato di recente, conviene fare prima una ridistribuzione controllata su un solo DP e verificare il content status. È più veloce che rigenerare subito il media e poi inseguire un errore identico.

    Controllo rapido lato server, prima di rilanciare il wizard:
- package source esistente
- content status = Success
- spazio libero sufficiente sul volume di destinazione del media

    Se il problema coinvolge una task sequence, apri la sequenza e controlla ogni riferimento a package, application, boot image o driver package. Basta un solo nodo rotto per bloccare la creazione del supporto.

    Quando il problema non è il contenuto ma il percorso del media

    In alcuni casi l’errore compare perché il wizard non riesce a creare il supporto nella destinazione scelta. Anche qui il codice è lo stesso, ma la radice è diversa: cartella non scrivibile, path troppo lungo, spazio insufficiente, share remota non raggiungibile.

  • Verifica che la destinazione del media sia locale e scrivibile.
  • Controlla spazio libero con un comando semplice come Get-PSDrive -PSProvider FileSystem oppure df se il processo gira in ambiente Linux/virtualizzato dedicato a supporti e tooling.
  • Evita percorsi annidati eccessivamente lunghi; prova una destinazione corta, ad esempio C:\Media\.

    • Se il supporto viene scritto su share, prova temporaneamente una destinazione locale. È una mitigazione pulita: separa i problemi di scrittura da quelli di contenuto. Se in locale funziona, il colpevole è il path di destinazione o la rete, non SCCM in sé.

    Metodo di diagnosi rapido in meno di cinque minuti

    Se devi stringere il cerchio velocemente, usa questa sequenza. È lineare e riduce il rischio di cambiare troppe variabili insieme.

  • Controlla il content status dell’oggetto coinvolto: deve essere Success.
  • Apri il log del wizard o distmgr.log e cerca il nome del file o del package che fallisce.
  • Verifica il source path sul file system: il percorso esiste e contiene i file?
  • Prova una destinazione media locale corta e scrivibile.
  • Se il problema resta, ridistribuisci il contenuto su un solo DP e ripeti il test.

    • Questa sequenza ti dice se il problema è a monte, a valle o nel mezzo. Il vantaggio è che non richiede interventi invasivi: stai solo leggendo stato, log e filesystem.

    Prevenzione: come evitare che l’errore torni fuori al prossimo refresh

    Una volta risolto, conviene mettere un paio di regole operative. Non servono procedure lunghe: bastano controlli minimi prima di modificare un package o una task sequence.

  • Non rinominare o spostare i source folder senza aggiornare i package che li usano.
  • Dopo ogni modifica al contenuto, verifica subito il content distribution status.
  • Usa una struttura di source ordinata e stabile, evitando cartelle temporanee o share “creative”.
  • Se il team gestisce più DP, documenta quale contenuto dipende da quale source path.

    • La prevenzione vera, in SCCM, è disciplina sui riferimenti. Il sistema non ama i contenuti volatili: se il file cambia posto senza che il package venga riallineato, prima o poi il conto arriva sotto forma di 80070002.

    Controlli finali prima di chiudere il ticket

    Prima di considerare chiuso il caso, ripeti il test di creazione del supporto con gli stessi parametri che fallivano. Il risultato atteso è semplice: il wizard completa, il file media viene creato, e nei log non compaiono più riferimenti a file mancanti.

  • Rilancia la creazione del media con la stessa configurazione.
  • Controlla che il file di output esista nel path scelto e abbia dimensione coerente.
  • Riapri il log del wizard e verifica assenza di errori 80070002 o di file not found.
  • Se hai ridistribuito contenuto, conferma che il status sia tornato a Success su tutti i DP interessati.

    • Se tutto è verde, annota quale componente era rotto: source, DP, destinazione media o dipendenza. È il dettaglio che evita di rifare la stessa caccia al tesoro alla prossima release.

    Assunzione operativa: il supporto viene creato in un contesto SCCM standard su Windows, con accesso alla console amministrativa e ai log del site server; se il tuo flusso usa percorsi, ruoli o wizard personalizzati, prima mappa il nome del log e il punto esatto in cui viene generato il media.