1 14/10/2026 10 min

Disinstallare un sito primario Configuration Manager non è un’operazione da “click e via”. Se il sito gestisce client attivi, distribuzioni, boundary group e integrazione con un CAS o con un database condiviso, la rimozione va trattata come un change controllato con verifica preliminare, finestra di manutenzione e rollback definito. L’obiettivo non è solo togliere i binari dal server: bisogna evitare che restino riferimenti nel database, account di servizio inutilizzati, certificati orfani, punti di distribuzione non puliti e client che continuano a puntare a un sito inesistente.

La strada corretta dipende dal tipo di sito, dalla topologia e dal motivo della rimozione. In genere si disinstalla un sito primario quando si sta consolidando l’infrastruttura, si sta migrando verso un altro hierarchy, oppure il sito è stato installato in modo errato e va eliminato prima di ricrearlo. La regola pratica è semplice: prima si dismettono i ruoli e si verifica che nessun client o servizio dipenda più dal sito, poi si procede con la rimozione del sito da Console o con il setup in modalità uninstall, e solo alla fine si puliscono i residui operativi.

Quando la disinstallazione è sicura

Un sito primario si può rimuovere in modo ordinato solo se questi punti sono veri: non ci sono client che devono ancora ricevere policy da quel sito, i contenuti necessari sono già stati migrati o non servono più, i ruoli dipendenti sono stati valutati singolarmente, e il database del site server non è più un nodo attivo della gerarchia. Se manca uno di questi elementi, il rischio è lasciare l’ambiente in uno stato incoerente, con console parzialmente funzionanti o client bloccati in fallback.

Prima di toccare il sito, conviene raccogliere tre evidenze minime: la topologia attuale, lo stato dei ruoli, e il numero di client assegnati. In pratica, serve sapere se il sito è standalone o child, se ospita Management Point, Distribution Point, Software Update Point, Reporting Services Point o Asset Intelligence, e se esistono relazioni con altri siti o con un CAS. In assenza di questi dati, non conviene improvvisare.

Verifiche preliminari da fare prima di avviare la rimozione

Il primo controllo è lato console. In Administration > Site Configuration > Servers and Site System Roles verifica quali ruoli sono installati sul server del sito primario. Se ci sono ruoli ancora in uso da altri server, rimuovere il sito senza prima ripulire o riassegnare quei ruoli può lasciare oggetti orfani nella console o nel database.

Il secondo controllo è la presenza di client assegnati. Dal punto di vista operativo, un sito primario che ha ancora client attivi non va eliminato senza aver prima migrato i client verso un altro sito o aver deciso che non devono più ricevere gestione centralizzata. La verifica più semplice è dalla console, ma se vuoi un riscontro rapido lato server puoi controllare i log del site server e il numero di dispositivi assegnati nel database o nei report già disponibili.

Il terzo controllo riguarda i content library e i distribution point. Se il server del sito ospita anche contenuti, la disinstallazione del sito non equivale alla rimozione del contenuto distribuito. Prima di procedere, va chiarito cosa deve essere mantenuto e cosa può essere eliminato. In caso contrario è facile lasciare file residui sotto SMSPKG, SCCMContentLib o percorsi equivalenti, con spazio disco occupato e nessun oggetto che li referenzi più.

Il quarto controllo riguarda gli account di servizio e le dipendenze di autenticazione. Se il sito usa account dedicati per il setup, il connection account o l’accesso al database, questi non vanno cancellati prima della fine della procedura. Vanno invece annotati per un’eventuale disattivazione successiva. Stesso discorso per certificati e binding IIS associati ai ruoli del sito.

Sequenza corretta di rimozione del sito primario

La sequenza più pulita è questa: prima si mettono in sicurezza dipendenze e ruoli, poi si avvia la disinstallazione del sito, infine si esegue la bonifica. Se il sito è standalone e non dipende da un CAS, il setup di Configuration Manager è lo strumento più lineare. Se invece il primario è parte di una gerarchia più ampia, la rimozione può richiedere passaggi aggiuntivi lato padre.

  1. Documenta lo stato iniziale. Esporta la lista dei ruoli, dei boundary group, dei distribution point e dei client assegnati. Conserva anche il nome del site code, il FQDN del site server e il percorso del database SQL. Se serve un rollback, questi dati sono il minimo indispensabile.

  2. Rimuovi o migra i ruoli dipendenti. Sposta i ruoli che devono restare in produzione su un altro server o disinstallali dal site server. In console, passa da Administration > Site Configuration > Servers and Site System Roles e verifica che il server non ospiti più ruoli critici.

  3. Conferma che i client siano migrati o fuori scope. Se il sito deve sparire, i client non devono più essere assegnati ad esso. Controlla assignment, boundary e boundary group. Se necessario, prepara prima la migrazione verso un altro primario o verso un nuovo hierarchy.

  4. Avvia la disinstallazione dal setup di Configuration Manager. Sulla macchina del site server esegui il programma di setup con la modalità di rimozione prevista dalla versione installata. Il comando preciso cambia in base al build e alla topologia, quindi va verificato nella documentazione della tua release o nella schermata del setup. Se il tuo ambiente usa una procedura guidata, segui quella invece di forzare parametri non confermati.

  5. Monitora i log mentre il setup lavora. I log più utili sono in genere sotto C:\ConfigMgrSetup.log o nei log del setup della versione specifica, più i log del sito sotto Logs nel percorso di installazione. Se la disinstallazione si blocca, il primo indizio arriva quasi sempre da lì.

  6. Completa la pulizia dei residui. Verifica servizi Windows rimasti registrati, cartelle di installazione, binding IIS, certificati, account di servizio e oggetti SQL legati al sito. L’obiettivo è evitare che il server venga percepito ancora come site system attivo da strumenti di monitoring o da operatori successivi.

Se il sito è parte di una gerarchia con CAS, la rimozione del primario va coordinata con il livello superiore. In alcuni casi il padre conserva riferimenti fino a quando il child non viene rimosso correttamente e replicato. Se si forza la cancellazione lato server senza il percorso corretto, il risultato tipico è una console con oggetti zombie o con errori di replica.

Comandi utili per verificare lo stato prima e dopo

Non esiste un singolo comando universale per ogni versione e topologia, ma alcuni controlli rapidi aiutano a capire se il server sta ancora esponendo servizi del sito. Su Windows Server puoi verificare i servizi Configuration Manager e il loro stato con PowerShell:

Get-Service | Where-Object {$_.DisplayName -like '*Configuration Manager*'} | Select-Object DisplayName, Status, StartType

Se trovi servizi ancora avviati dopo la disinstallazione, è un segnale che la rimozione non è stata completata o che qualche componente è rimasto registrato. In quel caso non conviene cancellare a mano alla cieca: prima va capito quale ruolo o componente sta trattenendo il servizio.

Per una verifica rapida dei log del setup, puoi controllare la presenza di errori o warning nelle ultime righe del file di log più recente. Un esempio generico con PowerShell è questo:

Get-Content 'C:\ConfigMgrSetup.log' -Tail 80

Se il percorso del log differisce nella tua release, usa quello indicato dal setup o dalla documentazione della build installata. Non dare per scontato che tutte le versioni scrivano negli stessi file.

Errori tipici durante la rimozione

Il primo errore classico è rimuovere il server prima dei ruoli. In questo caso il setup si ferma o lascia oggetti inconsistenti. Il sintomo può essere un errore di prerequisito, un timeout della console o un rollback parziale. La correzione è semplice: reinstallare temporaneamente ciò che manca solo se serve per completare una rimozione pulita, oppure ripristinare lo stato precedente dal backup e ripetere la sequenza corretta.

Il secondo errore classico è dimenticare la replica o l’aggiornamento del database. Se il sito è in una gerarchia, il padre deve sapere che il child non esiste più. Quando questa informazione non viene propagata, compaiono record orfani, errori di console e oggetti non rimovibili. In questi casi il log è la fonte primaria: senza log non si distingue un problema di replica da un problema di permessi SQL.

Il terzo errore è lasciare attivi boundary e boundary group che puntano al sito rimosso. I client possono continuare a cercare un site assignment non più valido, con conseguenze come fallback lento, policy mancanti o registrazioni di errore nei log client. Dopo la rimozione, va verificato che i boundary siano associati al nuovo sito o che non esistano più riferimenti al vecchio site code.

Il quarto errore riguarda i punti di distribuzione e i percorsi di contenuto. Se il server ospitava pacchetti o immagini, questi possono rimanere sul disco anche dopo la disinstallazione. Non è un problema finché il disco non viene riutilizzato, ma diventa un problema quando il team pensa che lo spazio sia stato liberato e invece il volume continua a essere occupato.

Bonifica post-rimozione

Dopo la disinstallazione, la bonifica va fatta con criterio. Prima si controlla che il sito non appaia più in console, poi si verificano i servizi Windows, quindi si puliscono eventuali cartelle residue solo se non servono per audit o per un eventuale reimage del server. La cancellazione manuale delle directory del prodotto va fatta solo quando si è certi che il setup abbia completato la rimozione e che non esistano altre applicazioni che condividano quei percorsi.

Se il server verrà riutilizzato per un nuovo sito, conviene eseguire anche una verifica di rete e di DNS per evitare che il vecchio FQDN o il vecchio site code restino nei record interni. In ambienti con PKI, controlla anche eventuali certificati emissione server, soprattutto se erano stati assegnati in modo specifico al ruolo di Management Point o a IIS.

Per gli ambienti gestiti con standard operativi rigorosi, è utile salvare uno snapshot finale dello stato: elenco ruoli rimossi, file di log del setup, eventuali errori e conferma della cancellazione o disattivazione degli account di servizio. Questo chiude il change in modo tracciabile e riduce le ambiguità quando, mesi dopo, qualcuno chiede perché il sito non esiste più.

Rollback: cosa fare se qualcosa va storto

Il rollback reale non è “annullo la disinstallazione”. Nella pratica, il rollback consiste nel ripristinare il server dal backup o dallo snapshot, oppure nel reinstallare il sito con la stessa site code e configurazione se la procedura e la versione lo consentono. Per questo motivo il backup del database, la copia della config e la documentazione dei ruoli sono indispensabili prima di iniziare.

Se la rimozione è stata avviata ma non conclusa, non continuare con pulizie aggressive finché non hai capito dove si è fermata. Recupera il log del setup, identifica il punto di errore, verifica se la causa è permessi, SQL, replica o dipendenza di ruolo, e solo dopo decidi se completare la disinstallazione o tornare indietro. In un ambiente SCCM, forzare la cancellazione di oggetti senza una diagnosi minima è il modo più rapido per complicare il ripristino.

In sintesi operativa: documenta, svuota le dipendenze, disinstalla con il setup corretto, controlla i log, poi pulisci i residui. Se il sito è in gerarchia o ha client ancora assegnati, non trattarlo come un semplice server da spegnere. L’ordine dei passaggi conta più della velocità.