1 04/11/2026 9 min

Installazione di un sito secondario SCCM: cosa va verificato prima

Un sito secondario in Microsoft Configuration Manager si installa bene solo quando la catena di dipendenze è già pulita: connettività tra parent e child, SQL disponibile, account con i diritti giusti, spazio disco sufficiente e una gerarchia che abbia davvero senso dal punto di vista operativo. Se uno di questi punti è fuori posto, l’installazione tende a fermarsi in modo poco elegante e il troubleshooting diventa più lungo del necessario.

Il punto chiave è questo: il sito secondario non è un’istanza autonoma. Dipende dal sito primario per il controllo gerarchico, per buona parte della configurazione e per la replica dei dati. Quindi la procedura non va letta come un semplice “setup”, ma come un cambio controllato che tocca rete, permessi, SQL, servizi e, in molti casi, la distribuzione dei contenuti verso sedi remote.

Prerequisiti infrastrutturali e di sicurezza

Prima di aprire la console, conviene validare l’assetto minimo. Il server destinato al sito secondario deve essere membro del dominio nella maggior parte degli scenari reali, raggiungibile dal site server primario e sufficientemente dimensionato per il carico atteso. In termini pratici, non basta che “si veda in rete”: servono risoluzione DNS corretta, porte aperte tra i nodi e una latenza coerente con il ruolo che il sito dovrà svolgere.

Controlla anche il disco. Il sito secondario scrive log, database locale se previsto, contenuti e file di supporto. Se il volume di sistema è stretto, l’errore può comparire solo a installazione avviata, quando ormai hai già consumato tempo su una configurazione che andrà rifatta. In produzione è prudente separare almeno log e contenuti dal disco di sistema, quando l’architettura lo consente.

Dal lato sicurezza, usa account con privilegi minimi necessari. Evita credenziali riutilizzate o troppo ampie: il sito secondario non deve diventare un punto di esposizione laterale nella gerarchia. Se usi account dedicati per installazione, documenta chi li possiede, dove sono custoditi e quando vanno ruotati. Non lasciare password in chiaro in note operative o script condivisi.

Flusso logico dell’installazione

La sequenza corretta è semplice: verifica prerequisiti, lancia l’installazione dal site server primario, valida la raggiungibilità del server secondario, conferma la configurazione SQL, controlla che i ruoli si registrino correttamente e infine verifica replica e distribuzione contenuti. Saltare una di queste fasi significa spostare il problema più avanti, non risolverlo.

Installazione dalla console di Configuration Manager

Nella console del sito primario, apri la sezione dell’amministrazione della gerarchia e avvia la procedura per aggiungere un sito secondario. La procedura guidata ti chiederà il nome del server, il sito padre, le opzioni relative a SQL e i dettagli di installazione. In molte organizzazioni questa parte viene fatta da remoto e non interattivamente sul server target: è una scelta sensata, perché centralizza il controllo e riduce gli errori manuali.

Nel wizard, l’elemento più delicato è la scelta del database. Se il sito secondario userà SQL locale, verifica in anticipo che l’istanza sia disponibile, che il servizio sia in esecuzione e che l’account del servizio SQL abbia i permessi richiesti. Se invece l’architettura prevede componenti SQL remote o dedicate, non dare per scontata la compatibilità: controlla sempre versioni, collation e policy di autenticazione.

Quando il wizard propone impostazioni di rete o di replica, evita di accettare valori “di default” senza leggerli. In ambienti distribuiti, la differenza tra una replica efficiente e una lenta spesso sta in dettagli apparentemente banali: compressione, finestre di manutenzione, larghezza di banda disponibile, presenza di proxy o firewall intermedi.

Verifiche immediate dopo l’avvio del setup

Appena l’installazione parte, non aspettare la fine per controllare l’evidenza tecnica. Il primo segnale utile è il log del site server primario, che mostra il tentativo di creazione del nuovo sito e le eventuali anomalie di connettività o autorizzazione. Il secondo è il log locale sul server secondario, dove emergono subito problemi di prerequisiti mancanti, servizi non avviabili o errori di database.

Se vuoi un controllo rapido lato rete, verifica che il server risponda sul nome corretto e che non ci siano problemi di risoluzione DNS o di routing. Un errore di naming può far sembrare guasto il sito quando in realtà è solo un record errato o un alias incoerente.

Esempi di controlli utili, da eseguire dal site server primario o da una macchina con visibilità di rete equivalente:

nslookup sccm-secondary01.contoso.local
ping sccm-secondary01.contoso.local
Test-NetConnection sccm-secondary01.contoso.local -Port 1433

Il risultato atteso è una risoluzione coerente del nome, una risposta ICMP se consentita dalla policy e, soprattutto, una connessione riuscita alla porta SQL se il database è locale o esposto in rete. Se il ping fallisce ma la porta SQL risponde, il problema è probabilmente nelle policy firewall e non nella raggiungibilità reale del server.

Log da leggere subito e cosa cercare

Per un’installazione SCCM, i log sono la vera fonte di verità. Non servono per abbellire il troubleshooting, servono per evitare congetture. I log più utili dipendono dalla fase, ma in generale devi concentrarti su quelli del site server primario e del server destinato al sito secondario. Cerca errori di autenticazione, timeout, fallimenti di copia file, problemi di SQL e riferimenti a prerequisiti mancanti.

Se il setup si blocca durante la creazione del sito, spesso il collo di bottiglia è uno di questi quattro punti: permessi dell’account di installazione, connettività verso SQL, spazio disco insufficiente o configurazione non coerente della gerarchia. La cosa utile non è leggere il log dall’alto verso il basso, ma isolare il primo errore reale, non il sintomo a cascata che viene dopo.

Un criterio operativo semplice: se il log mostra più errori in sequenza, il primo errore cronologico è quasi sempre quello da trattare per primo. Gli altri sono effetti collaterali.

Installazione del ruolo e assegnazione dei componenti

Durante l’installazione, il sito secondario non è solo una voce gerarchica: vengono creati servizi, ruoli e impostazioni che ne determinano il comportamento. Qui è importante distinguere tra capacità minima e capacità operativa reale. Un sito installato ma non pronto a ricevere contenuti o a sincronizzarsi correttamente è, di fatto, ancora incompleto.

Se la tua installazione include distribution point, management point o altri ruoli associati, verifica che siano assegnati secondo il design previsto. Non dare per scontato che il wizard abbia interpretato la tua intenzione correttamente: in ambienti complessi, una scelta sbagliata può lasciare il sito formalmente “green” ma inutilizzabile per i client remoti.

Un errore frequente è confondere il completamento dell’installazione del sito con la piena operatività della replica. Il sito può risultare creato, ma i dati di configurazione e i contenuti possono impiegare ancora un po’ a propagarsi. Per questo la verifica finale deve includere sia la console sia i log di sincronizzazione.

Verifiche di replica e consistenza dati

Dopo l’installazione, il test vero è la replica. Un sito secondario che non riceve correttamente configurazioni, pacchetti o aggiornamenti non risolve il problema di sede remota; lo sposta soltanto in un punto più difficile da diagnosticare. Controlla che gli oggetti arrivino, che i tempi di propagazione siano ragionevoli e che non ci siano code bloccate.

Se vuoi una verifica pratica, confronta nella console la presenza del nuovo sito, lo stato dei ruoli e la visibilità dei contenuti previsti. In parallelo, osserva i log di replica per capire se il ritardo è fisiologico o se c’è un errore strutturale. Un piccolo ritardo è normale; un blocco persistente no.

Quando possibile, valida anche dal punto di vista del client: un dispositivo nella sede collegata deve vedere il percorso corretto verso il punto di distribuzione o verso il management point previsto. Se il client continua a comportarsi come se il nuovo sito non esistesse, il problema potrebbe essere nel boundary, nel boundary group o nella configurazione dei punti di gestione.

Troubleshooting dei problemi più comuni

Se l’installazione fallisce subito, la probabilità più alta è un prerequisito mancante o un permesso insufficiente. Falsifichi rapidamente questa ipotesi controllando i log di setup, la raggiungibilità del server e l’account usato per l’installazione. Se invece il sito si crea ma resta parzialmente non operativo, il sospetto va alla replica o alla configurazione dei ruoli.

Un secondo caso comune è il database. Se SQL non è pronto, la sintomatologia può essere ambigua: installazione lenta, errori intermittenti, servizi che partono e si fermano. Qui la verifica minima è che il servizio SQL sia in esecuzione, che l’istanza risponda e che il disco dedicato non sia saturo.

Terza ipotesi: rete o firewall. Se il server è corretto ma il setup non riesce a completare copie o handshake, il problema spesso non è SCCM ma una porta bloccata tra i nodi. In questi casi la falsificazione è semplice: test di connessione mirati verso le porte coinvolte e controllo delle regole firewall locali e perimetrali.

Rollback e gestione del rischio

Prima di avviare la procedura, considera il blast radius: la creazione di un sito secondario tocca gerarchia, replica, SQL, storage e potenzialmente la distribuzione dei contenuti verso i client della sede remota. Se qualcosa va storto, il rollback non deve essere improvvisato. La regola pratica è avere sempre un punto di ritorno documentato, almeno a livello di configurazione e di stato dei servizi.

Se il setup fallisce in modo precoce, il rollback può essere semplice: arresto della procedura, pulizia dei componenti parzialmente creati e verifica che il sito primario torni allo stato precedente. Se invece il sito è stato creato ma presenta problemi strutturali, prima di rimuoverlo valuta l’impatto su contenuti, client e replica. In alcuni casi conviene correggere la causa e completare l’installazione, invece di distruggere e ricreare tutto.

Una buona pratica è conservare uno snapshot operativo della configurazione prima del cambio, almeno sotto forma di export della console, note sui ruoli assegnati e copia dei parametri usati nel wizard. Non è glamour, ma in produzione fa risparmiare ore.

Checklist finale operativa

Prima di considerare chiuso il lavoro, verifica questi punti in ordine:

  1. Il server secondario risolve correttamente il nome e raggiunge il site server primario.
  2. SQL è disponibile, coerente con il design previsto e senza errori nei log di servizio.
  3. L’installazione del sito è completata e il nuovo nodo compare correttamente in console.
  4. Replica e sincronizzazione mostrano attività normale, senza code bloccate o errori ripetuti.
  5. I ruoli associati risultano online e i client della sede remota vedono il percorso atteso.

Assunzione di lavoro: il sito secondario è stato installato in un ambiente SCCM già funzionante, con gerarchia primaria sana, DNS affidabile, connettività tra i nodi e accesso amministrativo alla console di Configuration Manager.