1 20/05/2026 8 min

Disponibile ConfigMgr Technical Preview 2101: per chi gestisce ambienti Microsoft Endpoint Configuration Manager, questa build è interessante soprattutto per due motivi: da un lato porta novità utili per testare il flusso di gestione, dall’altro è un buon promemoria su come tenere pulito il laboratorio prima di applicare una preview. Con una technical preview non si lavora mai “alla cieca”: si verifica il prerequisito, si fotografa lo stato del sito, si esegue l’upgrade e si controlla subito la salute del management point, del provider e della console.

Il punto pratico è semplice: una technical preview serve a validare funzioni e comportamento, non a sostituire un ambiente di produzione. Se hai un hierarchy stabile, il criterio corretto è separare chiaramente il laboratorio dal resto dell’infrastruttura, usare backup o snapshot coerenti e avere sempre chiaro il rollback. In altre parole: prima osservabilità, poi installazione.

Cosa controllare prima di installare la Technical Preview 2101

Prima di lanciare l’upgrade, conviene verificare tre cose: connettività verso i server Microsoft, stato della console/servizi di ConfigMgr e spazio disco sufficiente sul site server. In molte installazioni i problemi non arrivano dal pacchetto in sé, ma da prerequisiti trascurati: proxy, cache corrotta, componenti SQL con warning già presenti o repository WMI non in salute.

Una check minimale, lato server, parte dai servizi principali e dai log recenti. I nomi possono variare in base al ruolo, ma il controllo è sempre lo stesso: il sito deve essere già pulito prima del cambio di versione.

Get-Service SMS_EXECUTIVE, SMS_SITE_COMPONENT_MANAGER, SMS_AGENT_HOST, CcmExec | Format-Table Name, Status, StartType

Se uno di questi servizi non è in stato Running, il problema va chiarito prima dell’upgrade. Lo stesso vale per eventuali errori ricorrenti nei log del sito, in particolare quelli relativi a componenti SQL, repliche, inventory o distribution point. Il controllo rapido sui log permette di distinguere un sito sano da uno che sta solo “funzionando abbastanza”.

Un secondo punto è il disco. La technical preview può richiedere spazio aggiuntivo per estrazione, staging e aggiornamento componenti. Se il volume di sistema è tirato, il rischio è un’installazione incompleta o un rollback sporco. Verifica sempre con una query semplice e guarda la percentuale libera reale, non solo i gigabyte residui “a occhio”.

Get-PSDrive -PSProvider FileSystem | Select-Object Name, Used, Free

Per chi usa un proxy o una rete filtrata, va anche considerata la raggiungibilità verso i repository e i servizi di download. Se il server non riesce a recuperare il pacchetto o i metadata, l’update si ferma prima ancora di iniziare. In quel caso la diagnosi non è “ConfigMgr non si aggiorna”, ma “il site server non esce correttamente verso Internet o verso il canale previsto”.

Novità da considerare in un laboratorio ConfigMgr

Le technical preview di ConfigMgr servono a testare il ciclo di vita delle funzioni prima che arrivino nelle release più stabili. Il valore non sta solo nella lista delle novità, ma nel capire se la tua architettura è pronta a gestirle: console aggiornata, ruoli coerenti, task sequence compatibili, reporting che non si rompe e permessi che non bloccano l’operatività quotidiana.

In pratica, quando arriva una preview devi chiederti subito: la nuova funzione impatta i client, il contenuto distribuito o la gestione dei dispositivi? Se cambia il comportamento di compliance, discovery, deployment o management point, il test deve includere almeno un client pilota, un controllo dei log lato site server e una verifica della console dopo l’aggiornamento.

Un errore classico è installare la preview e limitarsi a “aprire la console”. Non basta. Vanno verificati almeno questi punti: sincronizzazione delle informazioni del sito, apertura corretta delle viste principali, distribuzione contenuti, policy verso i client e stato dei componenti di sistema. Se una nuova build introduce una regressione, la console può aprirsi senza problemi mentre il sito smette di distribuire o di raccogliere inventario.

Installazione della Technical Preview 2101: procedura operativa

La procedura corretta è lineare, ma va fatta con disciplina. Prima si prepara il laboratorio, poi si avvia l’update, infine si controllano log e componenti. Se il tuo ambiente ha un solo site server, il blast radius è più alto: il rollback deve essere già pensato prima di cliccare su Install.

  1. Apri la console di Configuration Manager con un account che abbia privilegi amministrativi sul sito.
  2. Vai nella sezione degli aggiornamenti disponibili e individua la build technical preview 2101.
  3. Verifica i prerequisiti mostrati dalla console e correggi eventuali warning bloccanti prima di procedere.
  4. Avvia l’installazione e monitora lo stato del pacchetto, senza chiudere la console.
  5. Controlla i log del sito durante e dopo l’upgrade per intercettare errori di prerequisiti, download o setup.

Se preferisci un controllo lato file system, il sito lascia tracce utili nei log del componente di update e nei log generali del site server. I percorsi possono variare, ma in un’installazione standard trovi riferimenti in aree come Logs sotto la directory di installazione di Configuration Manager. Il punto non è memorizzare il path a occhi chiusi: è sapere quale log guardare in base al sintomo.

Durante l’installazione osserva almeno tre segnali: il download del contenuto, l’applicazione del pacchetto e la successiva riapertura della console. Se il download si ferma, il problema è spesso di connettività o cache. Se il setup parte e poi fallisce, guarda prima i prerequisiti e poi eventuali dipendenze di sistema. Se la console non riflette il nuovo stato, verifica il provider WMI e la replica delle informazioni del sito.

Get-Process cmupdate, ccmexec, smsprov -ErrorAction SilentlyContinue

In un laboratorio ben tenuto, l’upgrade non dovrebbe richiedere interventi manuali invasivi. Se invece devi fermarti a metà, la scelta giusta non è “andare avanti e sperare”: congela il cambiamento, raccogli i log, annota lo stato del sito e valuta il rollback secondo la procedura prevista dal tuo ambiente.

Verifiche post-installazione che non vanno saltate

Dopo l’installazione, la prima verifica utile è banale ma fondamentale: la console deve aprirsi senza errori e mostrare la nuova versione. Subito dopo vanno controllati i ruoli principali del sito e la capacità di eseguire operazioni ordinarie, non solo la navigazione tra i menu. Se un aggiornamento ha introdotto una regressione, spesso si vede lì: nelle azioni quotidiane, non nella schermata iniziale.

Le verifiche pratiche, in ordine, sono queste:

  1. Apri la console e conferma la build installata nelle informazioni sul prodotto.
  2. Controlla lo stato dei ruoli del sito e dei componenti critici.
  3. Esegui una distribuzione di test verso un collection pilota.
  4. Verifica che almeno un client riceva policy e inventory in tempi coerenti con il normale comportamento del laboratorio.
  5. Ispeziona i log del client e del site server per errori nuovi o warning ricorrenti.

Per il client, i log più utili dipendono dall’attività testata: policy, inventory, content download, compliance o deployment. Non serve aprire tutto insieme. Serve una sequenza logica: prima il sintomo, poi il log giusto. Se un client non riceve policy dopo l’upgrade, il problema può essere nel sito, nel boundary, nella comunicazione o nel repository locale; il log del client ti aiuta a capire in quale punto si interrompe il flusso.

Se vuoi una verifica rapida lato shell, puoi confrontare il comportamento di un client con un test mirato sulla connettività verso il management point o verso il distribution point, sempre nel rispetto del tuo perimetro di test. L’obiettivo non è fare troubleshooting generico, ma dimostrare che la build non ha alterato il percorso normale di gestione.

Test-NetConnection -ComputerName <MP-o-DP> -Port 443

Se il tuo ambiente usa HTTPS, la verifica del certificato è parte del controllo post-upgrade. Un sito che sembra sano ma presenta errori TLS su console, client o ruoli distribuiti non è davvero pronto. Controlla scadenza, catena, binding e corrispondenza del nome con gli endpoint pubblicati.

Quando fermarsi e non proseguire

Ci sono tre casi in cui conviene fermarsi subito: errori di prerequisiti non risolti, log di installazione con fallimenti ripetuti e comportamento anomalo dei ruoli dopo il riavvio del servizio o del server. In questi casi insistire non migliora la situazione. Anzi, allarga solo il tempo di esposizione a un sito parzialmente aggiornato.

La regola pratica è semplice: se il sito non torna in uno stato coerente, stop. Conserva i log, annota l’ora dell’intervento, verifica se sono stati modificati componenti esterni come SQL, proxy, antivirus o policy di hardening, e valuta il rollback secondo il piano di laboratorio. Se manca un piano di ripristino, quella è la vera lacuna da chiudere prima del prossimo test.

Un dettaglio spesso sottovalutato riguarda la concorrenza con altre attività amministrative. Se durante l’upgrade ci sono job di manutenzione SQL, backup a caldo, scansioni EDR o rotazioni di certificati, il rumore operativo aumenta e la diagnosi peggiora. In un laboratorio serio le finestre di manutenzione si coordinano, non si sovrappongono per comodità.

Un approccio pulito per tenere sotto controllo le preview

Il modo migliore per gestire una technical preview è trattarla come una change controllata: inventario dello stato iniziale, finestra di intervento, verifica finale e rollback definito. Questo vale ancora di più con ConfigMgr, dove il confine tra site server, database, console e client è stretto e un errore in un punto si riflette rapidamente sugli altri.

Se documenti bene il prima e il dopo, la preview non è un salto nel buio ma un test utile. Ti resta una traccia concreta: versione installata, log consultati, componenti verificati, eventuali warning e decisione finale. È il tipo di disciplina che riduce le sorprese quando la funzione passa da laboratorio a release più ampia.

In sintesi operativa: controlla i prerequisiti, installa solo in ambiente adatto, verifica console e ruoli, testa i client pilota e tieni pronto il rollback. Con ConfigMgr 2101 Technical Preview, il valore non è “avere la novità subito”, ma capire presto se il tuo stack è davvero pronto a reggerla.