Date di fine supporto SCCM per le versioni Current Branch

Date di fine supporto SCCM Current Branch: il punto che conta davvero

Con SCCM, oggi Configuration Manager, la domanda “quando scade il supporto?” non ha una sola risposta valida per tutte le installazioni. La data dipende dalla versione Current Branch che stai usando e dal canale di supporto applicabile in quel momento. In pratica, non basta sapere che il prodotto è ancora installato: serve sapere esattamente quale build è in esecuzione e quale ramo di supporto Microsoft le riconosce.

Per chi gestisce ambienti enterprise, questo non è un dettaglio da calendario. Una versione fuori supporto significa niente fix ufficiali per bug e vulnerabilità, più rischio operativo nei cambiamenti di infrastruttura, e più attrito quando devi aprire un caso con Microsoft. Il vero problema, quasi sempre, è che si ragiona per “Current Branch” come se fosse una singola release continua. Non lo è: è una famiglia di versioni con finestre di supporto proprie.

Come leggere le date di supporto senza sbagliare metrica

La regola pratica è questa: non cercare una data generica per SCCM Current Branch, ma individua la versione installata e confrontala con il lifecycle Microsoft. Le date di fine supporto sono pubblicate per release, non per “SCCM” in astratto. Se hai più site system o console distribuite, la versione rilevante è quella del site primario o del central administration site, non il singolo client.

Il controllo più affidabile parte dalla console. In Administration > Site Configuration > Sites trovi la versione del sito. In alternativa puoi verificare il file di installazione o la versione del componente principale, ma la console è il primo punto da cui partire perché riflette lo stato effettivo del site server.

Se vuoi una verifica rapida lato server, il riferimento operativo più utile è il file di log del setup o le informazioni di versione del sito. In molti ambienti è più veloce leggere la build dalla console che inseguire stringhe sparse su disco. Quando serve un controllo incrociato, usa i log del site server e non affidarti alla memoria: le versioni di ConfigMgr si somigliano, ma le finestre di supporto no.

Versione installata: dove trovarla in modo affidabile

Se devi chiudere il gap in modo tecnico, fai così: prendi la build esatta e verifica il supporto sul portale Microsoft Lifecycle o nella documentazione ufficiale del prodotto. Il numero di versione è l’elemento decisivo. Per esempio, una release Current Branch può essere ancora supportata mentre una precedente è già uscita dalla finestra utile. La differenza non la fa il nome commerciale, ma la build.

Una lettura corretta della versione evita due errori comuni. Il primo è confondere la scadenza del supporto della versione principale con quella di un update cumulativo. Il secondo è assumere che l’installazione sia “aggiornata abbastanza” solo perché riceve contenuti nel console update ring. In realtà, il supporto si misura sempre rispetto alla release di base e ai termini pubblicati da Microsoft per quella specifica build.

Impatto operativo: cosa succede quando una release esce dal supporto

Quando una versione SCCM Current Branch arriva a fine supporto, non smette di funzionare da un minuto all’altro. Questo è il punto che crea più falsa sicurezza. Gli endpoint continuano a ricevere policy, i task sequence possono continuare a partire, la console si apre ancora. Ma il rischio reale cresce perché non hai più una copertura ufficiale per problemi nuovi, regressioni o incompatibilità con componenti recenti dell’ecosistema Microsoft.

In ambienti con Windows 11, co-management, Intune integration, SQL Server aggiornato o dipendenze di security più rigide, restare su una release vecchia può trasformare un semplice upgrade di routine in un progetto di recupero. Più aspetti, più aumentano gli incastri: schema update, prerequisiti, versioni del client, maintenance windows, reporting e dipendenze lato WSUS o distribution point.

In altri termini: il costo non è solo “rischio sicurezza”, ma anche tempo di fermo amministrativo. Un SCCM fuori finestra di supporto può bloccare l’adozione di nuove funzionalità o costringerti a fare upgrade in emergenza, che è quasi sempre il modo peggiore di gestire una piattaforma così centrale.

Tabella pratica: come orientarsi sulle Current Branch

Più che memorizzare date a mano, conviene usare un criterio operativo semplice:

• identifica la versione esatta del site;
• verifica la data di fine supporto sul lifecycle ufficiale Microsoft;
• controlla se hai ancora tempo sufficiente per test, pilota e rollout;
• se la release è vicina alla scadenza, pianifica subito l’upgrade;
• se è già fuori supporto, tratta l’upgrade come priorità di rischio.

Questo approccio è più utile di una tabella statica dentro un articolo, perché le date cambiano con le nuove release e con eventuali revisioni del ciclo di vita. L’unica tabella che conta davvero è quella che costruisci partendo dalla tua build installata.

Verifica rapida in console e fuori console

Se lavori dalla console, il percorso più diretto è quello già citato: Administration > Site Configuration > Sites. Lì controlli la versione del sito e, di riflesso, puoi risalire alla release Current Branch. Se invece devi automatizzare o fare audit su più ambienti, raccogli la versione del site server e confrontala con il documento di supporto Microsoft.

Un controllo utile lato server è verificare i log di setup e di aggiornamento del sito. Non serve scavare in mezzo a tutto: cerca la stringa della versione o dell’update installato, poi incrocia il dato con il lifecycle. L’obiettivo non è fare forensic, ma rispondere a una domanda semplice: questa istanza è ancora dentro la finestra di supporto, sì o no?

Se la risposta non è immediata, il gap va chiuso con un dato tecnico preciso: numero di versione, data di rilascio, data di fine supporto, e stato dell’ultimo update applicato. Senza questi quattro elementi si rischia di discutere di “quanto è vecchio” invece di decidere se è il momento di aggiornare.

Strategia corretta di aggiornamento

La strategia meno rischiosa è sempre la stessa: laboratorio, pilota, produzione. Prima validi l’upgrade in un ambiente non critico, poi lo applichi a un site di test o a una finestra controllata, infine estendi il rollout. In SCCM questa prudenza non è eccesso: è igiene operativa. La piattaforma tocca distribuzione software, compliance, inventory, task sequence e spesso anche gli endpoint più delicati dell’organizzazione.

Prima del cambio, fai sempre un backup coerente della configurazione, verifica lo stato di SQL, controlla spazio disco, e annota la versione attuale. Se qualcosa va storto, il rollback reale di un Configuration Manager site non è sempre banale, quindi la prevenzione vale più di un tentativo di recupero a posteriori. Non è il tipo di piattaforma su cui improvvisare durante una finestra notturna con metà team offline.

Un dettaglio spesso trascurato: il supporto della Current Branch non riguarda solo il site server. Anche client, console, prerequisiti di SQL e componenti integrati devono restare compatibili. Aggiornare il core senza verificare il resto crea un falso senso di sicurezza. Il sito può risultare “supported”, ma l’ambiente no.

Esempio operativo: cosa fare quando scopri una release in scadenza

Mettiamo che dalla console risulti una versione prossima alla fine supporto. La risposta corretta non è “poi lo facciamo”, ma aprire subito un change controllato. Il piano minimo è questo: raccogli la versione attuale, recupera il lifecycle Microsoft, identifica la release target supportata, verifica prerequisiti e compatibilità, poi definisci una finestra di migrazione con test e rollback documentati.

Se invece la release è già fuori supporto, il rischio cambia tono. In quel caso la domanda non è più se aggiornare, ma quanto velocemente puoi farlo senza rompere la gestione dei client. Prima ancora di toccare la produzione, conviene congelare le altre modifiche sulla piattaforma, così non sommi variabili. Più il sito è vecchio, più serve disciplina sui change.

Errore tipico: fidarsi del nome “Current Branch”

Il nome “Current Branch” induce molti operatori a pensare a qualcosa di sempre attuale per definizione. È un’abbreviazione mentale comoda, ma pericolosa. La branch è “current” nel modello di rilascio, non nella tua installazione reale. La tua istanza può essere ferma da mesi, con una release perfettamente documentata ma ormai fuori finestra.

Per questo in audit e in incident response conviene sempre scrivere la versione completa, non il solo nome del prodotto. Dire “abbiamo SCCM Current Branch” è troppo generico. Dire “abbiamo Configuration Manager Current Branch build X.Y, verificata in console il giorno Z” è una frase utile, verificabile e spendibile in un change advisory board.

Riferimento da usare sempre prima di decidere

Se devi decidere oggi se sei coperto, la sequenza è semplice: leggi la versione dalla console, vai al lifecycle ufficiale Microsoft, confronta il dato e verifica il tempo residuo. Se il margine è stretto, pianifica l’upgrade; se è già scaduto, tratta la migrazione come priorità. È un controllo che richiede pochi minuti e ti evita settimane di debito tecnico.

La domanda giusta non è “SCCM Current Branch è supportato?”, ma “questa build precisa è ancora dentro la finestra di supporto, e per quanto tempo ancora?”.

Se vuoi un processo solido, tieni un inventario delle versioni e una scadenza associata a ogni site. È una misura banale, ma nei team che gestiscono più ambienti fa la differenza tra un upgrade programmato e una corsa contro il tempo. Assunzione: l’ambiente è di produzione e la priorità è ridurre il rischio operativo prima di introdurre cambiamenti.