Aggiornamento cumulativo Windows 11 di luglio 2026 (KB5101650)

Simone Termine

Introduzione

Microsoft ha pubblicato gli aggiornamenti cumulativi di luglio 2026 per le versioni di Windows ancora supportate. Per Windows 11, la KB principale è KB5101650, destinata alle versioni 25H2 e 24H2, mentre i dispositivi con Windows 11 23H2 ricevono l’aggiornamento separato KB5099414. Per Windows 10 è invece disponibile KB5099539, riservata ai dispositivi coperti dal programma Extended Security Updates (ESU) e alle edizioni LTSC 2021 ancora incluse nel ciclo di supporto.

Gli aggiornamenti, distribuiti in occasione del Patch Tuesday del 14 luglio 2026, includono le correzioni di sicurezza del mese e, nel caso di KB5101650, anche i miglioramenti già introdotti con la preview KB5095093 pubblicata a giugno. Tra gli aspetti che richiedono maggiore attenzione negli ambienti aziendali rientrano le modifiche alla compatibilità con alcuni componenti di rete legacy, la correzione del problema che interessava le applicazioni basate su OLE Automation e il proseguimento delle attività legate al rinnovo dei certificati Secure Boot.

Nel corso dell’articolo analizzeremo le build installate, le modifiche più rilevanti e i controlli da effettuare prima di distribuire gli aggiornamenti attraverso Windows Update for Business, Microsoft Intune, Windows Autopatch, WSUS o Configuration Manager.

Le KB di luglio 2026

Anche a luglio Windows 11 25H2 e 24H2 condividono lo stesso aggiornamento cumulativo, pur raggiungendo build differenti, mentre Windows 11 23H2 riceve una KB separata. Microsoft ha pubblicato aggiornamenti specifici anche per Windows 11 26H1 e per le installazioni di Windows 10 che continuano a ricevere correzioni attraverso il programma Extended Security Updates o il canale LTSC.

KB5101650 per Windows 11 25H2 e 24H2

Con l’installazione di KB5101650, Windows 11 25H2 viene aggiornato alla build 26200.8875, mentre Windows 11 24H2 raggiunge la build 26100.8875. Il pacchetto comprende le correzioni di sicurezza pubblicate a luglio, i miglioramenti già distribuiti con KB5094126 e le novità introdotte attraverso l’aggiornamento facoltativo KB5095093 del 23 giugno 2026.

Come avviene sempre più spesso con gli aggiornamenti di Windows 11, alcune funzionalità incluse nel pacchetto vengono abilitate attraverso un rollout graduale. Di conseguenza, due dispositivi che eseguono la stessa build potrebbero non mostrare immediatamente le stesse opzioni o modifiche dell’interfaccia, perché la disponibilità può dipendere dalla fase di distribuzione, dal modello del dispositivo e, in alcuni casi, dall’area geografica.

Tra le novità provenienti dalla preview di giugno troviamo Point-in-time restore, un nuovo calendario per scegliere la data fino alla quale sospendere gli aggiornamenti, diversi interventi su Esplora file, miglioramenti alla connettività Bluetooth, nuove opzioni di accessibilità e un comportamento aggiornato per l’installazione delle stampanti compatibili con Internet Printing Protocol (IPP) e Windows Ready Print.

Point-in-time restore

Point-in-time restore consente di riportare il dispositivo a uno stato precedente utilizzando punti di ripristino creati automaticamente e archiviati localmente tramite Volume Shadow Copy Service (VSS). Il ripristino comprende il sistema operativo, le applicazioni installate, le configurazioni, le impostazioni e i file locali, con l’obiettivo di ridurre i tempi necessari per recuperare un dispositivo dopo un aggiornamento problematico, un errore applicativo o una modifica indesiderata.

La funzionalità utilizza, per impostazione predefinita, punti creati con una frequenza approssimativa di 24 ore e permette di recuperare uno stato conservato nelle ultime 72 ore. Durante il ripristino vengono annullate tutte le modifiche effettuate dopo il punto selezionato, comprese quelle relative a file, applicazioni, password, certificati e chiavi presenti localmente; i dati archiviati nei servizi cloud, come Microsoft OneDrive, non vengono invece ripristinati insieme al dispositivo.

Nella fase iniziale, il ripristino viene avviato da Windows Recovery Environment (WinRE) e, sui dispositivi protetti con BitLocker, richiede l’inserimento della relativa chiave di ripristino. Prima di abilitare la funzionalità in produzione è quindi opportuno verificare che le recovery key siano correttamente archiviate e accessibili, oltre a valutare lo spazio disco necessario e il comportamento delle applicazioni aziendali dopo il ritorno a una configurazione precedente.

Miglioramenti a Esplora file

La preview di giugno introduce numerosi interventi su Esplora file, con l’obiettivo di migliorarne prestazioni e affidabilità. Microsoft segnala tempi di apertura più rapidi, una maggiore reattività durante il montaggio delle immagini disco, una gestione più coerente dei suggerimenti nella barra degli indirizzi e diverse correzioni relative alla rinomina dei file, comprese le modifiche che interessano esclusivamente l’uso di lettere maiuscole e minuscole.

Sono stati risolti anche alcuni comportamenti anomali nella sezione Home, tra cui la possibile duplicazione dei file OneDrive nei Preferiti. La correzione relativa al collegamento OneDrive che smetteva di funzionare quando Esplora file veniva avviato con privilegi amministrativi è stata successivamente portata al rollout normale, rendendola disponibile per tutti i dispositivi idonei.

Nuovo comportamento per l’installazione delle stampanti

Per le nuove installazioni, Windows può ora utilizzare IPP come protocollo predefinito quando la stampante lo supporta, riducendo la dipendenza dai driver forniti dal produttore e favorendo l’adozione di Windows Ready Print. Il comportamento può essere controllato da Impostazioni > Bluetooth e dispositivi > Stampanti e scanner, attraverso l’opzione dedicata all’installazione predefinita delle stampanti con Windows Ready Print.

Negli ambienti che utilizzano print server tradizionali o periferiche specialistiche, il supporto a IPP non garantisce infatti che tutte le opzioni disponibili con il driver del produttore vengano mantenute. Il test deve quindi concentrarsi sui flussi di stampa effettivamente utilizzati dagli utenti, evitando di limitare la verifica alla sola creazione della coda o alla stampa di una pagina di prova.

Corretto il problema OLE con Microsoft Office

Tra le correzioni più rilevanti incluse in KB5101650 troviamo la risoluzione del problema che, dopo l’installazione dell’aggiornamento di sicurezza di giugno KB5094126, poteva impedire ad alcune applicazioni di terze parti di avviare Microsoft Office o di aprire i documenti richiesti. L’anomalia interessava i software che utilizzano OLE Automation per interagire con applicazioni come Word, Excel, PowerPoint o Access e, in alcuni casi, poteva presentarsi senza mostrare alcun messaggio di errore.

Il problema riguardava quindi soprattutto le integrazioni tra Office e applicazioni gestionali, documentali o verticali, mentre la normale apertura manuale dei programmi Microsoft 365 poteva continuare a funzionare senza evidenziare comportamenti anomali. Microsoft aveva ricevuto segnalazioni relative a software contabili, applicazioni per studi dentistici e strumenti come Zotero, precisando tuttavia che anche altri prodotti basati sullo stesso meccanismo potevano essere interessati.

Con l’installazione di KB5101650, Microsoft considera il problema risolto su Windows 11 25H2 e 24H2. La correzione è stata inclusa anche negli aggiornamenti di luglio destinati alle altre versioni supportate di Windows, ma verrà richiamata nelle rispettive sezioni senza ripeterne nuovamente il funzionamento.

Negli ambienti nei quali il problema era già stato segnalato, dopo l’aggiornamento conviene verificare non soltanto l’apertura del documento, ma anche le operazioni successive previste dal processo aziendale, come la compilazione dei dati, il salvataggio, l’esportazione e la chiusura dell’applicazione Office. Questo controllo permette di confermare che l’intera integrazione sia tornata operativa e non soltanto che il programma venga avviato correttamente.

Correzione del problema DISM su Windows 11 24H2

Nella documentazione relativa all’aggiornamento di giugno, Microsoft ha aggiunto il 14 luglio una nuova nota riguardante Deployment Image Servicing and Management (DISM). Su alcuni dispositivi con Windows 11 24H2, il comando /RestoreHealth poteva terminare con l’errore 0x800f0915, impedendo la riparazione del component store e complicando le normali attività di recupero del sistema operativo.

Poiché KB5101650 è un aggiornamento cumulativo e comprende le correzioni distribuite nei pacchetti precedenti, i dispositivi che avevano manifestato il problema dovrebbero tornare a eseguire correttamente il comando dopo l’installazione dell’aggiornamento di luglio. Negli ambienti nei quali l’errore era già stato rilevato, è consigliabile ripetere il controllo utilizzando:

DISM.exe /Online /Cleanup-Image /RestoreHealth

La verifica non deve essere eseguita indiscriminatamente su tutto il parco macchine, ma può essere utile sui dispositivi che avevano già generato l’errore o sui quali erano rimaste in sospeso attività di riparazione del component store.

Hardening dei trasporti TDI di terze parti

La modifica con il maggiore potenziale di impatto applicativo riguarda i trasporti Transport Driver Interface (TDI) di terze parti. TDI è una tecnologia legacy utilizzata da alcuni driver e componenti di rete; la relativa documentazione prevede da tempo che ogni trasporto impiegato per la comunicazione tramite socket venga registrato correttamente, ma prima degli aggiornamenti di luglio Windows non applicava questo requisito in maniera rigida.

Con gli aggiornamenti di sicurezza pubblicati dal 14 luglio 2026, Windows blocca invece l’utilizzo come socket transport dei provider TDI che non risultano registrati. I componenti conformi ai requisiti non subiscono modifiche, mentre un’applicazione che dipende da un provider non registrato potrebbe perdere la connettività o smettere completamente di funzionare dopo l’installazione della KB.

Il rischio riguarda soprattutto applicazioni legacy, vecchi client VPN, driver proprietari, agent di filtraggio del traffico e software verticali che installano componenti di rete non più aggiornati dal produttore. La presenza di uno di questi prodotti non implica automaticamente l’utilizzo di TDI, ma rappresenta un buon criterio per costruire un gruppo pilota realmente rappresentativo.

Quando viene rilevato un provider non registrato, Windows genera nel registro System un evento del provider AFD con ID 16003 e il messaggio relativo al rilevamento di un provider TDI non registrato. L’evento viene scritto una sola volta per ogni ciclo di riavvio, quindi la sua assenza immediatamente dopo l’installazione non esclude che il componente venga utilizzato soltanto durante uno specifico processo applicativo.

È possibile effettuare una prima verifica con PowerShell:

Get-WinEvent -FilterHashtable @{
      LogName = 'System'
      Id      = 16003
  } -ErrorAction SilentlyContinue |
Select-Object TimeCreated, ProviderName, Id, Message

Il comportamento può essere controllato attraverso il valore AfdTdiUnknownProviderValidationLevel, di tipo REG_DWORD, disponibile nel percorso HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters

Microsoft raccomanda di mantenere il livello di validazione almeno su 2 e di aggiornare o sostituire i componenti che non rispettano il requisito di registrazione. I valori 0 e 1 possono essere utilizzati come mitigazione temporanea, ma lasciano il sistema esposto al rischio che l’hardening è stato progettato per ridurre.

Se dopo l’installazione dell’aggiornamento un’applicazione perde improvvisamente la connettività, la ricerca dell’evento AFD 16003 dovrebbe rientrare tra i primi controlli. La diagnosi deve comunque proseguire verificando quale driver o applicazione abbia installato il provider, perché la modifica del registro elimina il blocco ma non risolve la mancata conformità del componente.

Remote Desktop e supporto per i thumbprint SHA-2

KB5101650 introduce il supporto ai thumbprint dei certificati SHA-2 per i publisher attendibili delle connessioni Remote Desktop. Il supporto a SHA-1 viene mantenuto esclusivamente per compatibilità con le configurazioni esistenti, mentre Microsoft ne prevede la rimozione in una futura versione di Windows e raccomanda di migrare verso SHA-256 o un algoritmo più robusto.

La modifica interessa principalmente gli ambienti che distribuiscono file .rdp firmati o che utilizzano criteri per riconoscere determinati publisher come attendibili. Non determina un’interruzione immediata delle configurazioni basate su SHA-1, ma rende opportuno censire i file RDP distribuiti agli utenti, le firme applicate e gli eventuali thumbprint inseriti in criteri, script o procedure interne.

Nello stesso contesto, Microsoft ha pubblicato nuove indicazioni per controllare tramite Group Policy quali file .rdp possano essere aperti dagli utenti, con l’obiettivo di ridurre il rischio di phishing e di connessioni Remote Desktop avviate da file non attendibili.

Il test dovrebbe comprendere l’apertura dei collegamenti RDP realmente distribuiti agli utenti, verificando sia l’assenza di avvisi inattesi sia il corretto riconoscimento del publisher. Limitarsi ad avviare manualmente mstsc.exe non permette di validare la parte della configurazione interessata dalla modifica.

Secure Boot e distribuzione dei nuovi certificati

Anche l’aggiornamento di luglio prosegue il processo di rinnovo dei certificati Secure Boot. I certificati emessi nel 2011 e ancora presenti su molti dispositivi hanno iniziato a raggiungere la scadenza da giugno 2026 e devono essere sostituiti dai nuovi certificati del 2023, in modo che Windows possa continuare ad applicare protezioni e aggiornamenti ai componenti eseguiti nelle prime fasi dell’avvio.

Con KB5101650, Microsoft aggiunge nuovi dati di targeting ad alta affidabilità, aumentando il numero di dispositivi considerati idonei alla distribuzione automatica dei certificati aggiornati. Il rollout resta graduale e viene esteso soltanto ai modelli per i quali sono disponibili sufficienti segnali di compatibilità.

Un dispositivo che non ha ancora ricevuto i nuovi certificati continuerà normalmente ad avviarsi e a installare gli aggiornamenti standard di Windows. Nel tempo, tuttavia, potrebbe non ricevere nuove protezioni per il Boot Manager, i database Secure Boot e gli altri componenti eseguiti prima del caricamento del sistema operativo, con una conseguente riduzione del livello di sicurezza della catena di avvio.

Negli ambienti gestiti è quindi necessario continuare a monitorare lo stato dei certificati e la compatibilità del firmware, prestando particolare attenzione ai modelli meno recenti, ai dispositivi con configurazioni UEFI non uniformi e ai sistemi sui quali gli aggiornamenti firmware vengono distribuiti separatamente. Microsoft mette a disposizione procedure specifiche per il deployment tramite Microsoft Intune, criteri di gruppo, registro e Windows Configuration System.

Per approfondire la gestione centralizzata del rinnovo è opportuno collegare questa sezione agli articoli Endpoint Ninja dedicati ai certificati Secure Boot, evitando di ripetere in questo aggiornamento mensile l’intera procedura di distribuzione.

Attenzione al file boot.stl nelle immagini di installazione

La documentazione di KB5101650 contiene una nota specifica per chi aggiorna supporti di installazione o immagini Windows esistenti utilizzando pacchetti Dynamic Update. In questi scenari, il file boot.stl deve essere presente nel supporto e deve corrispondere alla versione e all’architettura dell’immagine che si sta aggiornando.

Il file viene utilizzato durante la validazione Secure Boot e, se risulta assente o non coerente con l’immagine, il dispositivo potrebbe non riuscire ad avviarsi dal supporto di installazione, mostrando l’errore 0xc0430001.

Microsoft raccomanda di utilizzare lo script Update WinPE per aggiornare l’immagine e includere automaticamente i componenti necessari. In alternativa, boot.stl può essere copiato dalla cartella Windows\Boot\EFI di un sistema con la stessa versione e architettura al percorso corrispondente del supporto di installazione.

Prima di utilizzare l’immagine in produzione conviene eseguire almeno un avvio completo del supporto su un dispositivo rappresentativo, verificando il caricamento di WinPE, la visibilità dei dischi, la connettività di rete e l’avvio della task sequence. In questo modo il controllo non resta limitato alla sola presenza del file, ma valida il processo di deployment nel suo insieme.

Aggiornamento di curl e modifica alla gestione degli hotkey

La versione di curl integrata in Windows viene aggiornata alla 8.21.0, includendo nuovi miglioramenti di sicurezza. Per la maggior parte degli utenti la modifica sarà trasparente, mentre negli ambienti nei quali curl.exe viene richiamato da script di provisioning, remediation o automazioni interne è opportuno verificare che l’esecuzione e l’elaborazione dell’output continuino a produrre il risultato previsto.

La versione installata può essere controllata con:

curl.exe --version

L’aggiornamento modifica inoltre il comportamento utilizzato da Windows per annullare la registrazione e ripulire le scorciatoie da tastiera. In circostanze rare, alcune esperienze integrate che dipendono dal precedente ciclo di vita degli hotkey potrebbero smettere temporaneamente di rispondere a una determinata combinazione di tasti; Microsoft indica che, nella maggior parte dei casi, il riavvio dell’applicazione interessata è sufficiente per ripristinare il funzionamento.

Non si tratta di un problema noto generalizzato della KB, ma di un possibile effetto collaterale della modifica. Se il riavvio dell’applicazione non risolve il comportamento, Microsoft invita a inviare la segnalazione tramite Feedback Hub.

Servicing Stack Update e componenti AI

KB5101650 integra il Servicing Stack Update KB5120102, build 26100.8872, che aggiorna i componenti utilizzati da Windows per installare e gestire gli aggiornamenti. La SSU è combinata con la cumulative update e non richiede quindi una distribuzione separata quando il pacchetto viene installato attraverso i normali canali di servicing.

Il pacchetto aggiorna inoltre alla versione 1.2605.856.0 i componenti AI denominati Image Search, Content Extraction, Semantic Analysis e Settings Model. Questi componenti sono applicabili esclusivamente ai Copilot+ PC compatibili e, pur essendo inclusi nel pacchetto, non vengono installati sui normali PC Windows o sui sistemi Windows Server.

Problemi noti di KB5101650

Al momento della pubblicazione, Microsoft dichiara di non essere a conoscenza di problemi noti aperti relativi a KB5101650 per Windows 11 25H2 e 24H2. La pagina della KB e il portale Windows release health devono comunque essere ricontrollati prima del broad deployment, perché la documentazione può essere aggiornata nei giorni successivi al rilascio iniziale.

L’assenza di known issues non sostituisce quindi il pilot e non esclude incompatibilità con applicazioni, driver o configurazioni specifiche dell’organizzazione. Oltre ai report di aggiornamento, durante i primi giorni è opportuno monitorare anche le segnalazioni del service desk, gli errori applicativi e gli eventi registrati sui dispositivi pilota.

KB5099414 per Windows 11 23H2

Per Windows 11 23H2, l’aggiornamento cumulativo di luglio è KB5099414, che porta il sistema operativo alla build 22631.7376. Il pacchetto comprende le correzioni di sicurezza del mese e i miglioramenti inclusi nell’aggiornamento precedente KB5093998.

La KB contiene la stessa correzione relativa a OLE Automation e introduce anche l’hardening dei trasporti TDI, il supporto ai thumbprint SHA-2 per i publisher RDP e l’aggiornamento di curl alla versione 8.21.0. Sono stati inoltre corretti il collegamento OneDrive che poteva smettere di funzionare quando Esplora file veniva avviato con privilegi amministrativi e il problema che mostrava il nome interno di un file nella finestra di conferma dell’eliminazione definitiva dal Cestino.

La descrizione tecnica del problema OLE, di TDI e delle modifiche RDP non viene ripetuta in questa sezione, perché il comportamento è già stato analizzato nei paragrafi precedenti. Per i dispositivi 23H2 devono essere applicati gli stessi criteri di pilot e le stesse verifiche, utilizzando naturalmente KB5099414 e la relativa build come riferimento.

Microsoft non segnala problemi noti aperti per questo aggiornamento. La SSU integrata è KB5104023, build 22621.7373.

A luglio 2026, tuttavia, il vero tema operativo di Windows 11 23H2 è il ciclo di vita. Le edizioni Home e Pro hanno già terminato il supporto l’11 novembre 2025, mentre Enterprise ed Education continueranno a ricevere aggiornamenti soltanto fino al 10 novembre 2026.

La fase di assessment dovrebbe essere ormai conclusa. A questo punto è necessario concentrarsi sui dispositivi bloccati da applicazioni, driver o requisiti hardware, distinguendo le eccezioni reali dai computer che possono essere aggiornati attraverso le normali policy di feature update.

KB5099539 per Windows 10 ESU e LTSC

Per le installazioni di Windows 10 ancora coperte dal supporto Microsoft è disponibile KB5099539. L’aggiornamento porta Windows 10 22H2 ESU alla build 19045.7548, mentre Windows 10 Enterprise LTSC 2021 e Windows 10 IoT Enterprise LTSC 2021 raggiungono la build 19044.7548.

Il pacchetto corregge il problema di compatibilità relativo a OLE Automation, l’anomalia del collegamento OneDrive e il nome interno mostrato nella finestra di conferma del Cestino. Introduce inoltre l’hardening TDI e il supporto ai thumbprint SHA-2 per i publisher Remote Desktop, proseguendo parallelamente la distribuzione dei nuovi certificati Secure Boot. Su Windows 10 viene aggiunto anche il reporting dinamico dello stato Secure Boot nell’app Sicurezza di Windows.

Microsoft non segnala problemi noti aperti per KB5099539 al momento della pubblicazione. Negli ambienti che mantengono Windows 10 per dipendenze applicative o hardware, il pilot dovrebbe concentrarsi sugli stessi componenti legacy che hanno impedito la migrazione, perché sono anche quelli con maggiore probabilità di utilizzare driver o tecnologie di rete meno recenti.

KB5101649 per Windows 11 26H1

I dispositivi che eseguono Windows 11 26H1 ricevono KB5101649, con la quale il sistema operativo passa alla build 28000.2525. La KB include le principali modifiche di luglio relative a OLE Automation, Secure Boot, hotkey, TDI e Remote Desktop, oltre ai miglioramenti già distribuiti con la preview KB5095091.

Su questa versione viene introdotta anche una modifica specifica alla gestione dei sistemi AT Time e ATSvc: at.exe e schedcli.dll non possono più essere utilizzati per amministrare questi servizi legacy. Microsoft raccomanda di sostituirli con schtasks.exe, con i cmdlet PowerShell del modulo ScheduledTasks o con l’interfaccia ITaskSchedulerService, anticipando inoltre la futura rimozione di AT.exe e ATServer.

Windows 11 26H1 rimane comunque una versione destinata esclusivamente a nuovi dispositivi basati su specifiche piattaforme hardware introdotte nel 2026. Non viene offerta tramite Windows Update ai PC che eseguono versioni precedenti e non può essere installata come aggiornamento in-place sui normali dispositivi Windows 11 24H2 o 25H2.

Per la maggior parte delle organizzazioni, quindi, KB5101649 interessa soltanto un numero limitato di nuovi modelli e non modifica la baseline generale di aggiornamento, che rimane incentrata su KB5101650. Microsoft non segnala problemi noti aperti per la KB di Windows 11 26H1.

Scadenze di supporto da monitorare

Le scadenze più vicine riguardano Windows 11 24H2 Home e Pro, che terminerà il supporto il 13 ottobre 2026, e Windows 11 23H2 Enterprise ed Education, il cui supporto terminerà il 10 novembre 2026. Le edizioni Enterprise ed Education di Windows 11 24H2 resteranno invece supportate fino al 12 ottobre 2027.

Per gli ambienti aziendali, queste date devono essere lette insieme all’edizione effettivamente installata. Due dispositivi con la stessa versione possono avere scadenze differenti se uno utilizza Windows 11 Pro e l’altro Windows 11 Enterprise, quindi l’inventario deve includere entrambe le informazioni.

Distribuzione tramite Intune, Autopatch, WSUS e Configuration Manager

KB5101650 viene scaricata e installata automaticamente tramite Windows Update e Windows Update for Business, nel rispetto delle policy configurate. Il pacchetto è disponibile anche nel Microsoft Update Catalog e viene sincronizzato con Windows Server Update Services (WSUS) come aggiornamento di sicurezza per il prodotto Windows 11.

Negli ambienti gestiti con Microsoft Intune, gli update ring continuano a controllare il comportamento del client, compresi differimenti, scadenze, riavvii e notifiche. Le policy per i quality update possono invece essere utilizzate quando serve un’orchestrazione cloud più avanzata, un deployment gestito attraverso Windows Autopatch, un’expedite policy o l’abilitazione di Hotpatch sui dispositivi idonei.

Il modello di distribuzione dovrebbe rimanere progressivo e prevedere anelli sufficientemente distinti da permettere l’osservazione degli effetti prima del passaggio alla fase successiva.

Il gruppo pilota di luglio dovrebbe comprendere intenzionalmente dispositivi con applicazioni che automatizzano Microsoft Office, vecchi client VPN o agent di rete, file RDP firmati, stampanti che dipendono da driver avanzati e modelli hardware sui quali è ancora in corso la distribuzione dei certificati Secure Boot. Per i processi di imaging è necessario aggiungere anche una validazione separata delle immagini WinPE e delle task sequence.

Prima di aggiornare tutti i domain controller è necessario controllare gli eventi KDCsvc dal 201 al 209, verificare gli account di servizio privi di chiavi AES e testare le implementazioni Kerberos non Windows, in particolare quelle che utilizzano keytab contenenti soltanto chiavi RC4. Questo controllo appartiene al piano di aggiornamento dei server, ma deve essere coordinato con il rollout client perché gli errori di autenticazione potrebbero essere inizialmente interpretati come un problema di KB5101650.

Per il monitoraggio tramite Intune è disponibile il percorso Reports > Windows Updates > Reports > Windows Update Distribution Report, che consente di analizzare la distribuzione delle versioni e lo stato dei dispositivi. Negli ambienti Windows Autopatch, il report Quality update status è disponibile in Reports > Windows Autopatch > Windows quality updates > Reports.

Verifiche dopo l’installazione

Il primo controllo consiste nella verifica della build attraverso il comando winver. Dopo l’installazione degli aggiornamenti di luglio, i valori previsti sono:

La stessa informazione può essere recuperata tramite PowerShell:

Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber

Per verificare la presenza della KB applicabile al dispositivo è possibile utilizzare:

Get-HotFix -Id KB5101650,KB5099414,KB5101649,KB5099539 -ErrorAction SilentlyContinue | Select-Object HotFixID, InstalledOn

La verifica della build rimane generalmente il riferimento più affidabile, perché la visualizzazione delle KB nei sistemi di inventario o nei report cloud può risentire dei normali tempi di raccolta ed elaborazione dei dati.

Sui dispositivi che utilizzano componenti di rete legacy è necessario controllare anche gli eventi TDI:

Get-WinEvent -FilterHashtable @{
      LogName = 'System'
      Id      = 16003
  } -ErrorAction SilentlyContinue |
  Sort-Object TimeCreated -Descending |
Select-Object -First 20 TimeCreated, ProviderName, Message

L’assenza dell’evento subito dopo il riavvio non conclude la verifica. È necessario avviare l’applicazione potenzialmente interessata e riprodurre il flusso che utilizza la rete, perché il provider potrebbe essere caricato soltanto in quel momento.

Negli ambienti che utilizzano OLE Automation, la validazione deve partire dall’applicazione gestionale o documentale e comprendere apertura, modifica, salvataggio e chiusura del documento Office. Per Remote Desktop devono essere provati i file .rdp realmente distribuiti, mentre sulle postazioni che utilizzano script basati su curl può essere utile verificare sia la versione installata sia il corretto completamento delle automazioni.

All’interno di Microsoft Intune, il controllo deve comprendere la distribuzione delle build, i dispositivi che risultano in attesa di riavvio, gli errori di aggiornamento e le macchine che non hanno ancora ricevuto la policy. I risultati tecnici devono infine essere confrontati con le segnalazioni del service desk, perché alcuni problemi applicativi non vengono rappresentati direttamente nei report Windows Update.

Conclusioni

L’aggiornamento cumulativo di luglio 2026 risolve il problema che impediva ad alcune applicazioni basate su OLE Automation di avviare Microsoft Office e corregge l’anomalia di DISM che poteva bloccare la riparazione del component store su alcuni dispositivi Windows 11 24H2. Allo stesso tempo, continua la distribuzione dei nuovi certificati Secure Boot e prepara le configurazioni Remote Desktop alla futura eliminazione dei thumbprint SHA-1.

L’aspetto che richiede maggiore attenzione durante il pilot rimane l’hardening dei trasporti TDI. La modifica interessa una tecnologia legacy e non dovrebbe produrre effetti nella maggior parte degli ambienti moderni, ma può interrompere applicazioni o driver che utilizzano provider non registrati; per questo motivo la ricerca dell’evento AFD 16003 e la validazione dei componenti di rete meno recenti devono far parte dei controlli di luglio.

Al momento della pubblicazione Microsoft non segnala problemi noti aperti per KB5101650, KB5099414, KB5101649 e KB5099539. La distribuzione può quindi procedere senza un blocco preventivo generalizzato, mantenendo però un modello basato su anelli, monitoraggio dei risultati e verifica delle pagine Windows release health prima del broad deployment.

Il Patch Tuesday deve infine essere coordinato con due attività che vanno oltre la singola KB client: il completamento del rinnovo dei certificati Secure Boot e la fase finale dell’hardening Kerberos RC4 sui domain controller. Trascurare questi elementi potrebbe generare problemi di sicurezza o autenticazione che non sarebbero direttamente attribuibili alla cumulative update di Windows 11, ma che emergerebbero nello stesso periodo operativo.