Come aggiornare a Configuration Manager 1511

Il salto a Configuration Manager 1511 non va trattato come un semplice click di aggiornamento: è un cambio di piattaforma che tocca prerequisiti del sito, stato della gerarchia, compatibilità dei client e salute dell’infrastruttura SQL. La differenza tra un upgrade pulito e una settimana di correzioni sta quasi sempre nei controlli fatti prima di avviare il wizard.

Qui sotto trovi un percorso operativo pensato per ambienti reali: prima si verifica se il sito è pronto, poi si esegue l’aggiornamento, infine si controlla che console, componenti e distribuzione policy siano tornati stabili. L’obiettivo non è solo arrivare a 1511, ma farlo senza rompere la normale gestione dei client.

Prima di toccare il sito: cosa deve essere già in ordine

Prima di avviare l’aggiornamento, conviene distinguere tra blocchi reali e warning tollerabili. Un warning sullo stato di un vecchio client non blocca l’upgrade; un problema sul database, su un role fondamentale o su WSUS sì. In pratica: se il sito non è sano oggi, 1511 non lo rende più sano domani.

Controlla almeno questi punti:

• versione corrente di Configuration Manager e livello della gerarchia;
• stato del database SQL e spazio libero su volume dati e log;
• salute dei ruoli principali: management point, distribution point, software update point;
• presenza di errori critici nei log di sito e componenti;
• compatibilità dell’infrastruttura con la release target, inclusi prerequisiti di sistema operativo e SQL supportati.

Se hai più siti, verifica anche il rapporto tra primario e secondari. Un secondario instabile può non bloccare l’avvio dell’upgrade del primario, ma può introdurre comportamenti incoerenti nella replica e nella distribuzione dei contenuti. In questi casi il problema non è “se si può aggiornare”, ma “quanto rumore operativo vuoi portarti dietro”.

Il controllo che evita il 70% dei guai: log e prerequisiti

La parte utile non è aprire tutti i log a caso, ma sapere dove guardare. In una distribuzione Configuration Manager, i segnali più interessanti stanno nei log di setup, replication e component status. Se hai già errori ricorrenti prima dell’upgrade, quelli non spariscono perché lanci un nuovo build.

Verifiche pratiche:

1. Apri i log del server di sito e cerca errori ripetuti nei componenti core, soprattutto DB, replication e management point.
2. Controlla che il sito non abbia code di elaborazione anomale o backlog sui file di contenuto.
3. Verifica che il disco di sistema e quello del database abbiano margine; un upgrade con storage saturo è una pessima idea.
4. Se usi WSUS/SUP, controlla che la sincronizzazione sia sana prima di procedere.

Un esempio concreto: se il log del software update point mostra sincronizzazioni che falliscono da giorni, l’upgrade può comunque partire, ma poi ti ritrovi con console che sembra funzionare e aggiornamenti che non si allineano. In altre parole, l’upgrade non deve diventare il modo elegante per nascondere un problema già presente.

Backup e rollback: il minimo sindacale prima dell’upgrade

Prima di cambiare versione, metti in sicurezza ciò che ti serve per tornare indietro o per ricostruire il contesto. Non serve fare fantascienza: serve poter ripristinare rapidamente la configurazione e avere traccia chiara di cosa è stato toccato.

• backup del database di Configuration Manager;
• snapshot o backup coerente della macchina del site server, se previsto dalla tua policy;
• salvataggio delle personalizzazioni di console, script, query e report;
• nota della versione attuale e dei ruoli installati;
• copia dei file di configurazione o delle modifiche manuali non standard.

Se il tuo ambiente ha change management serio, questo è il punto in cui il rollback deve essere scritto e non solo “presunto”. Il rollback reale dipende da come è stato eseguito il backup e da quanto tempo puoi permetterti di stare fermo. Senza questi dati, stai facendo una scommessa, non un upgrade.

Come avviare l’aggiornamento a 1511

In Configuration Manager, l’aggiornamento di versione si gestisce dal nodo di amministrazione della console, nella sezione dedicata agli aggiornamenti e ai servicing. Il flusso esatto può cambiare in base alla versione di partenza, ma la logica resta la stessa: l’update viene importato, validato, scaricato se necessario e poi installato sul sito primario.

La sequenza operativa tipica è questa:

1. Apri la console di Configuration Manager con un account amministrativo adeguato.
2. Vai nell’area di amministrazione dedicata agli aggiornamenti del prodotto.
3. Se l’update 1511 è disponibile, avvia la fase di pre-req check prima dell’installazione.
4. Leggi con attenzione warning ed errori: i warning si valutano, gli errori si risolvono prima di proseguire.
5. Quando il controllo prerequisiti è pulito, avvia l’installazione e monitora lo stato del pacchetto di aggiornamento.

Durante il processo, non limitarti alla console. Tieni aperti i log di installazione e i log del server di sito. Se qualcosa si ferma, la console spesso ti dice solo che “l’operazione è in corso” o “ha avuto un problema”; il dettaglio vero lo trovi nei log.

Se l’ambiente è grande, pianifica la finestra come se l’upgrade fosse un change che impatta anche il team operativo. La console può restare accessibile mentre il sito si aggiorna, ma alcune funzioni possono diventare lente o temporaneamente incoerenti. Non è il momento di lanciare attività massive di distribuzione contenuti o di fare cambi paralleli.

Le tre cose che di solito si rompono davvero

Nella pratica, i problemi più comuni dopo l’upgrade non sono tutti uguali. Alcuni sono cosmetici, altri sono operativi. Le tre aree da tenere sotto osservazione sono console, componenti di sito e client policy.

1. Console non allineata: la console può richiedere aggiornamento o mostrare comportamenti strani finché non viene allineata alla nuova versione del sito.
2. Componenti di sito in stato degraded: spesso si tratta di servizi che riprendono dopo un po’, ma se persistono bisogna leggere i log e non fidarsi solo dello stato “giallo”.
3. Client che non ricevono subito policy nuove: dopo l’upgrade, la propagazione può richiedere tempo; se però il problema dura, va verificato il management point e la coda di elaborazione.

Qui il trucco è non confondere il normale ritardo post-upgrade con un guasto. Nei primi minuti o nelle prime ore, il sito può essere ancora in fase di riallineamento. Se invece dopo il tempo tecnico ragionevole i componenti restano degradati, allora hai un problema vero da isolare.

Verifiche post-upgrade che contano davvero

Una volta completata l’installazione, non dare per scontato che tutto sia ok solo perché la console si apre. Il controllo post-upgrade deve essere breve ma mirato: stato versione, stato componenti, distribuzione contenuti e risposta dei client.

• verifica che la versione del sito sia effettivamente passata a 1511;
• controlla che i ruoli principali risultino healthy o, almeno, in stato stabile;
• apri la console e verifica che non mostri errori di compatibilità;
• controlla che una policy di test venga distribuita correttamente a un client pilota;
• verifica che i log non mostrino errori ripetuti legati a replica, database o servizi di management.

Un buon test non è “la console si apre”, ma “un client campione riceve una policy, una distribuzione contenuti parte e i log non mostrano errori sistematici”. Se vuoi una metrica semplice, usa il tempo di riallineamento dei componenti e il tasso di errori nei log nelle prime 2–4 ore. Se questi numeri scendono verso il normale, sei sulla strada giusta.

Se qualcosa va storto: come ridurre il raggio d’impatto

Se durante o dopo l’upgrade compaiono errori seri, la priorità è contenere l’impatto. Non inseguire subito il fix strutturale: prima stabilizza il servizio. In un ambiente di produzione, questo significa bloccare cambi paralleli, evitare nuove distribuzioni e capire se il problema è nel sito, nel database o in un ruolo specifico.

Azioni sensate e reversibili:

1. ferma i change non urgenti sul site server;
2. verifica se il problema è circoscritto a un ruolo o a tutto il sito;
3. controlla i log recenti per individuare il primo errore utile, non solo quelli a cascata;
4. se necessario, disabilita temporaneamente attività secondarie per liberare risorse;
5. valuta il rollback solo se hai un punto di ripristino definito e un impatto che lo giustifica.

Il rollback non va improvvisato. Se la tua strategia di ritorno non è stata testata, devi considerarla parte del rischio dell’upgrade. Per questo il backup iniziale non è formalità: è il tuo unico appiglio se il sito entra in uno stato incoerente non recuperabile in tempi ragionevoli.

Quando conviene fermarsi prima di 1511

Non tutti gli ambienti sono candidati ideali per l’aggiornamento immediato. Se hai una gerarchia già stressata, storage al limite, problemi noti su SQL o una base client molto eterogenea, conviene prima ripulire l’infrastruttura. Aggiornare in quel contesto significa spesso spostare il problema un po’ più avanti, non risolverlo.

In pratica, rimanda l’upgrade se trovi uno o più di questi segnali:

• errori critici persistenti nei log di sito;
• dischi quasi pieni sul server di site o sul database;
• componenti core già in stato non sano prima del change;
• sincronizzazioni o repliche che falliscono regolarmente;
• assenza di una finestra di rollback ragionevole.

Meglio posticipare di un giorno che passare due settimane a inseguire problemi introdotti in un momento in cui l’infrastruttura era già fragile. Questo vale soprattutto per sistemi di gestione endpoint, dove anche un piccolo degrado può riflettersi su migliaia di client.

Checklist operativa finale

Se vuoi usare un controllo rapido prima del click finale, questa è la sequenza minima:

1. versione corrente identificata;
2. backup verificato;
3. spazio disco sufficiente;
4. SQL sano;
5. ruoli principali stabili;
6. prerequisiti superati;
7. finestra di change aperta;
8. piano di rollback disponibile.

Se tutti i punti sopra sono in ordine, l’upgrade a Configuration Manager 1511 è un change ragionevole, non una roulette. Se anche solo uno dei punti è debole, il lavoro vero è sistemare quello, non premere “avanti” sperando che il problema si risolva da solo.