Percorsi di upgrade supportati per SCOM 2025

Prima di pianificare un upgrade a SCOM 2025, la domanda da chiarire non è solo “si può fare?”, ma da quale versione si parte e quali componenti entrano davvero nel percorso supportato. In ambienti System Center il punto critico non è quasi mai l’installazione in sé: è la compatibilità tra management server, database, agenti, console, reporting e gli eventuali componenti accessori già presenti in infrastruttura.

Il principio da tenere fermo è semplice: si upgradea solo lungo i percorsi dichiarati dal vendor. Saltare versioni, forzare un passaggio laterale o trattare un management group come se fosse un’app standalone è il modo più rapido per ritrovarsi con console incoerenti, agenti non allineati o SQL in uno stato non supportato. Se ti manca il dato preciso sulla versione di partenza, lo chiudi subito con il comando di inventory o con i dettagli visibili nei componenti installati, non “a occhio”.

Che cosa va verificato prima di parlare di percorso di upgrade

Per SCOM 2025 il percorso corretto dipende da quattro elementi: versione esatta del management group, stato di SQL Server, presenza di ruoli secondari e topologia degli agenti. In produzione conviene raccogliere questi dati prima di aprire il binario dell’installer, perché la parte davvero costosa non è l’upgrade riuscito: è il rollback di un upgrade iniziato senza fotografia iniziale.

Il controllo minimo utile è questo:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup' |
Select-Object SetupVersion, CurrentVersion

Se la chiave non è presente sul server dove ti aspetti SCOM, il dato manca: non improvvisare. In quel caso recupera la versione dalla console, dai pacchetti installati o dal nodo che ospita il management server effettivo.

Percorsi supportati: la regola pratica

Il criterio operativo è questo: puoi arrivare a SCOM 2025 solo dai rami che Microsoft dichiara supportati come origine. In pratica, la famiglia di upgrade tipica include i rilasci più recenti della serie precedente e, quando previsto, i rispettivi update rollup o cumulative update richiesti come prerequisito. Se il tuo ambiente è molto datato, spesso il percorso non è un salto diretto ma una sequenza di upgrade intermedi.

Per evitare errori di pianificazione, ragiona così:

1. Identifica la versione di partenza del management group e del database OperationsManager.
2. Verifica il support matrix ufficiale per SCOM 2025 e annota la versione minima di origine consentita.
3. Controlla i prerequisiti del layer SQL: edizione, build, compatibilità e stato di manutenzione.
4. Valuta i componenti collegati: reporting, web console, gateway, ACS, eventuali integrazioni o management pack sensibili.
5. Definisci il percorso in sequenza, includendo eventuali upgrade intermedi prima del salto finale a SCOM 2025.

Se l’ambiente parte da una release troppo vecchia, il messaggio corretto non è “non si può aggiornare”, ma “non si può aggiornare direttamente”. È una differenza importante, perché spesso la soluzione è un doppio passaggio: prima porti il sistema a una baseline intermedia supportata, poi completi l’upgrade al target finale.

Management group: il cuore del percorso

Nel caso di SCOM, il management group è il vero confine dell’upgrade. Se hai più management server, il comportamento da aspettarsi è un aggiornamento coordinato del gruppo, non una serie di installazioni indipendenti. Il punto da non perdere è che il database e la console devono restare allineati al livello del management group, altrimenti compaiono inconsistenze che non sempre emergono subito.

Prima di toccare i nodi, conviene verificare lo stato operativo del gruppo e la presenza di allarmi aperti che potrebbero complicare il troubleshooting post-upgrade:

Get-SCOMManagementServer | Select-Object Name, IsGateway, Version

Il risultato atteso è una lista coerente con la versione attuale dell’ambiente. Se trovi nodi con versioni diverse in modo non spiegabile, non è un dettaglio: è un segnale che il management group non è uniforme e che prima dell’upgrade serve una normalizzazione.

SQL Server: prerequisito, non accessorio

Molti upgrade falliscono non perché SCOM sia fragile, ma perché si sottovaluta il database. Per SCOM 2025 devi controllare edizione, versione/build, collation, stato dei backup e salute del filegroup. Se SQL è fuori supporto o troppo indietro, il percorso di upgrade si interrompe lì, anche se il resto dell’infrastruttura sembra pronto.

Il controllo minimo lato SQL deve coprire almeno queste voci:

1. Versione esatta di SQL Server con SELECT @@VERSION;.
2. Collation del server e del database OperationsManager.
3. Spazio libero su data e log, con crescita prevista durante la procedura.
4. Stato dei job di maintenance, backup e integrity check.

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

Se la collation non è quella attesa o il database report/dw è fuori allineamento, il problema va chiuso prima dell’upgrade. Qui il rollback non è “ripristinare un file”: è spesso un ripristino coerente dell’intero stack SQL + SCOM, quindi il blast radius è alto e va pianificato in anticipo.

Console, gateway e agenti: cosa segue davvero il management group

La console amministrativa e i gateway non vanno trattati come elementi decorativi. La console deve essere compatibile con la versione del management group, mentre i gateway richiedono la stessa disciplina degli altri ruoli server: aggiornamento controllato, verifica del canale di comunicazione e controllo dei certificati se l’ambiente usa autenticazione certificata.

Gli agenti seguono una logica diversa: in genere non richiedono l’upgrade simultaneo e massivo, ma vanno comunque allineati entro una finestra ragionevole dopo il management group. Lasciare agenti troppo vecchi rispetto al core introduce falsi positivi, monitoraggi mancanti e problemi di raccolta dati che sembrano “bug” ma sono solo disallineamenti di versione.

Un controllo utile è il seguente, per vedere quanti agenti sono davvero coerenti con la baseline corrente:

Get-SCOMAgent | Select-Object DisplayName, Version, HealthState | Sort-Object Version

Se trovi una coda lunga di versioni eterogenee, non è necessariamente un blocco immediato dell’upgrade, ma è un indicatore forte di debito operativo. In produzione, più eterogeneità hai, più cresce il rischio che il post-upgrade diventi un esercizio di triage.

Scenario tipico di upgrade: sequenza consigliata

La sequenza corretta, in assenza di vincoli particolari, è quasi sempre questa: baseline di salute, backup completo, upgrade del core, verifica console e servizi, allineamento componenti secondari, upgrade agenti. Saltare il controllo iniziale è il classico errore che trasforma un change controllato in un incidente di produzione.

1. Congela le modifiche su management pack e configurazioni non essenziali.
2. Esegui backup verificabili di database, VM o snapshot coerenti secondo la tua policy.
3. Esporta la configurazione critica e annota versione, patch level e ruoli.
4. Applica l’upgrade al management group seguendo il percorso supportato.
5. Verifica servizi e console prima di passare agli agenti.
6. Allinea gateway e console se richiesto dalla matrice di compatibilità.
7. Fai il rollout degli agenti in modo graduale, non a tappeto se l’ambiente è grande.

Il rollback deve essere definito prima di partire. Se il core non supera i controlli post-upgrade, il piano di ritorno deve essere chiaro: restore del database, ripristino della VM o fallback del nodo secondario, a seconda dell’architettura. Non basta dire “torniamo indietro”: bisogna sapere con quale punto di ripristino e quanto tempo serve.

Verifiche post-upgrade: cosa deve tornare verde

Dopo l’upgrade, la priorità non è aprire la console e basta. Devi verificare che il management group sia stabile, che il database sia raggiungibile, che i servizi principali siano in esecuzione e che i dati inizino a fluire con la stessa o migliore affidabilità di prima.

1. Servizi SCOM: controllo dello stato dei servizi core sul management server.
2. Console: apertura senza errori, caricamento dei rami principali e assenza di crash della UI.
3. Database: connessione stabile a `OperationsManager` e, se presente, `OperationsManagerDW`.
4. Event log: assenza di errori ricorrenti legati a schema, permessi o connettività.
5. Agenti: heartbeat regolare e nessun aumento anomalo degli errori di comunicazione.

Un controllo utile lato Windows è verificare i servizi principali del server SCOM con il nome effettivo presente nel tuo ambiente, ad esempio:

Get-Service | Where-Object {$_.DisplayName -like '*Operations Manager*'} |
Select-Object Status, Name, DisplayName

Il risultato atteso è Status = Running per i servizi necessari al ruolo installato. Se uno dei servizi resta fermo, il problema va letto insieme agli eventi applicativi e al log del setup, non isolatamente.

Quando il percorso non è diretto: upgrade intermedi e vincoli nascosti

Ci sono ambienti in cui il percorso verso SCOM 2025 non è lineare per ragioni pratiche: versione iniziale troppo vecchia, SQL da riallineare, componenti legacy ancora installati o management pack che dipendono da versioni specifiche. In questi casi l’errore tipico è voler “accorciare” il cammino. La strada corretta è l’opposto: mappare i vincoli e rispettare ogni passaggio richiesto.

Se un prerequisito non è documentato o non è chiaro, non si colma il gap con supposizioni. Si chiude il dubbio con la fonte corretta: documentazione Microsoft per la matrice di supporto, inventario del sistema, log di setup e controlli sul database. È meglio fermarsi mezz’ora prima che passare una notte a rincorrere un upgrade parzialmente riuscito.

La regola operativa più utile con SCOM è questa: prima si dimostra che il percorso è supportato, poi si esegue. L’ordine inverso produce quasi sempre lavoro extra.

Checklist operativa da usare prima del change

1. Versione esatta di SCOM documentata per management server, console e gateway.
2. Versione e build di SQL Server verificate con query e non per supposizione.
3. Backup testato e ripristino provato almeno su ambiente di staging o lab, se disponibile.
4. Spazio disco sufficiente su system drive, data drive e log drive.
5. Finestra di manutenzione approvata con impatto utenti considerato reale.
6. Rollback scritto, con punto di ritorno e tempi stimati.
7. Verifica post-change con criteri oggettivi: servizi, console, log, agenti, database.

Se vuoi evitare ambiguità, l’output che devi avere in mano prima di iniziare è: versione sorgente, target, support matrix, stato SQL, elenco ruoli e piano di rollback. Senza questi cinque elementi, il percorso di upgrade a SCOM 2025 non è ancora un piano: è solo un’intenzione.

Assunzione operativa: ambiente in produzione o assimilabile, con gestione controllata del change e necessità di rispettare esclusivamente i percorsi di upgrade dichiarati e verificabili per la versione di partenza.