Correggere l'errore 0x80070070 nei deployment degli aggiornamenti SCCM

Quando un deployment di aggiornamenti SCCM fallisce con 0x80070070, il punto non è “l’update è rotto”: il codice indica quasi sempre spazio insufficiente. La trappola è che lo spazio può mancare in posti diversi: sul disco del client, nella cache del Content Transfer Manager, nella partizione di staging del software update, oppure sul volume dove il client scrive i file temporanei durante il download e la preparazione. Se si interviene alla cieca, si finisce a pulire il posto sbagliato e il problema torna al giro successivo.

Leggere il sintomo nel punto giusto

In SCCM il codice 0x80070070 non è una diagnosi completa, è un indizio. Il comportamento atteso è semplice: il client scarica il contenuto, lo valida, prepara l’installazione e l’update entra in fase di enforcement. L’osservato, invece, è un fallimento in una di queste fasi con errori di spazio, download interrotto o staging non completato. La differenza pratica la fanno i log: non basta vedere il codice nel console status, serve capire quale path ha esaurito la capacità.

Le tre cause più probabili, in ordine, sono queste: 1) volume di sistema o volume di lavoro quasi pieno sul client; 2) cache CCMCache o directory temporanee insufficienti per il pacchetto; 3) contenuto update troppo grande rispetto al disco disponibile, spesso su endpoint con storage ridotto o OneDrive/temporary files già saturi. La falsificazione rapida si fa in meno di cinque minuti con una combinazione di stato disco, log client e dimensione del contenuto.

Dove guardare prima: client, cache e staging

Il primo controllo è banale ma decisivo: spazio libero sul client. Se il sistema operativo gira con pochi GB residui, l’update può fallire anche se la cache SCCM è formalmente configurata bene. Su Windows, un controllo rapido del disco di sistema e dei volumi secondari chiarisce subito se il margine è troppo basso.

wmic logicaldisk get caption,freespace,size,volumename

Se il disco di sistema o il volume che ospita la cache è sotto pressione, il sospetto si rafforza. Se invece lo spazio è abbondante, il problema si sposta sulla cache e sui file temporanei del client. I log da leggere sono quelli del client Configuration Manager: C:\Windows\CCM\Logs\CAS.log, ContentTransferManager.log, DataTransferService.log, UpdatesDeployment.log e PatchDownloader.log. Il segnale utile non è il solo 0x80070070, ma la riga che mostra il path o la dimensione del contenuto quando il download viene tentato.

Un esempio tipico è un contenuto update che supera la dimensione libera della cache. SCCM non “magicamente” comprime il problema: se il pacchetto richiede più spazio di quello disponibile per staging e decompressione, il client si ferma. In questi casi il fallimento può comparire anche quando il disco sembra avere qualche GB libero, perché il margine effettivo non basta tra cache, temporanei e spazio richiesto per l’installazione.

Verifiche mirate sui log SCCM

La diagnostica efficace parte dal client, non dalla console. I log da cercare sono quelli che mostrano il punto di rottura. Se il download non parte, il problema può essere nel Content Access o nella policy. Se il download parte e si interrompe, il collo di bottiglia è quasi sempre spazio o corruzione del contenuto locale.

Controlli pratici:

• CAS.log: verifica assegnazione e accesso al contenuto.

• ContentTransferManager.log: conferma richiesta e stato del download.

• DataTransferService.log: mostra trasferimento BITS e possibili interruzioni.

• UpdatesDeployment.log: collega il deployment al fallimento effettivo.

• PatchDownloader.log: utile quando il problema nasce già nel recupero degli update.

Se vuoi un filtro rapido senza aprire tutto a mano, cerca direttamente il codice o le parole chiave dello spazio insufficiente.

findstr /i /c:"0x80070070" /c:"not enough space" /c:"insufficient" C:\Windows\CCM\Logs\*.log

Atteso: una o più righe che collegano il codice a un path, a una dimensione richiesta o a una directory temporanea. Se i log non mostrano nulla di utile, il gap non va inventato: va chiuso aprendo il dettaglio del deployment in console e verificando l’ID del pacchetto, la dimensione del content e il boundary group coinvolto.

La cache CCM: quando il problema è più piccolo di quanto sembra

La cache SCCM è spesso la vera causa. Se la dimensione della cache è troppo bassa rispetto al contenuto distribuito, il client prova a scaricare e poi fallisce in fase di staging. Il punto non è solo “aumentare la cache”: serve capire se il contenuto viene rimosso troppo presto, se il client ha più deployment concorrenti o se il disco è già occupato da altri file temporanei.

La verifica minima è vedere la cache configurata sul client e confrontarla con la dimensione del contenuto update. Se si usa il Configuration Manager Control Panel, il percorso è nel pannello Configuration Manager del client, scheda relativa alla cache. In alternativa, lato console, si può controllare il deployment type o il software update group e la dimensione totale del contenuto distribuito.

Se la cache è insufficiente, la correzione più pulita è aumentarla in modo reversibile, senza toccare il contenuto. È un change controllato, non un fix a caso: si modifica la dimensione della cache, si osserva un nuovo tentativo di download e si verifica se il client supera la fase di staging. Il blast radius è limitato al singolo endpoint o al gruppo ristretto su cui si applica la policy.

Quando il problema è nel volume di sistema

Molti ambienti trattano il disco C: come se fosse infinito, poi scoprono che gli aggiornamenti falliscono perché Windows Update, SCCM e altri agenti condividono lo stesso spazio. Se il volume di sistema è sotto una soglia critica, il client può non riuscire a decomprimere il pacchetto, scrivere i file temporanei o completare la fase di installazione.

Qui la mitigazione minima e reversibile è liberare spazio in modo sicuro: rimuovere file temporanei, verificare l’ingombro di cartelle note e, se presente, spostare o ridurre cache non essenziali. Non si parte da pulizie aggressive o da script distruttivi. Prima si misura con precisione dove sta finendo lo spazio.

powershell -NoProfile -Command "Get-PSDrive C | Select-Object Used,Free"

Se il margine libero resta troppo basso anche dopo una pulizia minima, la vera soluzione è strutturale: aumentare il disco della VM, rivedere il baseline di spazio libero richiesto per gli endpoint o ridurre il peso dei pacchetti distribuiti. In ambienti con storage ridotto, gli update cumulativi moderni possono richiedere una soglia più alta di quella prevista anni fa.

Contenuto update troppo grande o distribuzione non ottimizzata

Non tutti i deployment sono uguali. Un software update group con molti cumulative update, language pack o componenti opzionali può produrre contenuti pesanti. Se il boundary group o il distribution point non sono ben allineati, il client può ritentare il download, saturare la cache e poi fallire con 0x80070070. Il sintomo è spesso intermittente: alcuni client completano, altri no, in funzione dello spazio residuo e della concorrenza delle attività.

Qui conviene verificare due cose: la dimensione reale del content e la presenza di deployment sovrapposti. In console, il software update group e il deployment status devono essere confrontati con la capacità media dei client target. Se il parco macchine include endpoint con dischi piccoli, vale la pena segmentare i deployment o escludere temporaneamente i dispositivi al limite fino a quando non vengono sistemati.

Questa non è solo una questione di spazio: è anche di igiene del catalogo. Distribuire troppo contenuto a troppe macchine con profili di storage diversi è un classico modo per trasformare un problema di capacity in una coda di errori apparentemente casuali.

Sequenza di correzione consigliata

Il percorso più sicuro è questo: prima si conferma il punto di esaurimento, poi si applica la correzione minima, infine si scala. Non il contrario.

1. Controlla lo spazio libero del client con un comando affidabile o con l’inventario del sistema. Se il disco è vicino al limite, il problema è già plausibile.

2. Apri i log del client e cerca il messaggio legato a 0x80070070, al path temporaneo o alla cache. Se il log mostra un download interrotto per spazio, hai la conferma.

3. Verifica la dimensione della cache SCCM e confrontala con il contenuto del deployment. Se la cache è sottodimensionata, aumentala in modo graduale.

4. Se il volume di sistema è saturo, libera spazio con interventi reversibili e controllati. Evita pulizie massive senza backup o senza sapere cosa stai rimuovendo.

5. Rilancia il deployment su un numero limitato di endpoint e osserva se la fase di download e staging completa.

Il rollback, in questo caso, è semplice: se l’aumento della cache o la variazione di policy non risolve, riporti la configurazione al valore precedente. Se hai liberato spazio, non c’è nulla da “rollbackare”, ma devi documentare cosa è stato rimosso per evitare che il problema venga mascherato e torni al ciclo successivo.

Controlli finali che evitano falsi positivi

Un fix è valido solo se il client passa davvero dalla fase di download alla fase di installazione senza ricadere nello stesso codice. Il controllo finale non è “il deployment è verde in console”, ma una verifica sul singolo endpoint e su un piccolo campione rappresentativo.

Verifiche finali utili:

• Il nuovo tentativo non produce più 0x80070070 nei log client.

• La cache resta sotto una soglia sana dopo il download.

• Lo spazio libero sul volume di sistema non scende sotto il minimo operativo.

• Il deployment passa a stato Success o almeno supera la fase di download/staging.

Se il problema persiste dopo questi controlli, il gap da chiudere è quasi sempre uno di questi: log incompleti, contenuto non aggiornato sul distribution point, oppure un endpoint con storage troppo piccolo per il carico reale. In quel caso la correzione non è più locale, ma di architettura del deployment o di sizing dei client target.

Regola pratica da portarsi a casa

Con SCCM, 0x80070070 non va trattato come un errore generico di installazione. È quasi sempre un segnale di capacità: disco, cache o staging. Se parti dai log del client, confronti la dimensione del contenuto con la cache disponibile e misuri lo spazio reale del volume, arrivi alla causa senza tentativi alla cieca. E quando il problema è strutturale, la soluzione non è “riprovare”: è riallineare dimensione del contenuto, spazio disponibile e profilo dei client che riceve il deployment.