SCOM 2012 SP1 non è un’installazione da lanciare “e poi si vede”: se l’ordine dei prerequisiti è sbagliato, il setup termina magari senza errori evidenti, ma il management group si porta dietro limiti difficili da correggere dopo. La strada corretta è questa: preparare SQL e gli account, verificare il sistema operativo e i componenti richiesti, installare i ruoli nell’ordine giusto, poi validare subito console, database e discovery.
In questa guida parto da un’installazione tipica on-premise con Windows Server, SQL Server dedicato o comunque già pronto, e un ambiente dove vuoi evitare sorprese in produzione. Se stai usando un lab, puoi semplificare alcuni aspetti, ma non saltare i controlli: SCOM perdona poco la configurazione approssimativa.
Architettura minima da decidere prima del setup
Prima di aprire il wizard devi sapere dove finiranno i componenti principali: Management Server, database SQL, eventuale Reporting Server, gateway per reti non fidate e, se serve, console di amministrazione. La scelta impatta direttamente su licenze, firewall, account di servizio e manutenzione futura.
Per un’installazione standard di SCOM 2012 SP1 servono almeno questi pezzi: un server per il management group, un’istanza SQL Server supportata, un account per i servizi, un account per la configurazione iniziale e un dominio AD funzionante. Senza dominio puoi fare poco: SCOM è molto orientato a Kerberos, gruppi AD e deleghe.
Prerequisiti da verificare prima di toccare il setup
La prima verifica utile è la compatibilità. SCOM 2012 SP1 ha vincoli precisi su sistema operativo, SQL Server e framework richiesto. Non andare a memoria: controlla sempre la matrice ufficiale Microsoft per la tua combinazione di versioni, perché la differenza tra “supportato” e “funziona nel lab” qui conta davvero.
Al minimo, sul server dove installerai il Management Server devono essere presenti .NET Framework richiesto dalla release, Windows Server aggiornato con patch coerenti, DNS corretto e sincronizzazione oraria stabile. Se l’orologio del server è fuori tolleranza rispetto al dominio, l’autenticazione inizia a dare problemi in punti non ovvi.
Verifica anche spazio disco e latenza verso SQL. SCOM non è leggero: i database operativi e di data warehouse crescono rapidamente se hai molti agenti, alert e performance collection. Un disco lento su SQL si traduce in console pigra, alert in ritardo e manutenzione più costosa.
Controllo rapido lato sistema:
systeminfo
ipconfig /all
w32tm /query /status
wmic logicaldisk get caption,freespace,sizeAtteso: dominio risolto correttamente, time source coerente, spazio libero sufficiente sul volume dati e nessun errore evidente di rete. Se `w32tm` mostra drift o source non affidabile, sistemalo prima del setup.
SQL Server: la parte che conviene preparare bene una volta sola
Il database è il cuore del management group. SQL Server deve essere già installato, patchato e configurato secondo le indicazioni Microsoft per SCOM 2012 SP1. Evita istanze improvvisate su server condivisi con carico imprevedibile: se il database rallenta, il problema si riflette su discovery, health state e reporting.
Le cose da controllare sono poche ma decisive: collation supportata, memoria assegnata, storage adeguato, backup pianificati e account di servizio con diritti minimi necessari. In più, assicurati che il nome dell’istanza sia quello che vuoi mantenere nel tempo: cambiare SQL dopo l’installazione è possibile, ma non è il tipo di operazione che vuoi fare a caldo.
Controllo minimo dalla shell SQL o con SQL Server Management Studio:
SELECT SERVERPROPERTY('Collation') AS Collation,
SERVERPROPERTY('Edition') AS Edition,
SERVERPROPERTY('ProductVersion') AS Version;Atteso: collation supportata da SCOM, versione SQL nella lista compatibile e istanza raggiungibile dal server SCOM con autenticazione corretta. Se la collation non è quella giusta, non conviene proseguire “sperando di farla passare”.
Account di servizio e permessi: meno privilegi, meno guai
SCOM usa più account, e confonderli è il modo più rapido per creare troubleshooting inutile. Separare i ruoli aiuta anche dopo, quando devi capire cosa fa davvero ogni servizio. In genere ti servono account distinti per installazione iniziale, servizi del management server, eventuale reporting e accesso ai database.
Non usare account personali. Usa account di dominio dedicati, password gestite con criterio e gruppi AD documentati. Se l’azienda ha già una policy di service account, allineati a quella. Se non esiste, creala prima di installare SCOM: evitare il caos post-go-live costa meno che correggerlo dopo.
Permessi minimi da verificare: accesso al dominio, log on as a service dove richiesto, diritti di lettura sul namespace WMI e accesso ai server monitorati secondo il modello di discovery che userai. Per il setup iniziale, l’account deve poter creare database e oggetti nel Management Group, quindi non è un utente “qualsiasi”.
Ordine corretto di installazione
L’ordine conta più del wizard. Se installi i componenti in modo casuale, poi perdi tempo a rincorrere dipendenze e assistenti che falliscono per prerequisiti mancanti.
Prepara il server: patch, reboot, verifica dominio, DNS e ora di sistema.
Prepara SQL Server: istanza supportata, collation corretta, storage e backup.
Prepara gli account di dominio: installazione, servizi e reporting.
Installa il primo Management Server e crea il management group.
Installa la console amministrativa sui workstation o server di gestione.
Se necessario, installa Reporting Server e poi i gateway per reti separate.
Questo ordine riduce gli errori più comuni: database non raggiungibile, account non autorizzato, console che punta a un management group non ancora pronto, gateway installato prima del tempo.
Installazione del primo Management Server
Avvia il setup con un account che abbia i privilegi richiesti per la creazione iniziale del management group. Durante il wizard, l’attenzione va soprattutto su tre punti: nome del management group, istanza SQL e account dei servizi. Scegli il nome con criterio, perché sarà visibile ovunque: console, report, script e documentazione.
Se l’installer propone il controllo dei prerequisiti, non ignorarlo. È il momento giusto per fermarsi se manca qualcosa di banale, come un componente Windows o una libreria runtime. Le correzioni fatte prima dell’installazione sono quasi sempre più economiche di quelle fatte dopo.
Sequenza pratica:
Lancia il media di SCOM 2012 SP1 e avvia il setup come amministratore.
Seleziona l’installazione del Management Server e lascia completare il controllo prerequisiti.
Inserisci il nome del management group e conferma l’istanza SQL.
Specifica gli account dei servizi secondo la tua separazione amministrativa.
Completa il wizard e conserva il log di installazione per il post-check.
Se il setup fallisce, il primo file da aprire è il log dell’installazione, non la console. Cerca errori su SQL connectivity, permessi, collation o prerequisiti mancanti. In molti casi il messaggio a video è troppo sintetico per capire davvero il blocco.
Console amministrativa: installarla subito evita falsi problemi
La console va installata su un sistema di amministrazione che userai davvero. Non ha senso tenere l’unica console su un server fragile o accessibile solo in emergenza. Installa la console dopo il management server, così puoi fare subito login e controllare lo stato del management group.
Dopo l’installazione, apri la console e verifica che il management group sia raggiungibile, che il servizio del management server risponda e che non ci siano warning di connessione. Se la console si apre ma mostra oggetti incompleti o errori di sincronizzazione, la causa è quasi sempre nei servizi del backend o nella connettività verso SQL.
Reporting: utile solo se lo configuri davvero
Il modulo di reporting è spesso installato “perché potrebbe servire”, poi resta fermo e non viene mai validato. Se lo vuoi davvero, configurarlo subito è la scelta più sensata: SQL Server Reporting Services deve essere pronto, i database di reporting devono essere creati e l’integrazione con SCOM deve essere verificata con un report reale, non solo con la presenza del ruolo.
Un controllo semplice è aprire Report Manager o l’interfaccia SSRS e cercare i report di SCOM. Se non compaiono, il problema può essere nel binding, nei permessi dell’account usato per il reporting o nella configurazione della sottoscrizione. Anche qui conviene leggere i log di SQL Reporting Services prima di fare tentativi casuali.
Gateway server: quando la rete non è tutta nello stesso dominio
I gateway servono quando devi monitorare reti non fidate o segmenti dove non vuoi aprire trust completi. Sono utili, ma vanno trattati con precisione: certificati, firewall e risoluzione nomi devono essere corretti. Un gateway installato male sembra “vivo”, ma in realtà non inoltra bene gli agenti o non si autentica con il management server.
La parte critica è la fiducia reciproca tra gateway e management server. Se la catena certificati non è coerente, la registrazione fallisce o resta in stato intermedio. Controlla anche l’orario: certificati validi ma con clock fuori sync producono errori difficili da leggere a prima vista.
Verifiche post-installazione che non andrebbero saltate
Una volta completata l’installazione, il test vero non è “la console si apre”, ma “il management group lavora correttamente”. La sequenza minima di verifica dovrebbe includere stato dei servizi, connettività al database, discovery di un host di test e assenza di errori critici nei log.
Controlli utili subito dopo il setup:
Verifica i servizi SCOM sul server: devono essere avviati e stabili.
Apri la console e controlla che il management group risulti connesso.
Controlla i log applicativi e quelli del setup per warning persistenti.
Importa o abilita un management pack di test e scopri un server pilota.
Conferma che gli alert e gli health state arrivino in console senza ritardi anomali.
Se vuoi un controllo rapido lato servizio, puoi usare PowerShell o Services.msc. Un esempio minimo:
Get-Service | Where-Object {$_.DisplayName -like '*Operations Manager*'} | Select-Object Status,DisplayNameAtteso: servizi in esecuzione e nessun restart continuo. Se uno dei servizi flappa, fermati e leggi il relativo log prima di ripartire con altre modifiche.
Errori tipici e come leggerli senza perdere tempo
Gli errori più frequenti in fase di installazione o primo avvio ruotano quasi sempre attorno a quattro aree: SQL non raggiungibile, permessi insufficienti, prerequisiti mancanti e problemi di nome/DNS. Non conviene inseguire l’interfaccia grafica: il log racconta di più del messaggio a video.
Le posizioni dei log variano in base al componente, ma il principio resta lo stesso: cerca il file di setup e i log del servizio nel percorso indicato dall’installer o nella cartella di installazione del prodotto. Se il setup segnala un errore generico, cerca stringhe come “failed”, “access denied”, “SQL”, “collation”, “prerequisite” e “timeout”.
Un errore di collation, per esempio, non si risolve con un riavvio. Un errore di permessi non si risolve cambiando l’account a caso. Se la diagnosi è chiara, la correzione va fatta sul punto giusto, non sul sintomo.
Consigli pratici per non rifare tutto tra sei mesi
Documenta subito tre cose: nome del management group, account usati e posizione dei database. Sembrano dettagli banali, ma sono quelli che mancano quando devi fare manutenzione, disaster recovery o affiancare un altro amministratore. Aggiungi anche screenshot o export della configurazione iniziale, se il tuo processo interno lo consente.
Se prevedi crescita, pensa da subito alla separazione tra management server, database e reporting. SCOM scala meglio quando il ruolo di ogni server è chiaro. Mettere tutto sullo stesso host può andare bene in un test, ma in produzione tende a diventare un collo di bottiglia appena aumentano gli agenti o i pacchetti di monitoraggio.
Infine, non aggiornare a caso i management pack subito dopo l’installazione. Prima stabilizza la piattaforma base, poi introduci i pacchetti necessari uno alla volta. Così, se compare un comportamento anomalo, sai esattamente quale cambiamento lo ha introdotto.
Sequenza sintetica consigliata
Se vuoi una traccia operativa corta, usa questa: prepara il server, valida SQL, crea gli account, installa il primo Management Server, verifica la console, poi aggiungi reporting e gateway solo se servono davvero. È un ordine semplice, ma è quello che riduce il numero di rollback e di installazioni rifatte.
SCOM 2012 SP1 funziona bene quando gli dai un backend pulito e una configurazione coerente. Se invece parti con prerequisiti approssimativi, ti ritrovi a inseguire sintomi distribuiti tra database, console, servizi e rete. In pratica: meno improvvisazione all’inizio, meno lavoro sporco dopo.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.