Aggiornare ConfigMgr 2002 a 2010: guida pratica e bonus

Aggiornare ConfigMgr 2002 a 2010 senza improvvisare

Il salto da ConfigMgr 2002 a 2010 non è un click qualsiasi nel console tree: è un change controllato che tocca site server, componenti di management, reporting, client policy e spesso anche il modo in cui lavori con gli update successivi. La regola pratica è semplice: prima si verifica lo stato reale dell’ambiente, poi si apre la finestra di manutenzione, poi si procede. Saltare i controlli iniziali significa scoprire i problemi quando l’upgrade è già partito, cioè nel momento peggiore.

La domanda giusta non è “si può fare?”, ma “l’ambiente è pronto a reggere l’upgrade senza trascinarsi dietro errori già presenti?”. In ConfigMgr i problemi vecchi non spariscono perché l’update è nuovo: boundary group sporchi, componenti in warning, replica SQL lenta, requisiti ADK fuori allineamento o client health già degradata si presentano puntuali anche dopo il passaggio di versione.

Prima di iniziare: cosa controllare davvero

La preparazione pesa più dell’upgrade in sé. Se il site è stabile, l’update 2010 in genere è lineare; se il site è già fragile, l’upgrade amplifica il rumore e rende più difficile distinguere un warning innocuo da un problema reale.

• Verifica lo stato del sito in Monitoring > Site Status e Component Status: niente errori persistenti su SMS_EXECUTIVE, SMS_DISTRIBUTION_MANAGER, SMS_POLICY_PROVIDER o componenti di replica.
• Controlla la salute SQL: latenza, spazio libero, backup recenti, job critici e assenza di errori evidenti nei log del motore database.
• Conferma che il site server abbia risorse sufficienti: CPU, RAM e soprattutto disco libero sui volumi dove risiedono content library, inbox e directory temporanee.
• Verifica la compatibilità dell’ADK se gestisci task sequence, boot image o scenari OSD che dipendono da versioni specifiche.
• Assicurati di avere una finestra di manutenzione vera, non solo teorica: l’update può richiedere riavvii di componenti e tempi non banali per la propagazione ai site system.

Un controllo utile, spesso sottovalutato, è la lettura dei log prima di toccare il ramo di update. Non serve fare archeologia: basta capire se il site è pulito o se sta già lavorando male. Se trovi warning ripetuti, fermati e chiudi prima quelli. L’upgrade non è un detergente universale.

Prerequisiti operativi: il minimo che non va saltato

Per un aggiornamento sensato servono almeno tre cose: backup affidabili, osservabilità e rollback plausibile. Senza questi tre elementi stai facendo un cambio cieco.

• Backup: database SQL, site server, eventuali server di reporting e configurazioni critiche del site. Se il backup non è stato testato, non è un backup operativo.
• Snapshot: usali solo se la tua policy li accetta e se sai esattamente come gestire il rollback. In ambienti con SQL e integrazioni multiple, lo snapshot non sostituisce una strategia di recovery.
• Credenziali e privilegi: account con permessi adeguati sul site server e accesso alla console. Evita di lavorare con account d’emergenza non tracciati.
• Spazio libero: verifica disco su site server e SQL. Un upgrade fermo per spazio insufficiente è un classico evitabile.
• Change log: annota versione di partenza, orario di avvio, componenti coinvolti e punto di rollback.

Se vuoi essere rigoroso, prepara anche una schermata o nota con gli indicatori di baseline: numero di client attivi, stato dei boundary group, eventuali errori aperti e tempi medi di distribuzione policy. Dopo l’upgrade ti serviranno per distinguere un effetto collaterale da un problema preesistente.

Ordine corretto dell’aggiornamento

ConfigMgr non perdona molto bene gli upgrade eseguiti in ordine casuale. La regola è: si parte dal site primario, si osserva l’esito, poi si lascia propagare e solo dopo si verificano i ruoli e i client. Se hai gerarchie o site system distribuiti, l’attenzione va ancora di più sui tempi di replica e sulla coda dei componenti.

1. Apri la console e vai su Administration > Updates and Servicing.
2. Seleziona l’update 2010 e controlla i prerequisiti già segnalati dalla console.
3. Prima di partire, rileggi gli errori o warning nei log legati a update evaluation e prerequisiti.
4. Avvia l’installazione solo se il site è in stato accettabile e non hai warning bloccanti.
5. Lascia completare il processo senza forzare riavvii manuali o interventi a metà, salvo blocco evidente e documentato.

La console mostra l’avanzamento, ma la console da sola non basta. Il punto è verificare se il site sta davvero processando l’update o se è fermo in una fase di attesa. In pratica devi guardare sia l’interfaccia sia i log del sito. Il comportamento atteso è un avanzamento progressivo; l’osservazione sospetta è un fermo prolungato senza attività coerente.

Log da guardare senza perdere tempo

Se vuoi capire dove si è impuntato tutto, i log sono più utili delle ipotesi. Non serve leggere dieci file a caso: basta partire da quelli giusti e cercare la sequenza temporale.

• cmupdate.log: è il primo posto dove vedere l’avanzamento dell’update e gli eventuali blocchi.
• hman.log: utile per capire la gestione dell’hierarchy e le fasi di manutenzione del sito.
• sitecomp.log: se un componente non riparte o resta in stato anomalo, qui spesso trovi il dettaglio.
• distmgr.log: da leggere se dopo l’update hai problemi di distribuzione contenuti o package update.
• smsprov.log: utile se la console mostra comportamenti strani o errori di provider.

Un esempio operativo: se l’update sembra fermo ma cmupdate.log continua a scrivere progressi e sitecomp.log mostra il riavvio ordinato dei componenti, non sei davanti a un blocco. Se invece il log si interrompe su un prerequisito mancato o su un errore di accesso al database, il problema va trattato come stop reale, non come semplice lentezza.

Cosa cambia dopo il passaggio a 2010

Dopo l’upgrade non devi limitarti a vedere la nuova build nella console. Devi confermare che il sistema sia tornato operativo nei suoi punti pratici: policy ai client, distribuzione contenuti, deploy applicativi e reporting. Un upgrade “riuscito” ma non verificato è solo un’ipotesi elegante.

• Controlla la build del site nella console e confrontala con la versione attesa.
• Verifica che i componenti principali siano in OK e che i warning residui siano spiegabili.
• Fai una distribuzione di test verso una collection di laboratorio o pilot.
• Controlla che i client ricevano policy e che l’aggiornamento del machine policy sia regolare.
• Se usi OSD o task sequence, fai un test di avvio o di validazione su una macchina non critica.

Il punto debole tipico dopo un upgrade è la fiducia eccessiva nel fatto che “la console apre, quindi è tutto a posto”. In realtà il sito può apparire sano ma avere ancora code interne da smaltire. La verifica corretta è sempre funzionale: una policy applicata, una distribuzione riuscita, un client che parla con il management point, un contenuto scaricato senza errore.

Se qualcosa va storto: come limitare il raggio d’azione

Se emergono problemi durante o subito dopo l’upgrade, il primo obiettivo è contenere l’impatto. Non si va a toccare tutto il sistema in modo indiscriminato. Si identifica il layer e si interviene con la modifica minima reversibile.

Le opzioni più sane, in ordine di pragmatismo, sono queste: sospendere ulteriori cambiamenti, documentare il log che mostra il blocco, verificare se il problema è nel site server o in un ruolo secondario, e solo dopo valutare rollback o correzione mirata. Se il guasto è chiaramente legato alla nuova build e hai una strategia di recovery, il rollback va trattato come change formale, non come reazione istintiva.

• Blast radius: site server, database, distribution points, management points e client policy possono essere coinvolti a cascata.
• Rollback: deve essere pianificato prima, con backup verificati e finestra compatibile con il ripristino.
• Mitigazione: se l’update è applicato ma i servizi sono instabili, limita l’uso operativo del site finché non hai capito il punto di rottura.

Bonus utile: come evitare che il prossimo upgrade sia più duro del necessario

Il vero bonus non è “fare prima”, ma arrivare all’upgrade successivo con meno attrito. In ConfigMgr questo significa mantenere il sito pulito tra un update e l’altro, non aspettare la finestra di manutenzione per scoprire che qualcosa è rotto da settimane.

• Rimuovi o correggi i componenti in warning appena compaiono, non a ridosso dell’upgrade.
• Tieni sotto controllo gli spazi disco su site server e SQL con soglie operative reali, non teoriche.
• Allinea periodicamente client, ADK e versioni dei site system alle esigenze del parco macchine.
• Usa collection pilota per testare cambi di policy, applicazioni e content distribution prima di estendere il rollout.
• Documenta sempre cosa è cambiato tra una versione e l’altra: un upgrade senza storico è difficile da diagnosticare a posteriori.

Un ambiente ben tenuto rende l’upgrade quasi noioso, e in ambito infrastrutturale “noioso” è un complimento. Significa che i problemi veri sono stati chiusi prima, che i log non sono un cimitero di warning e che i passaggi di versione non diventano una caccia al dettaglio nascosto.

In pratica: la sequenza che funziona davvero

Se devo ridurre tutto a una sequenza operativa breve, la logica è questa: controlla lo stato del site, chiudi i warning evidenti, verifica backup e spazio, avvia l’update 2010, monitora i log giusti, conferma la build, poi fai test funzionali su policy, distribuzione e client. È una procedura semplice, ma semplice non vuol dire superficiale.

Assunzione: ambiente ConfigMgr 2002 single primary site o gerarchia con site system standard, backup disponibili e accesso console con privilegi amministrativi.