Come convertire SCOM da versione di valutazione a completa

Convertire SCOM da valutazione a versione completa senza perdere il controllo dell’ambiente

La conversione di Microsoft System Center Operations Manager (SCOM) da edizione di valutazione a licenza completa non è un cambio cosmetico: tocca la conformità della piattaforma, la continuità di monitoraggio e, in alcuni casi, il modo in cui l’istanza viene gestita nel tempo. La buona notizia è che il passaggio è in genere lineare. La parte delicata non è il tasto da premere, ma arrivarci con i prerequisiti in ordine: chiave corretta, diritti amministrativi, stato sano dei management server e una verifica post-change che dica davvero se l’ambiente è rimasto stabile.

In pratica, il passaggio a completa serve quando la trial sta per scadere o quando l’installazione è stata usata per test e deve entrare in produzione. Se il sistema è già operativo, la conversione va trattata come un change controllato: prima si verifica il layer di licenza, poi si controlla che console, management server e database siano accessibili, infine si conferma che i componenti restino in stato healthy dopo l’attivazione della chiave.

Cosa cambia davvero tra trial e completa

La differenza principale è giuridico-operativa, non tecnica: la trial ha una scadenza, la licenza completa no. Però la conversione impatta il piano di gestione perché, se la trial scade senza conversione, il rischio non è solo una notifica in console. In scenari reali puoi ritrovarti con funzioni limitate, alerting degradato o una finestra di tempo stretta per intervenire. Per questo conviene anticipare la procedura rispetto alla data di scadenza e non aspettare l’ultimo giorno utile.

Un punto spesso sottovalutato: la conversione non risolve problemi preesistenti. Se il management server ha errori nel Operational Manager log, se il database è lento o se la console presenta timeout, la licenza nuova non “cura” nulla. Prima di cambiare lo stato della licenza, l’ambiente deve essere almeno coerente e raggiungibile.

Prerequisiti minimi prima di toccare la licenza

Prima di aprire la console, conviene fare tre controlli rapidi: accesso amministrativo, chiave valida e stato del servizio. Sono controlli banali solo sulla carta; in pratica evitano il classico scenario in cui si avvia la procedura e poi si scopre che la chiave è errata, la console non ha privilegi o il server non risponde correttamente.

Se vuoi ridurre il rischio operativo, raccogli un riferimento di rollback. Nel caso di SCOM non stai quasi mai “tornando indietro” sulla licenza in senso stretto, ma devi poter dire con precisione quale stato era presente prima del change: versione, build, stato dei servizi e, se possibile, uno screenshot o export della pagina di licenza. Questo non è formalismo: in un ticket serio, la differenza tra avere o non avere questi dati è enorme.

Controlli utili prima della conversione:

• Accesso alla Operations Console con account amministrativo del dominio o con permessi equivalenti.
• Disponibilità della product key completa, senza ambiguità di edizione o canale di licensing.
• Stato online dei management server e raggiungibilità del database SQL usato da SCOM.

Percorso nella console: dove si cambia la licenza

La via più semplice è dalla Operations Console. In molte installazioni il percorso passa da Administration alla sezione relativa alla licenza o alla configurazione del prodotto, dove è presente l’opzione per inserire la chiave e convertire l’istanza. La nomenclatura può variare leggermente in base alla versione di SCOM, ma il punto non cambia: la chiave va inserita dalla console o da uno strumento ufficiale equivalente, non con modifiche manuali al database.

Se la tua versione mostra un wizard di aggiornamento licenza, usalo. Se la GUI non presenta il menu atteso, non forzare con workaround improvvisati: prima verifica la build esatta del prodotto e controlla la documentazione specifica per quella release. Qui il gap non va coperto a intuito; si chiude con un dato preciso, cioè la versione installata e il relativo percorso UI.

Un errore comune è confondere la conversione della licenza con l’upgrade di versione. Sono piani distinti: la conversione da trial a completa mantiene la stessa release, mentre l’upgrade cambia build e spesso richiede finestre di manutenzione più ampie. Se stai facendo solo la conversione, il blast radius dovrebbe restare limitato alla configurazione di licensing e al controllo dei servizi correlati.

Procedura operativa consigliata

La sequenza più pulita è: verificare stato, applicare la chiave, confermare l’attivazione, poi controllare che i servizi e la console restino stabili. Sembra ovvio, ma in ambienti con più admin e più change aperti è proprio la sequenza a fare la differenza.

1. Apri Operations Console con un account che abbia diritti amministrativi sul management group.
2. Vai nella sezione di amministrazione dove è esposta la gestione della licenza o della product key.
3. Inserisci la chiave completa della versione acquistata e conferma l’operazione.
4. Attendi la conferma di attivazione e annota eventuali messaggi di successo o warning.
5. Chiudi e riapri la console solo se richiesto dal wizard o se l’interfaccia non aggiorna immediatamente lo stato.
6. Verifica che i management server continuino a rispondere e che non compaiano nuovi errori nel log applicativo.

Se l’interfaccia richiede un riavvio della console o la rigenerazione della sessione, non interpretarlo come anomalia. È normale che alcune schermate non riflettano subito il nuovo stato. Quello che conta è il riscontro finale: la licenza deve risultare applicata e l’ambiente non deve mostrare degradi subito dopo il cambio.

Se vuoi una verifica più oggettiva, affianca alla console un controllo dei servizi Windows coinvolti. In molte installazioni è utile verificare che i componenti del management server restino in esecuzione e che non emergano restart anomali. Un esempio di controllo rapido, lato sistema, è questo:

Get-Service | Where-Object {$_.DisplayName -match 'Operations Manager|SCOM'} | Select-Object DisplayName, Status

Atteso: i servizi principali devono risultare Running. Se uno o più servizi risultano fermati, il problema non è la licenza in sé ma la salute dell’istanza, e va trattato come troubleshooting separato.

Verifiche immediate dopo l’attivazione

Dopo la conversione, non limitarti al messaggio “completed successfully”. La verifica minima deve coprire almeno tre livelli: console, servizi e log. Se uno dei tre dà segnali incoerenti, conviene fermarsi subito e non spostarsi su ipotesi più complesse.

1. Riapri la console e controlla che la schermata di licenza indichi lo stato complete o equivalente.
2. Verifica che i management server restino online e che gli alert esistenti continuino a essere visualizzati.
3. Controlla i log applicativi di SCOM e gli event log di Windows per errori nuovi nel minuto successivo al cambio.
4. Se disponi di un canale di monitoraggio esterno, conferma che non ci sia stato un buco negli heartbeat o nelle notifiche.

Un controllo utile è anche la semplice navigazione in console: se apri più viste e tutto risponde senza timeout, hai un primo segnale che il management group non ha subito effetti collaterali evidenti. Se invece la console diventa lenta proprio dopo il cambio, non liquidarlo come coincidenza: potrebbe esserci un problema preesistente reso più visibile dal refresh della sessione.

Se vuoi verificare la parte di licensing dal punto di vista amministrativo, conserva uno screenshot della schermata post-attivazione e annota data/ora del change. In audit o in una review interna, questi due elementi sono spesso più utili di una mail generica con scritto “fatto”.

Problemi tipici e come leggerli senza perdere tempo

Se la chiave viene rifiutata, le cause più probabili sono tre: chiave errata, edizione non coerente o problema di comunicazione della console con il management group. La falsificazione è rapida: ricontrolla il formato della chiave, verifica la build installata e prova ad accedere con un altro account amministrativo. In meno di cinque minuti di solito capisci se il problema è umano, amministrativo o tecnico.

Se la conversione sembra riuscita ma la licenza continua a risultare in trial, non assumere che il sistema “si aggiornerà da solo” in tempi lunghi. In quel caso controlla refresh della console, log dell’operazione e stato della sessione. Spesso è solo una mancata riconnessione, ma va dimostrato, non ipotizzato.

Se dopo il cambio compaiono errori di connettività verso SQL o degradano le viste operative, il problema potrebbe essere tutto un altro: saturazione del database, servizi in restart o un blocco già presente che coincide con il change. Qui la regola è non confondere correlazione con causalità. La licenza completa non dovrebbe alterare il traffico applicativo in modo significativo.

Blast radius, backup e rollback realistico

Il blast radius della conversione è normalmente basso: tocchi un aspetto di configurazione/licensing, non i dati di monitoraggio né la logica degli alert. Però il rischio operativo esiste, soprattutto se l’istanza è già fragile. Per questo il rollback non va immaginato come un “undo” perfetto, ma come la capacità di tornare a uno stato noto e documentato se qualcosa va storto subito dopo il change.

Prima del cambio, salva almeno le informazioni di base: versione di SCOM, stato della trial, screenshot della schermata di licenza e stato dei servizi. Se l’ambiente è gestito da più persone, registra anche chi ha eseguito l’operazione e a che ora. Questo non è solo tracciamento: è il materiale minimo per capire cosa è successo se dopo mezz’ora qualcuno segnala un’anomalia.

Rollback pratico: se la conversione introduce problemi immediati, il primo passo non è toccare il database ma riportare la console e i servizi a un stato osservabile, verificando se il problema è davvero legato all’attivazione o a una coincidenza temporale. Se la licenza completa è stata applicata correttamente ma emergono altri errori, il rollback della licenza potrebbe non essere la leva giusta; va aperta una diagnosi separata sul componente che ha smesso di funzionare.

Quando conviene farlo fuori dalla finestra di picco

Anche se la procedura è veloce, conviene eseguirla in una finestra di bassa attività. Il motivo è semplice: se qualcosa non torna, hai margine per osservare il comportamento del management group senza l’urgenza degli alert di produzione. In un ambiente con monitoring critico, scegliere un orario tranquillo riduce il rumore e rende più leggibili i segnali successivi al change.

Se gestisci più istanze, evita di convertire tutto insieme senza motivo. Meglio una sequenza controllata: prima l’ambiente meno critico o quello con maggiore copertura di monitoring esterno, poi gli altri. Anche qui il punto non è la difficoltà tecnica, ma la capacità di isolare eventuali anomalie.

Nota pratica finale per ambienti con governance stretta

In contesti enterprise, la conversione di SCOM viene spesso trattata come change amministrativo, non come patch o upgrade. Questo cambia il modo in cui va documentata: ticket, finestra, chiave usata, esito e verifica finale. Se il tuo processo richiede approvazione, prepara prima i dati minimi e non aprire il ticket con una descrizione vaga. Una richiesta ben scritta riduce il ping-pong e accelera il passaggio in esercizio.

In sintesi operativa: controlla lo stato iniziale, applica la chiave dalla console ufficiale, verifica lo stato post-change e conserva una traccia del prima/dopo. La conversione da trial a completa è una procedura semplice solo quando l’ambiente è già pulito. Se non lo è, il vero lavoro non è cambiare licenza, ma rimettere in ordine il contesto in cui quella licenza deve vivere.