Rimuovere un Distribution Point SCCM con PowerShell

La rimozione di un Distribution Point in SCCM non va trattata come una semplice cancellazione di ruolo. Se il punto di distribuzione è ancora referenziato da boundary group, contenuti, package o task sequence, la dismissione può lasciare riferimenti sporchi, errori di distribuzione e code di stato che poi richiedono più tempo da ripulire del lavoro iniziale. Con PowerShell si può automatizzare la parte ripetitiva, ma il flusso corretto resta lo stesso: verificare l’impatto, interrompere l’uso del nodo, rimuovere il ruolo, poi controllare che la console e i log riflettano davvero la modifica.

Qui l’obiettivo non è “fare presto”, ma fare una rimozione reversibile e tracciabile. In produzione, un DP va tolto solo dopo aver confermato che nessun client dipende da quel server per il contenuto corrente e che un eventuale fallback verso altri DP è già disponibile. Se mancano informazioni sul sito, sulla site code o sul nome esatto del server, non conviene improvvisare: bisogna prima identificarli dalla console o dai log del provider SMS.

Quando ha senso rimuovere un Distribution Point

Ci sono tre casi tipici. Il primo è il decommissioning di un server che non deve più ospitare ruoli SCCM. Il secondo è la sostituzione con un nuovo DP, spesso per upgrade hardware, cambio rete o migrazione datacenter. Il terzo è la pulizia di un nodo aggiunto per errore o rimasto in stato incoerente dopo un test. In tutti e tre i casi la sequenza corretta è la stessa: prima si riduce l’utilizzo del DP, poi si rimuove il ruolo, infine si verifica che il sito abbia completato la pulizia delle associazioni.

Se il DP è anche pull distribution point, punto PXE, peer cache source o ospita contenuti con dipendenze particolari, va trattato con più attenzione. Non basta togliere il ruolo principale: bisogna verificare anche le funzionalità collaterali che possono continuare a generare traffico o errori dopo la rimozione.

Prerogative minime prima di toccare il ruolo

Prima di eseguire la rimozione, conviene raccogliere questi dati minimi:

La verifica si può fare dalla console, ma spesso è più comodo partire dai log del sito e dal provider WMI. Se non si conosce il nome del provider o il path della console, si può comunque lavorare dal server del site con gli strumenti standard di Configuration Manager. Il punto non è usare sempre PowerShell, ma usarlo dove riduce il rischio di errore manuale.

Verifica dell’impatto prima della rimozione

La prima cosa da controllare è se il DP sta ancora distribuendo contenuti o se è ancora selezionato come destinazione da qualche boundary group. In console, il percorso tipico è Administration > Distribution Points per lo stato del ruolo, e Administration > Hierarchy Configuration > Boundary Groups per le preferenze di distribuzione. Se il nodo è ancora presente come preferenza, rimuoverlo dal boundary group prima della dismissione evita che i client continuino a tentare download verso un server destinato a sparire.

Dal lato operativo, il controllo rapido può essere fatto con PowerShell sul site server. Il modulo di Configuration Manager espone i cmdlet del provider SMS; una volta caricato il modulo e cambiata la location sul drive del sito, si possono interrogare i Distribution Point registrati.

Import-Module