Guida all’installazione di SCCM 2012 SP1

Scelta dell’architettura prima dell’installazione

SCCM 2012 SP1 non si installa bene “a tentativi”: la qualità del risultato dipende più dalla preparazione dell’infrastruttura che dal setup in sé. Prima di avviare il wizard, definisci con precisione il ruolo del server, il perimetro della site hierarchy e la collocazione dei servizi dipendenti. Se parti con un singolo Primary Site, la finestra di semplicità è ampia, ma alcuni errori di base diventano costosi da correggere dopo, soprattutto su SQL, DNS, AD e permessi.

Per un’installazione pulita di SCCM 2012 SP1, l’obiettivo minimo è questo: un server dedicato o quasi dedicato, un’istanza SQL compatibile e raggiungibile, un dominio AD sano, record DNS corretti, e account di servizio separati con privilegi limitati ma sufficienti. Se uno di questi punti è ambiguo, il setup può andare avanti e lasciarti problemi latenti che emergono solo quando inizi a distribuire client o content.

Prerequisiti di base e controlli sull’ambiente

Verifica subito sistema operativo, patch level e prerequisiti installati. SCCM 2012 SP1 richiede un ambiente Windows Server coerente con la versione supportata e con .NET, IIS e componenti aggiuntivi pronti. La tentazione di lasciare che il wizard “sistemi tutto” è cattiva: alcuni prerequisiti vengono rilevati tardi e, in presenza di policy restrittive, il setup si ferma a metà con messaggi poco utili.

Controlla anche la risoluzione nome/IP del server, la reachability verso domain controller, SQL e gli eventuali server remoti. Un errore di DNS o una latenza anomala verso SQL non impediscono sempre l’installazione, ma spesso provocano timeout o comportamenti intermittenti nei ruoli successivi.

Check rapidi da fare prima del setup:

• nome host stabile e coerente con il dominio;
• record DNS forward e reverse aggiornati;
• ora sincronizzata con il dominio;
• spazio disco adeguato su sistema, SQL e content library;
• antivirus con esclusioni pianificate per cartelle e processi SCCM/SQL.

SQL Server: il punto che determina metà dei problemi futuri

La scelta di SQL Server è una delle decisioni più importanti dell’intera installazione. SCCM 2012 SP1 supporta una specifica combinazione di versioni e patch di SQL; non basta che SQL “parta”. Devi verificare compatibilità, collation, memoria, istanze e collocazione fisica. Una collation sbagliata è uno degli errori più fastidiosi da intercettare tardi.

In pratica, per un Primary Site standard conviene usare un’istanza dedicata o comunque ben separata da altri carichi. Imposta memoria massima per SQL, evita che consumi tutta la RAM del sistema e non usare un’istanza con configurazioni ereditate da ambienti test poco puliti. Se SQL vive su un server remoto, valuta con attenzione latenza, throughput del disco e affidabilità della rete.

Verifiche minime lato SQL:

• collation coerente con i requisiti di Configuration Manager;
• istanza raggiungibile da SCCM con TCP/IP attivo;
• spazio su data, log e tempdb;
• account del setup con diritti sufficienti per creare database e oggetti;
• backup strategy già definita prima di produrre la prima site database.

Se vuoi validare la connettività da PowerShell o da una shell amministrativa, un test semplice è questo:

Test-NetConnection -ComputerName sql01.contoso.local -Port 1433

Se il test fallisce, non forzare il setup: prima risolvi firewall, routing, listener o istanza nominata. In caso di SQL remoto, il blast radius di una modifica errata può coinvolgere anche altri servizi che condividono l’istanza.

Account, permessi e deleghe: meno privilegi, meno sorprese

Il setup di SCCM 2012 SP1 richiede account distinti per attività diverse: installazione, servizi, pubblicazione in AD, accesso a SQL e distribuzione contenuti. Non usare un singolo account “tuttofare” se puoi evitarlo. La separazione dei ruoli aiuta sia in sicurezza sia nel troubleshooting, perché rende più chiaro quale componente stia fallendo.

In un’installazione classica, gli account più rilevanti sono il computer account del server SCCM, l’account che esegue il setup, l’account SQL service, e l’eventuale account per l’accesso ai domain services. Se usi gruppi e deleghe in AD, prepara in anticipo le OU e le autorizzazioni necessarie per la pubblicazione dei record e la gestione dei client.

Evita di inserire credenziali in chiaro in documenti o note operative. Se devi passare parametri a script o automazioni, usa vault o meccanismi equivalenti di redazione e rotazione.

Componenti Windows da abilitare prima del wizard

Molti setup falliscono non per SCCM, ma perché IIS e i componenti correlati non sono completi. Prima di lanciare l’installer, abilita i ruoli e le feature richieste dal server. Su Windows Server la lista esatta varia in base al ruolo che ospiterai, ma in un Primary Site tipicamente servono IIS, ASP.NET, BITS, RDC, .NET Framework e altri componenti di supporto.

Un approccio pratico è preparare il server con PowerShell e poi verificare lo stato dei feature installati. Esempio:

Get-WindowsFeature Web-Server, Web-Windows-Auth, Web-Metabase, NET-Framework-Features, BITS, RDC

Se qualche feature risulta assente, installala prima di proseguire. Il vantaggio è semplice: il wizard di SCCM si concentra sul proprio lavoro e non deve fare remediation dell’OS mentre stai cercando di capire perché un ruolo si ferma a metà.

Preparazione dell’Active Directory e dei record DNS

La parte AD è spesso sottovalutata. SCCM usa AD per pubblicare informazioni di site e per semplificare la discovery dei client. Se il dominio è sporco o i permessi di pubblicazione sono incompleti, l’installazione può comunque terminare, ma poi i client non scoprono correttamente il management point o non trovano i boundary corretti.

Assicurati che il nome del server SCCM sia risolvibile in DNS e che i record siano allineati con l’IP corretto. Un controllo base è questo:

nslookup sccm01.contoso.local

Se il risultato mostra un IP errato o un alias non previsto, correggi il record prima di installare. In ambienti con più VLAN o con DNS secondari, fai anche un controllo di reverse lookup: non è obbligatorio per il wizard, ma aiuta molto nella diagnostica successiva.

Installazione del Primary Site: sequenza pratica

Una volta completata la preparazione, puoi avviare il setup di SCCM 2012 SP1. Nella maggior parte dei casi, il percorso più lineare è installare un Primary Site standalone e poi aggiungere i ruoli necessari. Non ha senso complicare la gerarchia se non hai un’esigenza reale di child site o di separazione geografica rigida.

La sequenza operativa corretta è questa:

1. monta il media di installazione e avvia il setup come amministratore;
2. scegli l’installazione di un nuovo site;
3. seleziona il tipo di site corretto, in genere Primary Site;
4. indica il codice site e il nome del server;
5. configura il database SQL e la relativa istanza;
6. definisci i path di installazione e i file di supporto;
7. verifica il riepilogo e avvia la preinstall check finale.

Durante il wizard, presta particolare attenzione al database. Il path dei file MDF/LDF, la collocazione del tempdb e la separazione dai dischi di sistema sono scelte che incidono poi su performance e manutenzione. Se hai storage separato, usalo. Se non ce l’hai, almeno evita di far convivere OS, SQL data e content library sullo stesso volume senza una ragione precisa.

Se il wizard propone controlli preliminari, non ignorarli. Un warning su SQL, su IIS o su permessi AD è un segnale utile, non una formalità. Chi installa in fretta e “rimanda” quasi sempre finisce a fare troubleshooting con il servizio già esposto agli utenti.

Ruoli principali dopo l’installazione base

Terminata l’installazione del site, il lavoro vero comincia con i ruoli. Management Point, Distribution Point, Software Update Point, Endpoint Protection e altri componenti vanno aggiunti con criterio, non tutti insieme solo perché il wizard lo consente. Ogni ruolo introduce dipendenze, porte, storage e log da presidiare.

Per esempio, il Distribution Point richiede attenzione su spazio disco e strategia di content library; il Software Update Point si appoggia a WSUS e a una gestione precisa dei metadati; il Management Point deve essere testato con i client in rete reale, non solo da localhost. Se distribuisci contenuti pesanti, considera da subito la saturazione del link e la finestra di replication.

Una buona regola è aggiungere un ruolo alla volta e verificare i log corrispondenti. In SCCM il valore operativo dei log è altissimo: se qualcosa non funziona, il primo passo non è riavviare il server, ma leggere il file giusto. I log principali sono sotto la directory di installazione di Configuration Manager, in particolare nell’area `Logs` del site server.

Log e controlli post-installazione che contano davvero

Dopo il setup, verifica lo stato del servizio e la salute del site prima di procedere con i client. Il fatto che il wizard sia finito non significa che il sistema sia operativo. I controlli minimi devono coprire servizi, database, componenti web e accesso alla console.

Un set di controlli pratici include:

• servizi SCCM avviati e senza restart loop;
• accesso alla console amministrativa senza errori di connessione;
• database site creato e accessibile in SQL;
• log del setup senza errori bloccanti;
• Management Point raggiungibile via rete dal client test.

Se vuoi una verifica rapida lato sistema, controlla che i servizi principali siano presenti e in esecuzione:

Get-Service | Where-Object {$_.DisplayName -like '*Configuration Manager*' -or $_.Name -like 'SMS*'}

Per i log, non serve memorizzare tutto a mente: l’importante è sapere dove cercare. I file più utili sono quelli del setup, del site control e dei ruoli installati. Se un ruolo non parte, il log spesso dice già se il problema è permessi, prerequisiti mancanti, database o rete.

Problemi tipici e come evitarli in fase di installazione

Ci sono alcuni errori ricorrenti che si possono prevenire quasi sempre. Il primo è installare SCCM su un server con ruoli “misti” e troppe dipendenze storiche. Il secondo è trascurare SQL e scoprire dopo che la collation o la memoria non sono corrette. Il terzo è dare per scontato che DNS e AD siano perfetti, quando invece un record sbagliato o una delega incompleta possono sabotare discovery e management.

Un altro errore frequente è non prevedere il dimensionamento iniziale. Anche in una piccola infrastruttura, SCCM genera database, content library, log e traffico che crescono rapidamente. Se il disco è sottodimensionato, il primo sintomo può essere un rallentamento, ma la conseguenza reale è un errore in cascata su servizi e distribuzione contenuti.

Infine, non trascurare l’aggiornamento del sistema e dei prerequisiti di sicurezza. Un ambiente vecchio, senza patch coerenti, è più fragile sia in installazione sia in esercizio. Se il server è esposto a reti esterne o segmenti non fidati, il tema sicurezza non è opzionale: riduci la superficie d’attacco, limita le aperture di firewall e conserva una traccia dei cambiamenti.

Checklist operativa finale

Prima di considerare conclusa l’installazione, verifica questa sequenza minima:

1. SQL compatibile, raggiungibile e correttamente dimensionato;
2. feature Windows richieste installate;
3. DNS e AD coerenti con il nome del site server;
4. setup completato senza errori bloccanti nei log;
5. console accessibile e servizi principali in esecuzione;
6. primo ruolo aggiuntivo installato e validato con test reale.

Se uno di questi punti non torna, fermati lì e chiudi il gap prima di andare avanti. In SCCM è molto più economico correggere l’architettura iniziale che inseguire i sintomi dopo che i client hanno iniziato a registrarsi male o a scaricare contenuti da una piattaforma parzialmente configurata.

Assunzione operativa: questa guida parte da un’installazione nuova di SCCM 2012 SP1 su Windows Server in dominio Active Directory, con SQL disponibile e accesso amministrativo controllato.