Come cancellare i contenuti delle applicazioni dalla cache SCCM

Se per “cache SCCM” intendi i contenuti distribuiti ai client, il punto non è cancellare a caso: devi distinguere tra cache del client, contenuti sul distribution point e metadati di distribuzione. Sono tre cose diverse, con effetti diversi. Nella pratica, quando un pacchetto resta bloccato, si vuole quasi sempre liberare spazio sul client o forzare un nuovo download; quando invece il problema è lato infrastruttura, la pulizia va fatta sul content library del distribution point o con una redistribuzione del contenuto.

La regola utile è semplice: prima identifichi dove vive il problema, poi svuoti solo il livello giusto. Se cancelli la cache del client, il danno è limitato a quel computer e il contenuto verrà riscaricato. Se tocchi il distribution point o la libreria contenuti senza piano, puoi interrompere la distribuzione a molti client. Per questo conviene ragionare sempre per layer: client, site server, distribution point, database.

Cache del client SCCM: cosa stai davvero cancellando

La cache del client Configuration Manager è lo spazio locale dove il client salva i file scaricati per applicazioni, task sequence, update e altri contenuti. Di default è gestita dal componente CCMCache e vive in un percorso simile a C:\\Windows\ccmcache o comunque in una directory configurata nel client. Il contenuto può essere rimosso manualmente, ma il modo corretto dipende da quanto vuoi essere preciso.

Se il tuo obiettivo è liberare spazio, puoi cancellare i file della cache; se invece vuoi evitare di spezzare una distribuzione in corso, devi prima capire se il contenuto è ancora referenziato da un’installazione attiva. Un client può rigenerare la cache in autonomia, ma non può ricostruire un contenuto se il distribution point non lo serve più o se il package è stato rimosso senza aggiornare le distribuzioni.

Metodo sicuro: pulizia dal client con il controllo della cache

Il modo più pulito è intervenire sul client usando gli strumenti esposti da Configuration Manager o tramite WMI/PowerShell, così eviti di cancellare file che il client sta ancora usando. Se hai accesso al computer interessato, verifica prima la dimensione della cache e i contenuti presenti.

Controllo rapido della cache:

Get-WmiObject -Namespace root\\ccm\\SoftMgmtAgent -Class CacheConfig | Select-Object Location, Size, MaxCacheSize

Su ambienti più recenti puoi usare anche CIM, ma il concetto non cambia: cerchi percorso, dimensione massima e stato. Se la cache è piena o quasi piena, il client può fallire il download di nuovi contenuti o cancellare automaticamente elementi meno recenti, con risultati non sempre prevedibili.

Per vedere cosa c’è dentro, usa il namespace CCM e non il file system a occhi chiusi. I metadati del client ti dicono quali elementi sono registrati e quali sono in uso. Se trovi contenuti vecchi, legati a deployment conclusi o a task sequence non più usate, puoi rimuoverli con più serenità.

Eliminare contenuti dalla cache client senza improvvisare

Se devi forzare la cancellazione, il metodo più corretto è usare l’interfaccia del client o un’azione amministrata via script, non cancellare a mano la directory a runtime. La rimozione manuale del contenuto può funzionare, ma è la soluzione più grezza: se il client sta ancora usando un file, puoi lasciare residui o generare errori di download successivi.

Una procedura ragionevole è questa: prima controlli quali elementi occupano spazio, poi rimuovi solo quelli non più necessari, infine forzi una nuova valutazione del deployment. Se il contenuto è ancora richiesto, il client lo riscarica dal distribution point. Se non lo è più, la pulizia libera spazio senza effetti collaterali.

Esempio di approccio operativo con PowerShell sul client, da usare con cautela e solo dopo aver verificato il contenuto interessato:

Get-CimInstance -Namespace root\ccm\SoftMgmtAgent -ClassName CacheConfig | Select-Object Location, Size, MaxCacheSize

Per l’individuazione dei pacchetti, i log del client sono più affidabili della memoria dell’operatore. I file da controllare sono tipicamente in C:\Windows\CCM\Logs, in particolare CAS.log, ContentTransferManager.log e DataTransferService.log. Se un download fallisce, lì trovi se il client sta cercando un content ID non più valido, se il DP risponde male o se il problema è di rete.

Quando il problema non è la cache del client

Molti chiamano “cache SCCM” anche ciò che in realtà è un problema di distribuzione dei contenuti. Se su più client un’applicazione non parte, non è sensato svuotare la cache su ogni macchina: devi verificare se il contenuto è stato distribuito correttamente al distribution point, se il boundary group è corretto e se il package è ancora referenziato dal deployment.

Gli indicatori tipici sono questi: errori identici su più client, assenza di contenuto su uno o più DP, stato di distribuzione non riuscito nella console, oppure un client che prova a scaricare da un DP fuori rete o non raggiungibile. In questi casi la pulizia della cache client è solo un tampone temporaneo: il problema torna al primo nuovo download.

Qui la verifica minima è lato console SCCM: apri il deployment, controlla lo stato di distribuzione, verifica il content status e confronta il DP assegnato con il boundary del client. Se il contenuto non è presente sul DP corretto, la soluzione non è svuotare cache ma ridistribuire il contenuto o correggere il boundary.

Pulizia della content library sul distribution point

Se il problema è sul distribution point, la cache del client non c’entra. Il DP conserva i contenuti nella content library e nei file di staging; se questi si corrompono, si saturano o restano incoerenti con il database, la distribuzione fallisce a monte. In questo scenario la pulizia non si fa a mano cancellando cartelle, perché rischi di rompere l’indice dei contenuti.

La via corretta è usare gli strumenti di manutenzione del ruolo e, se necessario, rimuovere e ridistribuire il contenuto dal console. Prima di fare qualsiasi intervento, controlla i log del DP, in particolare quelli relativi alla distribuzione contenuti e alla gestione della libreria. Se trovi errori di hash, file mancanti o problemi di accesso al volume, la causa è spesso più strutturale di una semplice cache piena.

Un caso frequente è il DP con spazio disco insufficiente: il contenuto viene parzialmente scritto, poi la distribuzione fallisce e i client iniziano a scaricare in modo intermittente. Qui la metrica da guardare è lo spazio libero sul volume del DP e il numero di content jobs in errore. Prima liberi spazio in modo controllato, poi ridistribuisci il contenuto.

Scenario operativo: un’app non si installa più sui client

Immagina un’applicazione distribuita che da ieri fallisce con errore di download su alcuni endpoint. La tentazione è svuotare la cache del client e riprovare. Può anche aiutare, ma solo se il contenuto scaricato è corrotto localmente o se il client ha una vecchia referenza. Se invece il DP serve un content ID rotto, cancellare la cache fa solo ripetere il fallimento.

La sequenza corretta è questa: controlli il log del client, verifichi il codice errore e capisci se il fallimento avviene nella fase di locazione del contenuto o in quella di trasferimento. Se l’errore è di locazione, guardi boundary e DP. Se è di trasferimento, guardi rete, spazio cache e integrità del contenuto. Solo dopo, se serve, svuoti la cache del client e forzi un nuovo tentativo.

Quando fai il retry, osserva se il client cambia sorgente o se continua a puntare allo stesso DP. Se il comportamento non cambia, il problema è probabilmente upstream e non locale. Questo evita la classica sequenza di “cancella tutto e spera”, che in SCCM produce più rumore che risultati.

Comandi utili e verifiche rapide

Per una diagnosi iniziale sul client, questi controlli sono quelli che danno più segnale in meno tempo:

Get-CimInstance -Namespace root\ccm\SoftMgmtAgent -ClassName CacheConfig | Select Location, Size, MaxCacheSize
Get-ChildItem 'C:\Windows\CCM\Logs' | Sort-Object LastWriteTime -Descending | Select-Object -First 10 Name, LastWriteTime
Get-Content 'C:\Windows\CCM\Logs\CAS.log' -Tail 50
Get-Content 'C:\Windows\CCM\Logs\ContentTransferManager.log' -Tail 50

Se vuoi verificare la connettività verso il DP, un test semplice è controllare che il client risolva e raggiunga il server giusto. Non serve fare troubleshooting “a sentimento”: se il download fallisce, devi sapere se il nome del DP è corretto, se la porta è aperta e se il traffico passa dal percorso previsto.

Se il problema è solo spazio cache, la metrica da osservare prima e dopo è la dimensione occupata dalla cache e il numero di download falliti. Se invece tocchi il deployment o il DP, la metrica utile è il tasso di successo della distribuzione e il numero di client che completano l’installazione dopo la correzione.

Rischi, blast radius e rollback

La pulizia della cache sul client ha blast radius basso: impatta quel solo endpoint, ma può causare un nuovo download del contenuto e quindi consumo di banda. Il rollback, in senso stretto, non esiste perché stai rimuovendo dati temporanei; la mitigazione è semplicemente lasciare che il client riscarichi il contenuto o ripristinare manualmente il file se ne hai ancora una copia valida.

La pulizia o la redistribuzione lato distribution point ha blast radius più ampio. Prima di intervenire, conviene esportare lo stato del deployment dalla console e tenere traccia del content ID interessato. Se qualcosa va storto, il rollback è la ridistribuzione del pacchetto originale o la riabilitazione del contenuto precedente, non la cancellazione cieca di cartelle sul server.

Assunzione: l’obiettivo è rimuovere contenuti obsoleti o corrotti senza interrompere distribuzioni attive; se hai un ambiente con più DP e boundary complessi, la verifica del content status in console va fatta prima di qualunque pulizia locale.