Installare SQL Server per SCCM 2012 SP1

Installare SQL Server per SCCM 2012 SP1 senza farsi male

La parte che rompe più spesso un’installazione di SCCM 2012 SP1 non è il setup di Configuration Manager, ma il database SQL preparato male. Se l’istanza è sbagliata, la collation non è quella prevista, i servizi non hanno i permessi giusti o il disco è già saturo, il risultato è sempre lo stesso: installazione lenta, errori ambigui e problemi che emergono dopo il go-live. Qui conviene essere rigidi: prima si decide il profilo dell’istanza SQL, poi si installa, poi si verifica che SCCM la veda nel modo atteso.

Il punto di partenza è semplice: per SCCM 2012 SP1 serve un SQL Server supportato dalla matrice Microsoft del periodo, con un’istanza dedicata o comunque isolata, e con una collation coerente con i requisiti di Configuration Manager. Se questa base è sbagliata, non la correggi con un workaround elegante. La correzione vera è reinstallare o ricreare l’istanza con i parametri corretti.

Scelta dell’architettura: istanza dedicata, locale o remota

Nella pratica hai tre scenari. Il primo è SQL installato sullo stesso server del site server, utile in laboratori o ambienti piccoli. Il secondo è SQL remoto, che è la scelta più pulita in produzione perché separa carico applicativo e database. Il terzo è una macchina SQL già in uso per altri servizi: tecnicamente possibile in alcuni casi, ma è il meno desiderabile perché introduce contesa su CPU, RAM, storage e manutenzione.

Per SCCM 2012 SP1 io considererei “sano” un SQL dedicato, con storage separato per dati, log e tempdb. Se non puoi farlo, almeno evita che i file MDF/LDF e il sistema operativo convivano sullo stesso volume senza controllo. In un’installazione mediana, il collo di bottiglia non è quasi mai il motore SQL in sé, ma la latenza disco e la crescita incontrollata dei file.

Prerequisiti minimi da controllare prima del setup

Prima di aprire il wizard, verifica questi punti. Non sono dettagli cosmetici: se uno manca, l’installazione può andare avanti e fallire più tardi, quando hai già perso tempo.

1. Versione di Windows Server supportata per il ruolo SQL, con patching coerente rispetto a SCCM 2012 SP1.
2. Account di servizio dedicato per SQL Server e SQL Agent, senza usare account personali o privilegi eccessivi.
3. Spazio disco sufficiente per database, log, tempdb, backup e crescita iniziale.
4. Collation corretta per la compatibilità con SCCM.
5. Firewall e connettività aperti tra site server e SQL Server sulla porta prevista.

Per un controllo rapido dello stato del sistema, prima dell’installazione puoi usare questi comandi sul server SQL:

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
wmic logicaldisk get caption,freespace,size,volumename
sc query MSSQLSERVER
sc query SQLSERVERAGENT

Il primo comando ti conferma il sistema operativo, il secondo ti dà un’idea immediata dello spazio disponibile, il terzo e il quarto servono solo se l’istanza è già presente e vuoi capire se stai lavorando su una macchina sporca. Se i servizi non esistono ancora, è normale.

Collation: il dettaglio che decide se SCCM parte davvero

La collation è il punto più delicato. Per SCCM 2012 SP1 la scelta tipica è una collation del tipo SQL_Latin1_General_CP1_CI_AS. Se installi SQL con una collation diversa, soprattutto se non case-insensitive o non compatibile con i requisiti di ConfigMgr, puoi vedere errori di validazione o comportamenti incoerenti più avanti. Non è una preferenza estetica: è un vincolo funzionale.

Se hai dubbi sulla collation corrente di un’istanza già installata, verifica così:

sqlcmd -S localhost -E -Q "SELECT SERVERPROPERTY('Collation') AS Collation;"

Se il risultato non coincide con quello richiesto dal tuo scenario SCCM, non tentare scorciatoie. La collation di istanza non è un parametro che sistemi a posteriori con una query. La via corretta è reinstallare l’istanza con il valore giusto oppure creare una nuova istanza dedicata.

Installazione di SQL Server: impostazioni da non lasciare al default

Durante il setup di SQL Server, evita il “next, next, finish”. Alcune scelte di default sono accettabili in laboratorio, ma in produzione diventano debito tecnico immediato.

1. Instance name: usa un nome chiaro e dedicato, soprattutto se la macchina ospita più istanze. L’istanza di sistema predefinita va bene solo se davvero non hai altro.
2. Service accounts: assegna account dedicati a motore e Agent. Niente account locali generici se puoi evitarlo.
3. Collation: imposta quella richiesta da SCCM prima di iniziare l’installazione.
4. Data directories: sposta dati, log e tempdb su volumi separati se l’infrastruttura lo consente.
5. Startup type: avvio automatico per i servizi che servono davvero, nulla di più.

Se preferisci un controllo da riga di comando in fase di validazione, il concetto è questo: devi sapere dove finisce ogni file e chi lo gestisce. Dopo l’installazione, controlla il mapping dei file del database di sistema e i servizi attivi:

sqlcmd -S localhost -E -Q "SELECT name, physical_name FROM sys.master_files;"
sc query MSSQLSERVER
sc query SQLSERVERAGENT

Se usi un’istanza nominata, sostituisci localhost con localhost\NOMEISTANZA. Il controllo dei file ti dice se i database di sistema sono finiti su un volume inadeguato; il controllo dei servizi conferma che l’istanza è realmente operativa.

Permessi e service account: il minimo necessario, non di più

Uno degli errori classici è concedere troppo “per fare prima”. In realtà SCCM e SQL funzionano meglio quando i privilegi sono chiari e limitati. L’account del Database Engine deve poter avviare il servizio, leggere e scrivere nei percorsi dei file dati e log, e interagire con il sistema in base al modello di servizio previsto. L’account SQL Agent deve fare il suo lavoro senza diventare un amministratore di dominio travestito.

Se usi account di dominio, documenta nome, scopo e scadenza della password. Non lasciare segreti in chiaro in script o note operative. Se devi automatizzare verifiche o installazione, usa un vault o almeno un meccanismo di redazione nei log di change.

In un ambiente SCCM, il problema non è solo “SQL si installa”. Il problema è “SQL resta stabile, aggiornabile e supportabile dopo sei mesi”. La differenza la fanno i dettagli di servizio, storage e permessi.

Firewall, porte e connettività tra site server e SQL

Se SQL è remoto, la connettività va verificata prima di installare SCCM. Il site server deve raggiungere l’istanza sulla porta TCP prevista; se usi istanza nominata e porte dinamiche, stai aggiungendo fragilità senza motivo. In produzione è più pulito fissare una porta statica e aprirla esplicitamente nel firewall.

Dal site server puoi fare un test rapido della porta:

Test-NetConnection sql01.contoso.local -Port 1433

Se il test fallisce, prima correggi rete e firewall, poi riparti con il setup. Non ha senso cercare il problema dentro SCCM quando il socket non si apre. Se la porta è diversa, documentala nel change e nel firewall. Se usi named instance con SQL Browser, sappi che stai aggiungendo dipendenza su UDP 1434 e comportamento meno prevedibile.

Tempdb, log e storage: la parte che incide davvero sulle prestazioni

Per SCCM il dimensionamento non deve essere fatto “a sensazione”. Il database cresce con inventario, compliance, software update, distribuzione contenuti e retention dei dati storici. Il tempdb soffre quando il sottosistema disco è lento o quando il server è affollato. I log diventano un problema se il recovery model, i backup o la retention non sono pensati con criterio.

La regola pratica è separare i volumi almeno così: sistema operativo, dati SQL, log SQL, tempdb, backup. Se non puoi separare tutto, separa almeno dati e log. Un volume unico per tutto è accettabile solo in ambienti piccoli o temporanei, non come scelta architetturale definitiva.

Per capire se il problema è lo storage, guarda la latenza e la coda disco prima di toccare il database. Su Windows puoi partire con Performance Monitor, oppure con una verifica rapida dello stato generale del disco e del carico I/O. Se hai già SQL installato, osserva anche le metriche di attesa e il consumo del tempdb. Se il server è lento prima ancora di SCCM, il problema non è SCCM.

Backup e ripristino: non aspettare il primo incidente

Un’installazione SQL per SCCM senza strategia di backup è incompleta. Devi sapere già da subito dove finiscono i backup, quanto spazio occupano e con quale retention li tieni. Non basta “avere il backup”: serve un restore testato. Altrimenti hai solo file che sembrano rassicuranti.

Se la piattaforma è piccola, una policy base può prevedere backup full frequente, differenziali se utili, log backup se il recovery model lo richiede e verifica periodica del ripristino su ambiente di test. Se il database cresce molto, il piano va tarato sui tempi di restore accettabili, non solo sui tempi di backup.

Verifiche finali prima di collegare SCCM a SQL

Prima di lanciare il setup di SCCM, fai un controllo finale coerente e ripetibile. L’obiettivo è ridurre la probabilità di scoprire un difetto quando il wizard è già a metà.

1. Verifica che il servizio SQL sia in esecuzione.
2. Controlla la collation dell’istanza.
3. Conferma la raggiungibilità TCP dal site server.
4. Controlla spazio libero e crescita dei volumi SQL.
5. Assicurati che l’account di servizio abbia i permessi richiesti.

Un check sintetico utile sul server SQL può essere questo:

sqlcmd -S localhost -E -Q "SELECT @@VERSION, SERVERPROPERTY('Collation') AS Collation;"
wmic logicaldisk get caption,freespace,size
sc query MSSQLSERVER

Se i risultati sono coerenti con il progetto, puoi passare alla configurazione di SCCM. Se no, correggi prima l’infrastruttura. Il costo di un’ora in più adesso è molto più basso del costo di una reinstallazione dopo che il site è già in produzione.

Un approccio pratico che evita i classici errori

La sequenza operativa più solida è questa: definisci in anticipo versione supportata, collation, nome istanza, account di servizio, porte e layout dischi; installa SQL; verifica con query e test di rete; solo dopo collega SCCM. In altre parole, non usare il setup di SCCM per scoprire se SQL è stato preparato bene.

Nel mondo reale, gli errori più costosi sono sempre gli stessi: istanza condivisa con altri carichi, collation errata, storage unico per tutto, firewall aperto “a tentativi”, account troppo privilegiati e assenza di un piano di backup ripristinabile. Nessuno di questi è sofisticato, ma tutti producono incidenti veri.

Se vuoi un’installazione robusta, tratta SQL come componente infrastrutturale critico, non come prerequisito da spuntare. SCCM dipende da lui in modo pesante e continuo. Un’istanza ben costruita oggi ti evita molto rumore domani.