1 15/04/2026 9 min

Per ConfigMgr (Microsoft Endpoint Configuration Manager) la parte delicata non è “installare SQL Server” in sé, ma installarlo con i parametri giusti: versione supportata, collazione corretta, feature minime, account di servizio ben separati e un controllo finale sul motore prima di puntare il sito verso il database. Se sbagli uno di questi punti, il setup di ConfigMgr può andare avanti e fermarsi più tardi, quando correggere costa molto di più.

Questa guida copre l’installazione di SQL Server 2019 in un contesto ConfigMgr on-premises. L’obiettivo è avere un’istanza pulita, pronta per ospitare il database del site server, con una configurazione prevedibile e facile da manutenere. Dove serve, distinguo tra ciò che è richiesto e ciò che è consigliato per operare senza sorprese.

Scelta dell’istanza: default o named instance

Per ConfigMgr puoi usare sia l’istanza predefinita sia un’istanza nominata. In ambienti semplici, l’istanza default riduce il rumore operativo: meno porte da ricordare, meno complessità nei collegamenti e meno errori nei riferimenti al server. In ambienti condivisi, dove lo stesso host ospita più motori o più laboratori, un’istanza nominata è spesso la scelta più ordinata.

La scelta non cambia il punto centrale: ConfigMgr deve vedere un’istanza SQL stabile e supportata, con collazione corretta e servizi avviabili sotto account controllati. Se l’istanza è già usata da altri carichi, verifica prima che non ci siano policy o baseline che impongono hardening incompatibile con il setup di ConfigMgr.

Prerequisiti da verificare prima del setup

Prima di lanciare il programma di installazione, controlla questi punti. Sono quelli che in pratica evitano il maggior numero di reinstallazioni:

  1. Versione di Windows Server supportata per il tuo scenario ConfigMgr.
  2. Account con privilegi amministrativi locali sul server SQL.
  3. Spazio disco sufficiente per data, log e tempdb.
  4. Collazione corretta per ConfigMgr.
  5. Connettività di rete tra site server e SQL server.
  6. Porta TCP consentita nel firewall, di solito 1433 se usi la porta standard.

Se vuoi fare un controllo rapido lato sistema, questi comandi sono utili prima dell’installazione:

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
wmic logicaldisk get caption,freespace,size,volumename
netstat -ano | findstr :1433

Il terzo comando non ti dice se SQL è già installato in modo completo, ma aiuta a capire subito se la porta standard è già occupata. Se è occupata, decidi prima se cambiare porta o usare un’altra istanza: farlo dopo complica la configurazione di ConfigMgr e il troubleshooting dei client.

Collazione corretta per ConfigMgr

La collazione è uno dei punti più importanti. Per ConfigMgr, la scelta tipica è SQL_Latin1_General_CP1_CI_AS. Se installi il motore con una collazione diversa, il setup del site può fallire o produrre comportamenti anomali in fase di query e confronto testi.

Non dare per scontato che la collazione di sistema sia già quella giusta. Se il server è stato preparato per altri servizi, oppure è stato riutilizzato da un’installazione precedente, controlla esplicitamente il valore prima di procedere. Il modo più semplice è aprire il setup di SQL Server e verificare la pagina Server Configuration o, se l’istanza esiste già, leggere la proprietà dell’istanza da SSMS.

Se devi chiudere il dubbio via T-SQL su un’istanza già presente, puoi usare:

SELECT SERVERPROPERTY('Collation') AS Collation;

Se la collazione non è quella attesa, la correzione non è un semplice toggle. Nella pratica, per un server destinato a ospitare ConfigMgr, la strada più pulita è reinstallare l’istanza con la collazione corretta. Tentare di “aggiustare dopo” in genere costa più tempo e introduce più rischio di una reinstallazione controllata.

Installazione di SQL Server 2019: feature minime

Per ConfigMgr non servono tutte le componenti di SQL Server. Installa il motore database e gli elementi strettamente necessari al tuo scenario. In generale, il focus è su:

  • Database Engine Services
  • Client Tools Connectivity se richiesto dal tuo flusso di gestione
  • Management Tools per amministrazione e troubleshooting

Evita feature inutili se non hai un requisito preciso. Ogni componente in più è superficie di manutenzione, patching e controllo. In ambienti enterprise questo conta davvero, soprattutto se l’istanza SQL è dedicata a ConfigMgr e non deve fare altro.

Avvia il setup come amministratore e segui il wizard. Se preferisci farlo da riga di comando, il file di configurazione generato dal setup ti consente di mantenere una traccia ripetibile. Un esempio di installazione silenziosa, da adattare ai nomi dei percorsi e delle edizioni, può partire da un file `ConfigurationFile.ini`.

[OPTIONS]
ACTION="Install"
FEATURES=SQLENGINE,CONN,SSMS
INSTANCENAME="MSSQLSERVER"
SQLSVCACCOUNT="DOMAIN\\sqlsvc"
SQLSYSADMINACCOUNTS="DOMAIN\\AdminGroup"
TCPENABLED=1
NPENABLED=0
SQLCOLLATION="SQL_Latin1_General_CP1_CI_AS"

Il file sopra è volutamente essenziale. Non copiarlo alla cieca: i nomi delle feature e i parametri variano in base all’edizione, al media di installazione e al modo in cui gestisci gli account. La logica però resta la stessa: pochi componenti, account espliciti, collazione dichiarata, TCP abilitato.

Account di servizio e modello di accesso

Per un’installazione pulita, separa gli account di servizio da quelli amministrativi. Non usare account personali per il motore SQL. Meglio un account dedicato, con password gestita secondo la tua policy interna e con privilegi minimi necessari. Se il database dovrà essere accessibile dal site server di ConfigMgr, prepara anche il gruppo o l’account che userai durante il setup del sito.

In pratica, ti servono almeno due livelli distinti:

  1. Account del servizio SQL, usato dal motore.
  2. Account amministrativo, usato per installazione e gestione iniziale.

Se vuoi verificare rapidamente i servizi dopo l’installazione, usa PowerShell o `services.msc`. La verifica minima è che il servizio del motore sia Running e configurato con l’account previsto.

Get-Service -Name MSSQLSERVER,SQLSERVERAGENT | Select-Object Name,Status

Se usi un’istanza nominata, il nome del servizio cambia. Questo è uno dei motivi per cui conviene tenere una nota operativa con nome istanza, porta, account e percorso dei data file: in un ambiente con più server SQL, dopo qualche mese queste informazioni non sono più ovvie.

Impostazioni di rete, porte e firewall

ConfigMgr deve raggiungere SQL in modo affidabile. La configurazione più semplice è una porta TCP statica, di solito la 1433, aperta solo tra i sistemi che servono davvero. Se usi un’istanza nominata con porte dinamiche, aggiungi il rischio di troubleshooting inutile: il servizio può cambiare porta, il firewall può non seguirlo, e il setup del site può iniziare a fallire in modo intermittente.

Per questo, in ambienti di produzione la scelta più lineare è spesso:

  • porta TCP statica;
  • firewall limitato al site server e agli host autorizzati;
  • disabilitazione di ciò che non serve, compresi protocolli legacy inutili.

Una verifica rapida della raggiungibilità, dal site server verso SQL, si fa con `Test-NetConnection`:

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

Se il test fallisce, prima di toccare SQL controlla il firewall Windows e gli eventuali firewall di rete. Il problema più comune non è il motore spento, ma il percorso interrotto tra i due host.

Percorso operativo consigliato

Se vuoi ridurre il rischio, segui questo ordine. È il modo più lineare per evitare di dover rifare il lavoro perché una scelta base era sbagliata.

  1. Prepara il server Windows con patch aggiornate e spazio disco adeguato.
  2. Definisci nome istanza, account di servizio e porta TCP.
  3. Verifica la collazione prima di confermare il setup.
  4. Installa solo le feature necessarie al motore.
  5. Abilita SSMS o gli strumenti di gestione se li usi nel tuo standard.
  6. Apri il firewall solo per i flussi richiesti da ConfigMgr.
  7. Controlla il servizio SQL e la connessione dal site server.

Se stai preparando un server nuovo, conviene fare il controllo finale anche via query. Dopo l’installazione, connettiti a `master` e verifica collation, versione e stato dei servizi logici che userai per il site.

SELECT
    @@VERSION AS Versione,
    SERVERPROPERTY('Edition') AS Edition,
    SERVERPROPERTY('Collation') AS Collation;

Se la risposta mostra SQL Server 2019 e la collazione prevista, hai già eliminato due classi di problemi tipici: incompatibilità di versione e mismatch di ordinamento. A quel punto il setup di ConfigMgr ha una base molto più solida.

Verifiche dopo l’installazione

Dopo il setup, non fermarti al “servizio avviato”. Le verifiche utili sono poche ma concrete:

  1. Il servizio SQL è in esecuzione.
  2. La porta TCP configurata risponde dal site server.
  3. La collazione corrisponde al requisito di ConfigMgr.
  4. Il login amministrativo usato per il setup ha i diritti previsti.
  5. I percorsi dei file dati e log puntano ai volumi giusti.

Per controllare i percorsi dei database puoi usare SSMS oppure una query che elenchi i file fisici:

SELECT
    DB_NAME(database_id) AS DatabaseName,
    name AS LogicalName,
    physical_name
FROM sys.master_files
ORDER BY DatabaseName, LogicalName;

Questo controllo è utile perché il problema spesso non è “SQL non parte”, ma “SQL parte su dischi non previsti”. Se data e log finiscono sul volume sbagliato, il collo di bottiglia si presenta più tardi, quando il site ConfigMgr comincia a crescere.

Errori tipici da evitare

Ci sono alcuni errori ricorrenti che vale la pena prevenire subito:

  • installare SQL con collazione non supportata dal site;
  • usare account locali invece di account di servizio dedicati;
  • lasciare porte dinamiche senza una ragione precisa;
  • aprire il firewall in modo troppo ampio;
  • mescolare file dati, log e tempdb sullo stesso disco senza valutazione;
  • saltare il test di connettività dal site server.

Il punto non è essere eccessivamente rigidi. È evitare che un’installazione apparentemente riuscita diventi un problema operativo nel momento in cui ConfigMgr inizia a fare davvero il suo lavoro: inventario, policy, distribuzione contenuti e reporting.

Nota pratica per ambienti già esistenti

Se SQL Server 2019 è già presente e devi solo prepararlo per ConfigMgr, non dare per scontato che basti “creare il database”. Prima conferma la collazione, il modello di autenticazione, la connettività, la dimensione dei file e la gestione degli account. In un ambiente già usato da altri servizi, la verifica dei requisiti è più importante della procedura di installazione in sé.

Se invece stai costruendo un server dedicato, tieni la configurazione il più semplice possibile. Per ConfigMgr, la semplicità è un vantaggio operativo: meno variabili, meno sorprese durante il setup del site, meno tempo perso nel troubleshooting di un problema che nasce da dettagli di base.

Checklist finale

  • Collazione verificata e compatibile con ConfigMgr.
  • Istanza SQL definita e documentata.
  • Account di servizio dedicato e autorizzazioni minime.
  • Porta TCP statica e firewall limitato.
  • Servizio SQL attivo e raggiungibile dal site server.
  • Feature installate solo se necessarie.

Se questa checklist è completa, hai una base solida per passare alla fase successiva: l’installazione del site ConfigMgr e la creazione del database. Se manca uno dei punti sopra, conviene fermarsi e chiudere il gap prima di andare oltre.