Come installare l’aggiornamento 1610 di SCCM Current Branch

L’aggiornamento 1610 di Microsoft System Center Configuration Manager Current Branch non va trattato come un semplice “next, next, finish”. In un ambiente reale tocca infrastruttura, console, client, componenti di sito e spesso anche integrazioni laterali come WSUS, SQL e antivirus. Se l’obiettivo è portare il sito a 1610 senza trasformare il change in un incidente, la sequenza corretta è sempre la stessa: verificare lo stato attuale, mettere in sicurezza il rollback, leggere i prerequisiti, installare con un punto di controllo chiaro e poi validare il comportamento del sito.

Il punto che crea più problemi non è l’installazione in sé, ma l’idea che il comportamento sia identico in ogni topologia. Un primario standalone non si gestisce come un hierarchy con CAS, e un lab non prova quasi mai i casi interessanti: replica lenta, storage quasi pieno, SQL con manutenzione assente, client distribution non allineata, boundary group sporchi. Per questo conviene ragionare per dipendenze e non per schermate del wizard.

Prima di partire: cosa deve essere vero

La baseline minima è banale solo sulla carta. Devi sapere con precisione quale versione è installata, se il sito è in salute, dove finiranno i log, e come tornerai indietro se il cambio si interrompe a metà. In pratica servono quattro verifiche rapide: versione corrente del prodotto, stato del sito, capacità disco sul server del sito e disponibilità di backup coerenti del database e della VM o del sistema.

Per leggere la versione corrente apri la console e vai su Administration > Overview > Site Configuration > Sites, oppure controlla la proprietà del prodotto sul server. Se vuoi un riscontro più affidabile, usa anche il file di log del setup e il report di versione del sito. In un ambiente sano, l’upgrade parte solo se il sito non mostra errori non risolti nelle code di distribuzione, nella replica o nei componenti critici.

Il controllo del disco non è accessorio. L’update di SCCM può scaricare contenuti, decomprimere pacchetti e scrivere log e backup temporanei. Se il volume di sistema o quello dei dati è tirato, il cambio può fallire in modo poco elegante. Verifica spazio libero almeno sul volume che ospita il sito, i log e l’area di staging. Un controllo semplice è sufficiente:

Get-PSDrive -PSProvider FileSystem | Select-Object Name, Free, Used, @{n='FreeGB';e={[math]::Round($_.Free/1GB,2)}}

Se il sito usa SQL remoto, controlla anche che il database sia in buono stato e che non ci siano job di manutenzione bloccati o backup dimenticati. Non serve fare tuning prima dell’update, ma serve evitare di eseguire il cambio sopra una base già fragile.

Che cosa installa davvero l’update 1610

Un aggiornamento Current Branch non è un pacchetto monolitico. Modifica file di prodotto, componenti del sito, console, prerequisiti e spesso il comportamento dei client in modo indiretto. Il server di sito riceve il pacchetto, lo valida, esegue i controlli preliminari e poi applica i cambi nel contesto del sito. La console si aggiorna, ma solo se la procedura arriva a completamento. I client, invece, non vengono “aggiornati tutti insieme”: la nuova versione si diffonde in base alla normale logica di client deployment e policy.

Qui c’è un errore ricorrente: considerare l’upgrade del server come fine del lavoro. In realtà è solo il primo passo. Dopo il sito devi verificare che distribuzione contenuti, inventory, policy, application deployment e reporting continuino a funzionare come prima. Se il sito è sano ma i client non ricevono policy o le distribuzioni restano in errore, il problema è operativo anche se il wizard ha terminato senza warning.

Prerequisiti che vale la pena controllare davvero

Il prerequisito più importante è la compatibilità. Devi confermare che la build corrente di SCCM supporti il passaggio a 1610 e che il sistema operativo del server, SQL Server e la console siano in una combinazione supportata. Se salti questo passaggio, il setup può partire comunque ma bloccarsi in fase di validazione o lasciarti con un sito in stato ambiguo.

Il secondo prerequisito è la salute dei componenti. Nella console, la sezione Monitoring > System Status > Component Status ti dice subito se ci sono componenti rossi o gialli da prima del change. Non ignorare warning vecchi “perché tanto il sito funziona”: durante un upgrade, un componente già degradato è il candidato perfetto a diventare il collo di bottiglia.

Il terzo prerequisito è il backup. Non basta “avere un backup in qualche parte”. Serve un backup verificato del database e, se il sito è virtualizzato, un checkpoint o snapshot coerente con una finestra di rollback definita. Lo snapshot non sostituisce il backup, ma in molti ambienti è il modo più rapido per tornare allo stato precedente se l’upgrade si interrompe nelle prime fasi. Va usato con criterio e con una finestra breve, perché non è una soluzione da tenere viva a lungo.

Installazione da console: il percorso più pulito

Se l’ambiente è standard e la console risponde bene, la via più sicura è la console stessa. Vai su Administration > Updates and Servicing, seleziona l’update 1610 quando compare come disponibile e avvia il wizard. Se il pacchetto non è ancora apparso, prima di forzare qualunque cosa verifica la sincronizzazione e i log del componente di servicing. Forzare download o retry senza capire perché l’update non è visibile porta spesso a perdere tempo su un sintomo, non sulla causa.

Durante il wizard presta attenzione a tre punti: prerequisiti, selezione dei componenti da aggiornare e finestra di manutenzione. Se hai ruoli distribuiti, considera l’impatto sugli altri server del hierarchy. In un sito con più ruoli, il fatto che il primario sia pronto non significa che il resto della catena lo sia. Un distribution point lento o un management point non raggiungibile può non bloccare il setup, ma può rendere l’esito operativo meno affidabile di quanto sembri.

Il log da tenere aperto durante l’installazione è quello del servizio di site server e quello relativo agli update. I nomi esatti cambiano in base al ruolo e alla versione, ma la logica resta identica: controlla che il pacchetto venga scaricato, che i prerequisiti passino e che la fase di installazione non si fermi su errori di accesso, spazio o componenti SQL. Se compare un blocco, non rilanciare a ripetizione: identifica il punto di stop e correggi la causa.

tail -f /path/del/log/di/site/update.log

Il path preciso dipende dal ruolo e dalla configurazione, ma il principio è sempre lo stesso: un log in tempo reale ti dice molto più della console quando il wizard è fermo su “in progress” per troppo tempo.

Installazione con pacchetto scaricato o staging interno

In alcuni ambienti l’update viene prima scaricato in un’area di staging o distribuito in modo controllato. Ha senso quando vuoi ridurre il rischio di dipendere dalla connettività Internet o dal comportamento del repository di aggiornamento durante la finestra di change. È una scelta ragionevole se il sito è in una rete filtrata o se la change window è stretta e non vuoi aggiungere variabili esterne.

Il vantaggio dello staging è la prevedibilità; lo svantaggio è la gestione del contenuto. Devi controllare integrità del pacchetto, permessi sulla share o sulla cartella di staging e allineamento con l’account che esegue il servizio. Un errore di permessi può sembrare un problema di SCCM, ma in realtà è solo un problema di accesso file. Anche qui il controllo minimo è semplice: verifica che l’account del servizio abbia lettura e scrittura sull’area prevista e che non ci siano blocchi da antivirus o backup agent.

Se usi una share, evita di lasciarla esposta più del necessario. L’update package non contiene segreti in chiaro, ma l’area di staging è comunque una superficie operativa da proteggere con permessi minimi e accesso limitato agli amministratori che lavorano sul change.

Ordine corretto delle verifiche durante il change

L’ordine giusto è: stato del sito, avvio dell’update, osservazione dei log, conferma della fase di installazione, verifica console, verifica componenti, verifica client. Se inverti questo ordine, finisci a inseguire sintomi secondari. Ad esempio una console che non si apre subito dopo l’update può essere normale per qualche minuto; un componente in errore persistente, invece, è un segnale reale.

Per le verifiche rapide, tieni sotto mano queste domande operative: il sito è ancora raggiungibile? Il database risponde? I log mostrano progresso o stallo? Il wizard è fermo su prerequisiti o sta già applicando file? La console si aggiorna? I servizi principali restano in running? Un singolo sì o no non basta; serve il quadro completo.

Se vuoi una metrica semplice, usa il tempo di completamento del change e il numero di errori nei componenti di sito nelle prime due ore dopo l’upgrade. Non è una metrica elegante, ma è utile. Se il sito ha completato l’update e i componenti tornano verdi senza spike di errori, sei nella direzione giusta. Se invece aumentano gli errori di replica, distribuzione o policy, il problema è già emerso e va trattato subito.

Dopo l’upgrade: cosa controllare davvero

La prima verifica è la versione effettiva del sito e della console. Non fermarti al messaggio “successfully installed”. Apri la console e controlla che il build number sia quello atteso. Poi verifica che i ruoli principali siano operativi e che non ci siano warning nuovi in Component Status. Se il sito è multi-server, controlla anche i ruoli remoti che dipendono dal primario.

La seconda verifica è funzionale: distribuisci un contenuto di test, forza un client di prova a prendere policy, apri un’applicazione o una baseline conosciuta e osserva se il ciclo si chiude. Il punto è validare il comportamento reale, non solo l’assenza di errori in console. In ambienti grandi, il problema più insidioso è l’upgrade formalmente riuscito ma con una funzione laterale degradata.

La terza verifica è la telemetria operativa. Controlla i log dei componenti più sensibili e il carico del server nelle ore successive. Un upgrade di SCCM può introdurre un picco temporaneo, ma non deve lasciare il sito in saturazione permanente. Se noti CPU alta, I/O anomalo o code di lavoro che non si svuotano, serve una diagnosi separata.

Rollback: quando ha senso e come non improvvisarlo

Il rollback non si improvvisa a metà change. Va definito prima. Se hai usato uno snapshot coerente e il change è ancora in una finestra accettabile, il ritorno indietro può essere rapido. Se invece l’upgrade ha già toccato database e stato del sito in modo significativo, il rollback va valutato con più cautela perché il rischio di inconsistenza aumenta.

In pratica, il rollback va considerato solo se il sito non completa l’upgrade, i log mostrano un errore bloccante non risolvibile in tempi brevi, oppure la funzionalità core è degradato in modo inaccettabile. Il criterio non è “mi piace poco il risultato”, ma “il sito non è affidabile per gli utenti”.

Prima di tornare indietro, salva i log del tentativo fallito e annota il punto esatto di stop. Sono il materiale che ti serve per capire se il problema è stato ambientale, di prerequisiti o del pacchetto stesso. Un rollback senza raccolta evidenze ti lascia con un sito vecchio ma con la stessa causa irrisolta.

Errori tipici che vedo più spesso

Il primo errore è partire senza finestra di manutenzione reale. Se il change viene aperto “quando c’è tempo”, il controllo sul sito diventa superficiale e il rischio sale. Il secondo errore è ignorare il warning preesistente perché “non c’entra con l’update”. In SCCM quasi tutto c’entra, almeno indirettamente, quando lavori sul sito. Il terzo errore è non distinguere tra successo del setup e successo operativo: sono due cose diverse.

Un altro punto sottovalutato è la console. Dopo l’upgrade, la console deve essere coerente con il sito. Se gli amministratori continuano a usare una console vecchia, possono vedere comportamenti strani o errori di compatibilità. Tenere allineati i client di amministrazione evita una parte dei falsi problemi.

Infine, non usare l’update come occasione per fare altre modifiche non correlate. Se devi cambiare boundary group, riorganizzare collection o rifare il packaging, separa i change. Mischiare attività diverse rende impossibile capire quale modifica ha introdotto l’anomalia.

Una sequenza operativa che riduce il rischio

Se vuoi una traccia pratica, la sequenza è questa: verifica versione e stato del sito, conferma backup e rollback, controlla disco e componenti, avvia l’update da console, monitora i log in tempo reale, valida la console, verifica i ruoli e testa almeno un flusso client-end-to-end. Questa sequenza non elimina i problemi, ma li rende visibili quando sono ancora trattabili.

Nel caso dell’update 1610, il valore vero non è “aver installato una release”. È avere un site server che continua a fare il suo lavoro senza introdurre regressioni invisibili. Se fai le verifiche giuste, il change resta un’attività amministrativa. Se salti i controlli, diventa una caccia al sintomo con impatto utenti.

Assunzione operativa: l’ambiente è in produzione o comunque abbastanza vicino alla produzione da richiedere backup verificati, monitoraggio dei log e rollback definito prima dell’avvio.