Guida passo passo all’installazione di SCOM 1801

SCOM 1801: scegliere prima l’architettura, poi l’installer

System Center Operations Manager 1801 non si installa bene se si parte dal wizard e basta. La sequenza corretta è decidere prima come distribuire management server, database, data warehouse, console e gateway, poi verificare i prerequisiti di Active Directory, SQL Server, certificati e account di servizio. In ambienti Microsoft l’errore più comune non è l’installazione fallita: è un’installazione formalmente riuscita ma fragile, lenta o difficile da manutenere.

Questa guida segue un approccio pratico: preparazione, installazione del primo management server, configurazione del database e dei ruoli aggiuntivi, validazioni finali e punti di rollback. Dove serve, conviene usare la console o il setup grafico; dove serve ripetibilità, conviene lavorare con PowerShell e con log verificabili.

Architettura minima consigliata per un’installazione pulita

Per un primo deployment di SCOM 1801, il modello più lineare è questo: un management server iniziale, SQL Server dedicato o quasi dedicato, database operativo e data warehouse sullo stesso motore SQL solo se il carico è contenuto, console amministrativa su macchina di gestione separata, e gateway server solo per reti non fidate o segmenti remoti. In ambienti piccoli si tende a concentrare tutto, ma quando il numero di agenti cresce si paga in latenza di query, manutenzione e troubleshooting.

La regola pratica è semplice: se il team non riesce a spiegare in una frase dove finiscono i dati operativi e dove finiscono i dati storici, l’architettura è stata pensata male. SCOM lavora bene quando SQL è dimensionato e isolato. Lavora male quando il database “vive” insieme ad altro carico imprevedibile.

Prerequisiti da chiudere prima del setup

Prima di lanciare il setup, verifica questi punti: dominio Active Directory funzionante, nome host definitivo, risoluzione DNS coerente in avanti e indietro, ora sincronizzata, account con privilegi adeguati, SQL Server supportato e patchato, e spazio disco sufficiente per database, log e staging. Se uno di questi elementi è instabile, SCOM si installa comunque ma poi produce sintomi ambigui: console lenta, agenti che non si registrano, alert duplicati, o errori nel management pack store.

Controlla anche che il server non sia già “sporco” di tentativi precedenti. Residui di installazioni parziali, servizi dismessi o chiavi di registro lasciate da test precedenti sono una fonte classica di problemi. Se il sistema è stato usato per prove, meglio una macchina pulita o una rebuild completa.

Verifica la connettività verso SQL e il nome del server. Un test essenziale è questo:

Test-NetConnection sql01.contoso.local -Port 1433
nslookup sql01.contoso.local
w32tm /query /status

Se il test TCP verso la porta SQL fallisce, non andare avanti: il setup di SCOM può bloccarsi o completarsi con configurazioni che poi non riescono a parlare con il motore database. Se il DNS restituisce un nome diverso da quello atteso, correggi prima la risoluzione. Se l’ora è fuori sync, sistemala subito: Kerberos e certificati non perdonano drift temporali.

Account e permessi: cosa serve davvero

SCOM usa più account di quanti molti si aspettino. Non servono privilegi eccessivi, ma servono ruoli chiari. In pratica devi distinguere tra account di installazione, account per il servizio di gestione, eventuale account per l’accesso al database, e account per i runbook o le integrazioni successive. Il principio è sempre lo stesso: non usare Domain Admin come default operativo se puoi evitarlo.

Per il primo server, l’account che lancia il setup deve poter creare il management group e scrivere sul database SQL. Se la tua organizzazione impone separazione dei compiti, prepara in anticipo i permessi sul motore SQL e i gruppi AD che ospiteranno i futuri operatori SCOM. Il costo di una preparazione corretta è molto più basso del costo di un troubleshooting a installazione finita.

Se vuoi verificare rapidamente i privilegi lato SQL, usa una connessione con un account autorizzato e controlla la presenza dei login previsti. Non improvvisare con credenziali in chiaro nei file: se devi testare, usa un prompt elevato e cancella la cronologia sensibile se il contesto lo richiede.

Installazione di SQL Server per SCOM 1801

SCOM 1801 dipende molto da SQL, quindi la scelta del motore non va fatta in fretta. Usa una versione supportata e aggiornata, con istanza dedicata se possibile. L’operatività migliora quando i database di SCOM non competono con applicazioni generiche per CPU, I/O e memoria. Se l’istanza è condivisa, il rischio non è solo performance: è anche manutenzione imprevedibile.

Durante la preparazione SQL, verifica collations, memoria massima, auto-growth e collocazione dei file MDF/LDF. Una configurazione ragionevole evita che il database operativo cresca in modo frammentato o che i log saturino il disco. La metrica da guardare non è solo lo spazio libero, ma anche la latenza disco sotto carico e il tempo di risposta delle query verso il management group.

Se vuoi un controllo rapido delle impostazioni principali, puoi documentare ciò che trovi con query di sola lettura:

SELECT @@VERSION;
SELECT name, recovery_model_desc, collation_name
FROM sys.databases
WHERE name IN ('OperationsManager', 'OperationsManagerDW');

Se i database non esistono ancora, la query serve solo a confermare che l’istanza risponda e che la collazione del motore sia coerente con i requisiti interni dell’azienda. In caso di collazione errata, non “aggiustare dopo”: è uno dei casi in cui rifare l’istanza è spesso meno costoso che convivere con un problema strutturale.

Primo management server: ordine corretto del setup

Il primo management server è il momento in cui si crea il management group. È il punto più delicato dell’intera installazione, perché da qui dipendono schema SQL, servizi core, console e autorizzazioni. Se il gruppo viene creato con nome sbagliato o con account impropri, il danno non è sempre immediato ma si trascina nel tempo.

Avvia il setup dal supporto di installazione corrispondente alla build 1801, scegli l’installazione del management server e non saltare la schermata di verifica prerequisiti. Se il wizard segnala problemi di .NET, Windows Features o componenti mancanti, fermati e correggi prima di procedere. Il setup di SCOM non è il posto giusto per “vediamo se va avanti lo stesso”.

In genere il flusso corretto è questo:

1. Verifica prerequisiti sul server destinato a ospitare il primo management server.
2. Prepara SQL Server e conferma raggiungibilità della porta.
3. Avvia il setup SCOM 1801 con un account autorizzato.
4. Crea il nuovo management group con nome coerente con la naming convention aziendale.
5. Definisci il database operativo e il data warehouse secondo il layout previsto.
6. Completa l’installazione e salva i log del setup per audit e troubleshooting.

Durante il wizard, la scelta del nome del management group merita attenzione. Cambiarlo dopo è possibile solo con procedure più invasive e spesso con effetti collaterali sulla documentazione interna, sugli script e sulle integrazioni già pronte. Conviene usare un nome che identifichi ambiente e funzione, non un’etichetta generica che diventa ambigua dopo il primo ampliamento.

Log da controllare subito se il wizard si ferma

Se il setup si interrompe, il primo posto da controllare è la cartella log del programma di installazione e i log del sistema. Non cercare “a sensazione” nel registro eventi: i file di setup dicono molto più rapidamente dove si è rotto il flusso. Tieni d’occhio anche l’event viewer di Windows e i log del motore SQL.

Una strategia utile è questa: cerca prima errori evidenti di prerequisito, poi problemi di permessi, poi timeout verso SQL. In installazioni fallite, il sintomo finale è spesso lontano dalla causa reale. Un errore nel wizard può dipendere da DNS, da UAC, da un servizio SQL non avviato o da un path locale non scrivibile.

Se devi raccogliere informazioni minime da un server Windows, controlla almeno questi elementi:

Get-WinEvent -LogName Application -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message
Get-Service | Where-Object {$_.Status -ne 'Running'}
Get-ChildItem 'C:\Program Files\Microsoft System Center\' -ErrorAction SilentlyContinue

Se trovi servizi mancanti o stati incoerenti, non forzare restart casuali senza capire il contesto. In un’installazione incompleta, un riavvio può solo sporcare ulteriormente il quadro. Meglio prendere nota dei timestamp e confrontarli con i log del setup.

Console amministrativa e ruoli aggiuntivi

Dopo il primo management server, installa la console amministrativa sulle macchine da cui lavorerà il team. Evita di tenere tutto solo sul server core, perché la manutenzione quotidiana diventa scomoda e aumenta la probabilità di operazioni fatte in fretta dal posto sbagliato. La console non è un optional: è parte del disegno operativo.

Se l’ambiente lo richiede, aggiungi gateway server per segmenti di rete separati o non completamente fidati. I gateway sono utili quando non vuoi aprire troppo il traffico in ingresso verso il management group. Anche qui il punto non è “installare di più”, ma ridurre la superficie di esposizione e mantenere il controllo del flusso agent-to-management.

Per i gateway, i certificati contano. Se il modello di trust è basato su certificati, prepara la PKI prima di procedere. Un gateway senza certificati corretti non è un nodo funzionante: è un nodo che genera ticket. Se la tua PKI è lenta o non standardizzata, chiudi il tema prima e non dopo.

Agent, discovery e prima validazione operativa

Una volta installato il core, la prova vera è l’onboarding degli agenti. Non basta vedere la console aperta: bisogna verificare che i server target vengano scoperti, approvati e che inizino a inviare heartbeat e performance data. Il primo controllo utile è la presenza dell’agente in stato sano e l’assenza di errori di autenticazione o di canale.

In un ambiente appena nato, scegli pochi host pilota e controlla il comportamento per almeno un ciclo di monitoraggio completo. Se i dati arrivano ma con ritardo, il problema può essere di latenza SQL, di rete o di carico sui management server. Se non arrivano affatto, cerca prima problemi di firewall, trust o DNS.

Un controllo operativo minimo può includere la verifica del servizio agente e della connettività verso il management server:

Get-Service HealthService
Test-NetConnection scom-ms01.contoso.local -Port 5723

Se la porta 5723 non risponde, la catena di monitoraggio si interrompe quasi sempre a monte. In quel caso la verifica va fatta su firewall locale, firewall perimetrale e regole di rete tra i segmenti interessati. Non partire dai management pack se il trasporto base non funziona.

Scelte che fanno differenza dopo il primo avvio

La differenza tra un’installazione “finita” e una piattaforma gestibile sta in alcune decisioni prese subito. La prima è il sizing: CPU, RAM e I/O del management server e di SQL devono essere allineati al numero di agenti e ai pacchetti di monitoraggio che caricherai. La seconda è la manutenzione: backup, patching e controllo della crescita dei database non vanno rinviati a quando il sistema è già sotto pressione.

Un’altra scelta importante riguarda i management pack. Caricarne troppi all’inizio rende difficile capire quale componente sta generando alert, flapping o overhead. Meglio partire con il necessario, validare i monitor fondamentali, poi introdurre gradualmente il resto. Questo approccio riduce il rumore e rende leggibili i primi risultati.

Se l’obiettivo è affidabilità operativa, misura almeno tre cose dopo l’installazione: tempi di risposta della console, latenza di inserimento dati nel database, e percentuale di agenti sani. Se una di queste tre metriche degrada subito, il problema va affrontato prima di ampliare il perimetro.

Rollback ragionato se qualcosa non torna

Se l’installazione del primo management server è andata male e il management group non è stato ancora usato in produzione, la soluzione più pulita spesso è il rollback completo della macchina o il restore da snapshot, purché il contesto lo consenta e la VM non sia già stata collegata a servizi condivisi. In ambienti controllati, una ricreazione pulita costa meno di una riparazione incerta.

Se invece il core è già stato popolato con dati e agenti, evita interventi distruttivi senza piano. In quel caso il rollback deve essere accompagnato da backup SQL, esportazione delle configurazioni rilevanti e finestra di manutenzione. Il blast radius non è solo tecnico: è operativo, perché gli operatori perdono visibilità finché la piattaforma non torna affidabile.

Prima di toccare database o servizi, salva sempre i log del setup e annota versione, nome del management group, hostname e stato dei servizi principali. Questi dati sono il punto di partenza per qualunque ripristino serio.

Checklist finale prima di dichiarare SCOM pronto

Una installazione SCOM 1801 si può considerare pronta solo se il management server risponde, la console si apre senza errori, SQL accetta connessioni stabili, almeno un agente pilota comunica correttamente, e i log non mostrano errori ripetuti di autenticazione o timeout. Se manca uno di questi elementi, il sistema è ancora in fase di assestamento e non va trattato come piattaforma affidabile.

Il criterio pratico è questo: deve essere possibile aprire la console, vedere il management group corretto, individuare il server installato, verificare il primo agente e leggere i log senza ambiguità. Se questi passaggi richiedono tentativi o correzioni improvvisate, significa che il setup va rivisto a monte e non solo “aggiustato”.

Assunzione: questa procedura è pensata per un deployment iniziale in ambiente Windows Server recente, con SQL Server supportato e dominio Active Directory disponibile; se il contesto è più restrittivo, conviene validare prima compatibilità e policy interne.