WSUS in timeout: la procedura Microsoft per sbloccare gli update Windows

I problemi di sincronizzazione WSUS (Windows Server Update Services) segnalati a luglio 2026 hanno avuto un effetto immediato sulla gestione degli aggiornamenti Windows: scansioni lente, timeout, errori IIS e distribuzioni dei pacchetti software bloccate su intere flotte aziendali. Microsoft ha ricondotto il malfunzionamento a un accumulo anomalo di metadati nel catalogo di WSUS: la mitigazione lato servizio ha fermato la propagazione del difetto, ma non ha ripulito i server già coinvolti.

Per gli amministratori IT il problema non si è limitato a una semplice sincronizzazione più lunga. I server WSUS e i Software Update Point collegati a Configuration Manager hanno iniziato a gestire un volume eccessivo di metadati, con richieste XML più pesanti, maggiore pressione su IIS e un numero anomalo di scambi tra client e server. Gli errori 0x80244010, 0x80072EE2 e HTTP 503 sono diventati i segnali più evidenti di aggiornamenti difficoltosi da elaborare.

La procedura pubblicata da Microsoft nella KB5121986 interviene direttamente sulla SUSDB: elimina le voci difettose, modifica temporaneamente il limite MaxXMLPerRequest, richiede la reindicizzazione del database e impone un controllo attento del carico su WsusPool. In pratica, non si tratta di applicare una patch e riavviare il servizio; serve una manutenzione coordinata di database, IIS, repliche WSUS e client già esposti al catalogo anomalo.

Cos’è WSUS e come funziona in breve

WSUS nasce nei primi anni 2000 come strumento centralizzato per distribuire patch e aggiornamenti nelle reti aziendali senza obbligare ogni dispositivo a collegarsi direttamente ai server Microsoft.

Il modello resta molto diffuso: un server locale sincronizza il catalogo di Windows Update, conserva metadati e contenuti approvati, quindi risponde alle richieste dei client.

Proprio questa architettura spiega la gravità del guasto lamentato in questi giorni da una vasta schiera di utenti aziendali: quando il catalogo diventa troppo grande o contiene elementi anomali, la scansione non rallenta soltanto sul server; aumenta anche il numero di richieste che ogni endpoint deve completare prima di stabilire quali aggiornamenti siano applicabili.

La platea interessata è ampia: comprende sistemi da Windows 10 versione 1607 fino a Windows 11 26H1, oltre a Windows Server 2012, 2012 R2, 2016, 2019, 2022 e 2025.

La procedura Microsoft parte dal backup del database

La correzione manuale presentata da Microsoft richiede accesso amministrativo a SQL Server Management Studio e va eseguita su ogni database SUSDB coinvolto.

Prima di intervenire, i tecnici di Redmond raccomandano un backup completo: la query elimina definitivamente i metadati dal catalogo, quindi l’unico modo affidabile per annullare l’operazione consiste nel ripristinare il database.

L’istanza SUSDB può risiedere in SQL Server oppure nel Windows Internal Database, a seconda di come WSUS è stato installato. L’amministratore deve quindi verificare la configurazione usata, lo spazio disponibile per il file di backup e la possibilità di ripristino.

La query pubblicata da Microsoft (paragrafo Run the cleanup query) non elimina indiscriminatamente tutti i metadati presenti nella SUSDB. Per prima cosa individua le revisioni più recenti degli oggetti coinvolti, così da evitare di intervenire su versioni precedenti o già superate dello stesso elemento. Poi controlla il titolo localizzato di ogni voce e applica un filtro preciso: seleziona soltanto i record il cui nome comincia con “Product Detectoid for ProductName TestProduct“, cioè lo schema associato ai metadati di test che hanno provocato la crescita anomala del catalogo WSUS.

Per ogni elemento individuato, lo script passa il relativo UpdateID alla stored procedure spDeleteUpdateByUpdateID. Non esegue quindi una semplice cancellazione diretta dalle tabelle: usa una routine interna di WSUS che gestisce la rimozione delle revisioni e delle relazioni collegate, limitando il rischio di lasciare record incoerenti nella SUSDB.

Aggiornamento del parametro MaxXMLPerRequest

All’inizio della pulizia, la procedura imposta MaxXMLPerRequest a 0: il valore rimuove temporaneamente il limite di 5 MB applicato alle richieste XML. La scelta può sembrare controintuitiva, ma serve a ridurre i fallimenti dei client che, durante la fase di recupero, devono ancora elaborare risposte molto grandi e rischiano di superare il numero massimo di “dialoghi” con WSUS.

Una volta stabilizzato il server e completate con successo le scansioni, Microsoft chiede di riportare il parametro al valore predefinito di 5.242.880 byte. Lasciarlo senza limite più del necessario non offre un vantaggio operativo duraturo e può esporre IIS a richieste più pesanti.

La query da utilizzare è sempre riportate nella pagina di supporto al paragrafo Update MaxXMLPerRequest.