SCCM 2301 Preview Tecnica: novità e installazione

SCCM 2301 Preview non è una release da trattare come un normale aggiornamento di produzione. È una build di anteprima, utile per verificare compatibilità, novità della console e impatti operativi prima di decidere se adottarla nel ramo stabile. In pratica: si installa in un ambiente controllato, si misura l’effetto sui workflow reali e si tiene pronta una via di ritorno. Se l’obiettivo è capire cosa cambia e come provarla in sicurezza, conviene ragionare per impatto su site server, console, client e integrazioni esterne.

Cosa cambia davvero in una Preview Tecnica

La parola chiave è validazione. Una preview introduce funzionalità nuove o correzioni che possono toccare oggetti sensibili: distribuzione contenuti, raccolta inventario, compliance, task sequence, aggiornamenti software e automazione. Non va letta come “nuova versione pronta”, ma come un ambiente in cui il vendor ti chiede implicitamente di scoprire incompatibilità prima degli altri.

Nel contesto Microsoft Endpoint Configuration Manager, una preview serve soprattutto a verificare tre cose: se la console resta coerente con i flussi di amministrazione quotidiani, se i client continuano a comportarsi come previsto e se l’infrastruttura di supporto — SQL, distribution point, management point, WSUS/SUP, boundary groups — regge senza effetti collaterali. Il punto non è “funziona l’installazione”, ma “resta affidabile il sistema dopo l’upgrade”.

Prima di installare: inventario minimo e punti di rottura

Prima di toccare il site server, conviene fotografare il perimetro. Se manca questo passaggio, il troubleshooting diventa subito più costoso perché non distingui il difetto introdotto dalla preview da un problema già presente. I punti da fissare sono pochi ma concreti.

• Versione corrente del site e build della console.
• Topologia: primary site, CAS se presente, number of MPs/DPs/SUP.
• Stato di SQL e spazio libero sui volumi che ospitano content library, package source e log.
• Eventuali integrazioni: Intune, Azure AD, co-management, patching, reporting esterno.
• Finestre di manutenzione e piano di rollback.

Se vuoi una verifica rapida dello stato lato Windows Server, i controlli base sono banali ma utili: spazio disco, servizi critici, salute SQL e reachability verso i ruoli. Un esempio minimo:

Get-Service SMS_EXECUTIVE, SMS_SITE_COMPONENT_MANAGER, W3SVC, CcmExec | Select Name, Status
Get-PSDrive -PSProvider FileSystem | Select Name, Free, Used
Test-NetConnection -ComputerName <sql-server> -Port 1433

Se uno di questi controlli fallisce prima dell’upgrade, il problema non è la preview: sistemalo prima, altrimenti ti ritrovi a inseguire falsi positivi.

Novità da osservare nel ramo 2301 Preview

In una preview la lista esatta delle novità dipende dal pacchetto e dalle note di rilascio del canale Microsoft, ma l’operatività cambia quasi sempre in alcune aree ricorrenti. Le più interessanti da validare in laboratorio sono quelle che impattano la gestione quotidiana, non le sole schermate nuove.

Console e flussi amministrativi

La console è il primo punto da stressare. Apri i nodi che usi davvero: Applications, Device Collections, Monitoring, Software Updates, Task Sequences. Se la preview introduce nuove proprietà o nuove azioni contestuali, verifica che i ruoli RBAC continuino a limitare correttamente ciò che un operatore può vedere e modificare. Un errore classico nelle preview è dare per scontato che la UI sia solo cosmetica: spesso invece cambia il backend chiamato dalla console, e lì emergono inconsistenze con permessi o prerequisiti non documentati bene.

Content distribution e boundary handling

Il cuore della piattaforma resta la distribuzione contenuti. Qualsiasi modifica ai processi di DP o ai criteri di selezione boundary group va testata con pacchetti grandi, applicazioni con dependency chain e task sequence che richiedono download consistenti. Qui il segnale utile non è “job started”, ma il tempo di propagazione e la percentuale di successo nel trasferimento. Se hai già metriche, confronta prima e dopo su un campione realistico, non su un pacchetto vuoto creato apposta per il test.

Co-management e integrazione cloud

Se l’ambiente è ibrido, la preview va osservata con ancora più attenzione. La parte delicata è la coerenza tra policy on-prem e cloud, soprattutto quando il tenant ha già workload spostati verso Intune. Controlla che i criteri di split dei workload non cambino comportamento dopo l’aggiornamento della console o dei componenti del site. In pratica, bisogna verificare che i device continuino a ricevere la policy dal canale previsto e non da un fallback inatteso.

Prerequisiti di installazione: cosa non saltare

Il setup di SCCM 2301 Preview segue la logica classica degli update del product family, ma la differenza vera la fa la disciplina del pre-check. Il prerequisito più importante è che il site sia in salute prima di partire. Se il componente baseline è già sporco, l’upgrade tende a fermarsi su warning oppure, peggio, a completarsi lasciando in coda errori laterali.

1. Verifica che il site server non abbia errori critici aperti in hman.log, sitecomp.log, smsexec.log e distmgr.log.
2. Controlla che SQL abbia spazio, backup recenti e nessuna manutenzione bloccata.
3. Assicurati che la console usata per l’upgrade sia compatibile con la versione che stai installando.
4. Conferma la reachability verso Microsoft update e i repository necessari se il percorso scelto usa download online.
5. Prepara una finestra di manutenzione con rollback definito.

Un controllo utile lato servizi è il seguente:

Get-Service SMS_EXECUTIVE, SMS_SITE_COMPONENT_MANAGER, SMS_NOTIFICATION_SERVER, W3SVC | Format-Table -Auto

Se uno dei servizi chiave è fermo senza motivo noto, non proseguire con l’installazione. Prima recupera il motivo dal log corrispondente, poi riparti. In un ambiente SCCM sano, gli update non dovrebbero essere usati per “provare a vedere se si sistema”.

Installazione: percorso operativo pulito

Il flusso tipico è semplice: scarico del pacchetto, avvio del wizard o applicazione del bundle, monitoraggio dei prerequisiti, completamento e verifica della replication interna. La parte che fa la differenza è la disciplina nel leggere i log giusti mentre il setup è in corso. I log da guardare sono quelli del site server e del setup, non solo la schermata del wizard.

1. Scarica il pacchetto preview dal canale previsto e conserva hash o integrità se disponibili.
2. Lancia l’upgrade dal console update node o dal metodo previsto dalla release note.
3. Monitora CMUpdate.log, ConfigMgrSetup.log e i log di componenti correlati.
4. Attendi il completamento della fase di prerequisiti prima di chiudere il wizard.
5. Dopo il completion, lascia tempo alla replication interna e controlla lo stato del site.

Un esempio di approccio da shell per tenere sotto controllo il log principale è questo:

Get-Content 'C:\Program Files\Microsoft Configuration Manager\Logs\CMUpdate.log' -Wait

Durante l’installazione, il rischio principale è confondere un rallentamento normale della replication con un blocco vero. Se il wizard resta fermo ma i log mostrano attività e nessun errore ripetuto, spesso è solo una fase lunga. Se invece compaiono errori di prerequisito, fermati subito e correggi il problema alla radice.

Log e segnali da leggere per non andare a intuito

In SCCM il log è spesso più utile della GUI, soprattutto quando stai testando una preview. I file che vale la pena aprire subito sono quelli che spiegano lo stato del site, la distribuzione contenuti e la salute dei componenti. Non serve leggerli tutti: servono pochi file, letti nel momento giusto.

• CMUpdate.log: avanzamento dell’update e blocchi legati al pacchetto.
• ConfigMgrSetup.log: prerequisiti e installazione componenti.
• hman.log: aggiornamento dell’architettura dati e metadata.
• sitecomp.log: stato dei componenti del site.
• distmgr.log: distribuzione contenuti verso DP.
• wsyncmgr.log: sincronizzazione aggiornamenti software, se rilevante.

Se non sai da dove partire, la regola è questa: update non parte o non si completa = CMUpdate.log; componenti strani dopo upgrade = sitecomp.log; problemi con contenuti = distmgr.log. È un metodo semplice, ma evita di perdere tempo in file che non c’entrano.

Verifiche post-installazione che contano davvero

Dopo il completamento non basta vedere la console aprirsi. Serve una verifica funzionale su attività reali. Il controllo corretto è: il site continua a fare ciò che faceva prima, senza errori nuovi e senza degrado evidente nei tempi di risposta.

1. Apri la console con un account standard di amministrazione RBAC e verifica che i nodi critici siano accessibili.
2. Controlla lo stato dei componenti del site in Monitoring.
3. Distribuisci una piccola applicazione di test a una collection limitata e osserva il completamento.
4. Verifica che almeno un client riceva policy e reporti correttamente verso il management point.
5. Se usi software updates, conferma che scan e compliance restino coerenti con il ciclo precedente.

Per una verifica lato client, un controllo minimo può essere quello di guardare la presenza dei log e la cadenza degli update policy. Esempio:

Get-Service CcmExec
Get-ChildItem 'C:\Windows\CCM\Logs' | Sort-Object LastWriteTime -Descending | Select-Object -First 5 Name, LastWriteTime

Se i client smettono di aggiornarsi ma il site sembra sano, il problema è spesso a valle: boundary, MP, certificati, firewall o policy che non arrivano. La preview non è automaticamente la colpa; va dimostrato con log e timeline.

Rollback e blast radius: come non farsi male

Il rollback di una preview è il punto che molti sottovalutano. La domanda non è se “si può tornare indietro”, ma quanto costa. Se hai un primary site singolo, il blast radius è alto perché tocchi il punto di controllo dell’intero ambiente. Per questo un backup consistente del server, snapshot solo se davvero coerenti con la tua policy e un export della configurazione precedente sono il minimo sindacale.

• Blast radius: console, site server, client policy, content distribution, reporting.
• Rollback minimo: restore del backup del site server o ritorno alla build precedente secondo procedura supportata dal vendor.
• Prima di procedere: esporta note operative, versione, stato componenti e cambi introdotti nella finestra.

Se l’installazione è stata fatta in lab, il rollback è semplice: ripristino della VM o del backup. Se invece hai scelto di provarla in un ambiente di preproduzione condiviso, il rollback deve essere concordato con chi gestisce SQL, storage e integrazioni. Non improvvisare: in SCCM l’effetto collaterale più costoso è quasi sempre il tempo perso a ricostruire una baseline non documentata.

Quando ha senso provarla e quando no

Ha senso provarla se stai preparando un upgrade futuro, se vuoi verificare una correzione che ti serve davvero o se hai un laboratorio che replica il più possibile il tuo ambiente. Non ha senso installarla in fretta “per curiosità” su un site che serve utenti reali e che non hai modo di tornare indietro in modo pulito.

La regola pratica è questa: se non puoi misurare il prima e il dopo, stai solo accumulando rumore. Una preview è utile quando ti aiuta a ridurre il rischio della prossima release stabile; è inutile quando introduce complessità senza un obiettivo operativo chiaro.

In ambienti SCCM maturi, il valore di una preview non sta nella novità in sé, ma nella possibilità di scoprire in anticipo cosa si rompe quando il sistema incontra il tuo modo reale di lavorare.

Se vuoi usarla bene, trattala come un test di compatibilità, non come un upgrade cosmetico. È questo l’atteggiamento che evita di trasformare una prova tecnica in un incidente operativo.