L’essentiel à retenir

Microsoft a identifié une dégradation affectant Windows Server Update Services.

Les symptômes observés comprenaient :

  • synchronisation très lente ;
  • opération qui ne se termine pas ;
  • timeout ;
  • charge élevée du pool IIS ;
  • clients effectuant trop d’allers-retours vers WSUS ;
  • erreurs HTTP ou Windows Update.

L’impact a augmenté à partir du :

13 juillet 2026

Microsoft a appliqué une mitigation côté service le :

18 juillet 2026

L’incident a été déclaré résolu le :

20 juillet 2026

La cause documentée est une accumulation de métadonnées de publication présente :

  • sur le service Microsoft ;
  • dans les catalogues des serveurs WSUS existants.

Pour les serveurs encore affectés, Microsoft recommande :

  1. sauvegarder chaque base SUSDB ;
  2. exécuter la requête de nettoyage officielle KB5121986 ;
  3. laisser les clients effectuer un premier rattrapage ;
  4. remettre MaxXMLPerRequest à sa valeur par défaut ;
  5. réindexer la base ;
  6. exécuter l’assistant de nettoyage WSUS ;
  7. recycler le pool IIS ou redémarrer IIS.

Quels systèmes ont été concernés ?

Microsoft a listé les plateformes suivantes parmi les environnements servis par WSUS :

Clients

  • Windows 11 26H1 ;
  • Windows 11 25H2 ;
  • Windows 11 24H2 ;
  • Windows 11 23H2 ;
  • Windows 10 22H2 ;
  • Windows 10 21H2 ;
  • Windows 10 1809 ;
  • Windows 10 Enterprise LTSC 2019 ;
  • Windows 10 Enterprise LTSC 2016 ;
  • Windows 10 1607.

Serveurs

  • Windows Server 2025 ;
  • Windows Server 2022 ;
  • Windows Server 1809 ;
  • Windows Server 2019 ;
  • Windows Server 2016 ;
  • Windows Server 2012 R2 ;
  • Windows Server 2012.

Cette liste décrit les plateformes pouvant recevoir leurs mises à jour par l’intermédiaire de WSUS. Le problème principal se situe dans la synchronisation et le catalogue WSUS.

Pourquoi ne faut-il pas réinstaller WSUS immédiatement ?

Un timeout peut être provoqué par :

  • l’incident Microsoft de juillet 2026 ;
  • une base surchargée ;
  • un pool IIS saturé ;
  • un problème de TLS ;
  • un proxy ;
  • un espace disque insuffisant ;
  • une base WID ou SQL en erreur ;
  • une configuration de produits trop large ;
  • une maintenance jamais réalisée ;
  • un antivirus inspectant les mauvais répertoires ;
  • un certificat ou une chaîne de confiance.

Une réinstallation complète :

  • ne corrige pas nécessairement la cause locale ;
  • peut faire perdre les groupes, approbations et historiques ;
  • oblige les clients à reconstruire leur relation avec le serveur ;
  • consomme du temps ;
  • peut masquer une base SQL ou une configuration IIS dégradée.

Depuis la mitigation du 18 juillet, Microsoft indique qu’une nouvelle installation ou une reconstruction ne devrait plus rencontrer le problème précis de métadonnées côté service. Cela ne signifie pas qu’il faut reconstruire un serveur existant sans diagnostic.

Les erreurs caractéristiques

Microsoft associe notamment les erreurs suivantes aux symptômes :

CodeSignification générale
0x80244010nombre maximal d’allers-retours WSUS dépassé
0x8024400Eerreur SOAP côté serveur ou client
0x80244007faute SOAP pendant l’échange
0x80244022service indisponible, souvent associé à HTTP 503
0x80240439format ou volume de données anormal
0x80072EE2délai d’attente réseau dépassé
HTTP 503pool IIS indisponible ou surchargé

Le code le plus caractéristique de l’incident est :

0x80244010

Il indique que l’analyse du client a nécessité trop d’échanges avec WSUS.

Étape 1 : vérifier le statut officiel de l’incident

Avant de modifier le serveur, consultez :

  • Windows Release Health ;
  • Microsoft 365 Admin Center si l’entreprise y a accès ;
  • KB5121986 ;
  • les éventuelles mises à jour de Microsoft.

Au 21 juillet 2026, l’incident est marqué résolu.

Un serveur qui continue à rencontrer les symptômes peut toutefois conserver les métadonnées incorrectes dans sa propre base.

Étape 2 : documenter l’état avant intervention

Relevez :

  • version de Windows Server ;
  • version et rôle WSUS ;
  • base WID ou SQL Server ;
  • serveur autonome, amont ou réplique ;
  • date de dernière synchronisation réussie ;
  • nombre de mises à jour ;
  • nombre de clients ;
  • espace disque ;
  • état d’IIS ;
  • état de la base ;
  • proxy ;
  • intégration Configuration Manager éventuelle.

Informations système

Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Rôle WSUS

Get-WindowsFeature -Name UpdateServices*

Services

Get-Service WsusService, W3SVC |
    Select-Object Name, Status, StartType

Espace disque

Get-Volume |
    Select-Object DriveLetter, FileSystemLabel, Size, SizeRemaining

Pool IIS

Chargez le module :

Import-Module WebAdministration

Puis :

Get-WebAppPoolState -Name WsusPool

Étape 3 : consulter l’historique de synchronisation

Dans la console WSUS :

Synchronisations → Historique des synchronisations

Relevez :

  • heure de début ;
  • durée ;
  • résultat ;
  • message d’erreur ;
  • nombre de révisions reçues ;
  • répétition du problème.

Une synchronisation lente apparue précisément autour du 13 juillet 2026 renforce l’hypothèse de l’incident Microsoft.

Un problème plus ancien peut avoir une autre cause.

Étape 4 : examiner SoftwareDistribution.log

Le journal principal se trouve généralement dans :

%ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log

Ouvrez les dernières lignes :

Get-Content \
  "$env:ProgramFiles\Update Services\LogFiles\SoftwareDistribution.log" \
  -Tail 300

Recherchez :

Select-String \
  -Path "$env:ProgramFiles\Update Services\LogFiles\SoftwareDistribution.log" \
  -Pattern 'timeout|0x80244010|0x80244022|503|Soap|WebException|TLS' \
  -CaseSensitive:$false

Distinguez :

  • timeout pendant une synchronisation amont ;
  • problème de connexion TLS ;
  • pool IIS arrêté ;
  • erreur de base ;
  • import manuel ;
  • erreur de client.

Étape 5 : vérifier le point de terminaison Microsoft

WSUS doit normalement synchroniser avec :

https://sws.update.microsoft.com

Vérifiez la configuration avec PowerShell administrateur :

$server = Get-WsusServer
$config = $server.GetConfiguration()
$config.MUUrl

Un ancien point de terminaison peut provoquer des erreurs différentes.

Testez la résolution DNS :

Resolve-DnsName sws.update.microsoft.com

Testez le port 443 :

Test-NetConnection \
  sws.update.microsoft.com \
  -Port 443

Ce test confirme uniquement la résolution et la connexion TCP. Il ne valide pas l’ensemble de la négociation TLS, du proxy et de l’échange applicatif.

Étape 6 : vérifier le proxy

Affichez la configuration WinHTTP :

netsh winhttp show proxy

Vérifiez également la configuration WSUS dans la console.

Recherchez :

  • authentification expirée ;
  • inspection TLS ;
  • certificat d’autorité manquant ;
  • restriction de domaine ;
  • timeout proxy ;
  • changement de politique ;
  • règle bloquant sws.update.microsoft.com.

N’excluez pas le proxy uniquement parce que la navigation web fonctionne depuis le serveur.

Étape 7 : vérifier TLS

Le point de terminaison moderne WSUS utilise TLS 1.2.

Sur d’anciens serveurs, un manque de correctifs ou une politique de chiffrement trop restrictive peut empêcher la synchronisation.

Recherchez dans SoftwareDistribution.log les lignes relatives à :

SCHANNEL Protocol

Contrôlez les événements Schannel :

Get-WinEvent \
  -FilterHashtable @{
      LogName      = 'System'
      ProviderName = 'Schannel'
  } \
  -MaxEvents 100 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Pour un serveur utilisant une GPO de suites cryptographiques :

gpresult /scope computer /h C:\Temp\GPReport.html

Examinez :

SSL Cipher Suite Order

Étape 8 : vérifier IIS et WsusPool

Un HTTP 503 peut indiquer que WsusPool est arrêté ou recycle en boucle.

État

Import-Module WebAdministration
Get-WebAppPoolState -Name WsusPool

Démarrer le pool

Start-WebAppPool -Name WsusPool

Examiner les événements IIS

Consultez :

Observateur d’événements → Journaux Windows → Application

Recherchez notamment les sources :

  • WAS ;
  • IIS-W3SVC-WP ;
  • ASP.NET ;
  • .NET Runtime ;
  • MSSQL ou Windows Internal Database.

Charge du processus

Get-Process w3wp -ErrorAction SilentlyContinue |
    Select-Object Id, CPU, WorkingSet, StartTime

Le processus w3wp.exe peut héberger plusieurs pools. Corrélez le PID avec IIS avant de conclure.

Étape 9 : identifier WID ou SQL Server

WSUS peut utiliser :

  • Windows Internal Database ;
  • SQL Server local ;
  • SQL Server distant.

Vérifiez la configuration dans le Registre et l’installation.

Un serveur WID utilise souvent une instance accessible via un canal nommé de type :

\\.\pipe\MICROSOFT##WID\tsql\query

La valeur exacte dépend de la version de Windows Server.

N’exécutez aucune requête tant que vous n’avez pas identifié :

  • la bonne instance ;
  • la bonne base SUSDB ;
  • les répliques ;
  • la méthode de sauvegarde ;
  • les droits utilisés.

Étape 10 : sauvegarder SUSDB

Microsoft exige une sauvegarde avant le nettoyage.

La suppression de métadonnées est définitive.

Avec SQL Server Management Studio

Connectez-vous à l’instance contenant SUSDB puis réalisez une sauvegarde complète.

Exemple de commande SQL à adapter :

BACKUP DATABASE SUSDB
TO DISK = N'C:\Backup\SUSDB_PreDetectoidCleanup.bak'
WITH INIT, STATS = 5;

Vérifiez ensuite :

  • existence du fichier ;
  • taille cohérente ;
  • journal de sauvegarde ;
  • espace libre ;
  • copie sur un autre support ;
  • procédure de restauration.

Étape 11 : utiliser la requête officielle KB5121986

Microsoft fournit dans KB5121986 une requête destinée à :

  • supprimer les detectoids mal publiés ;
  • temporairement mettre MaxXMLPerRequest à 0 ;
  • éviter la limite de 5 Mo pendant le rattrapage ;
  • réduire le nombre d’allers-retours nécessaires aux clients.

La requête doit être exécutée :

  • avec SQL Server Management Studio ;
  • sur chaque base SUSDB ;
  • y compris chaque serveur réplique ;
  • après sauvegarde ;
  • pendant une fenêtre de maintenance ;
  • en suivant la version actuelle de KB5121986.

Les suppressions ne se propagent pas automatiquement entre les serveurs WSUS.

Étape 12 : surveiller le nettoyage

Pendant l’opération :

  • surveillez le CPU ;
  • surveillez l’espace disque ;
  • contrôlez les verrous SQL ;
  • conservez les sorties de la requête ;
  • notez le nombre d’éléments supprimés ou ignorés ;
  • ne fermez pas SSMS sans savoir si la transaction est terminée.

Microsoft indique que certains éléments peuvent être ignorés parce qu’ils restent référencés.

Cette situation doit être interprétée avec le journal de la requête, pas comme un échec automatique.

Étape 13 : permettre le rattrapage des clients

Le premier scan après nettoyage peut être plus long.

C’est attendu : le client doit reconstruire une partie de son évaluation avec un catalogue assaini.

Microsoft indique que la récupération des clients est automatique.

Ne réinitialisez pas immédiatement tous les composants Windows Update des postes.

Commencez avec un groupe pilote de clients :

  • un Windows 10 ;
  • un Windows 11 ;
  • un serveur ;
  • un poste distant ;
  • un client utilisant le plus grand nombre de produits WSUS.

Étape 14 : générer WindowsUpdate.log sur un client

Sur un client PowerShell administrateur :

Get-WindowsUpdateLog

Le fichier généré peut être enregistré sur le Bureau.

Microsoft recommande d’observer une ligne de type :

evaluated appl. rules of X out of N deployed entities

Après nettoyage, la valeur N doit être beaucoup plus faible lors du prochain scan.

Ne recherchez pas uniquement les identifiants des detectoids : Microsoft précise qu’ils ne sont pas nécessairement visibles de cette manière dans le journal client.

Étape 15 : remettre MaxXMLPerRequest à sa valeur par défaut

Lorsque :

  • WSUS est stabilisé ;
  • les clients pilotes analysent correctement ;
  • la charge revient à la normale ;
  • les timeouts ont disparu ;

remettez la valeur par défaut :

UPDATE tbConfigurationC
SET MaxXMLPerRequest = 5242880;

La valeur correspond à 5 Mo.

Conservez la preuve du changement et l’heure d’exécution.

Étape 16 : réindexer SUSDB

Une suppression importante fragmente les index.

Après le nettoyage :

  • exécutez la procédure de réindexation WSUS recommandée par Microsoft ;
  • mettez à jour les statistiques ;
  • contrôlez la durée et les erreurs ;
  • surveillez l’espace libre de la base et du journal.

N’utilisez pas un script de maintenance ancien sans vérifier sa compatibilité avec la version de SQL ou WID.

Étape 17 : exécuter l’assistant de nettoyage WSUS

Dans la console :

Options → Assistant Nettoyage du serveur

Traitez progressivement :

  • mises à jour et révisions inutiles ;
  • ordinateurs obsolètes ;
  • fichiers inutiles ;
  • mises à jour expirées ;
  • mises à jour remplacées.

Sur un serveur jamais entretenu, évitez de tout sélectionner en une seule opération si le volume est très important.

Procédez par étapes et surveillez :

  • IIS ;
  • base ;
  • CPU ;
  • mémoire ;
  • durée ;
  • erreurs.

Étape 18 : recycler WsusPool ou IIS

Après la maintenance, videz l’état en cache.

Recycler uniquement le pool est moins perturbant qu’un redémarrage complet d’IIS :

Restart-WebAppPool -Name WsusPool

Si nécessaire et pendant une fenêtre adaptée :

iisreset

Vérifiez ensuite :

Get-WebAppPoolState -Name WsusPool
Get-Service WsusService, W3SVC

Étape 19 : relancer une synchronisation

Depuis la console WSUS, lancez une synchronisation manuelle.

Surveillez :

  • heure de départ ;
  • progression ;
  • durée ;
  • nombre de nouvelles mises à jour ;
  • erreurs ;
  • charge IIS ;
  • croissance de SUSDB ;
  • espace du contenu.

La première opération peut rester plus longue qu’une synchronisation habituelle.

Étape 20 : contrôler les mises à jour de juillet 2026

Vérifiez que les correctifs attendus sont présents pour les produits réellement sélectionnés.

Contrôlez :

  • Windows 10 ;
  • Windows 11 ;
  • Windows Server ;
  • Microsoft Defender ;
  • Office ou autres produits gérés ;
  • architectures x64 et ARM64 si utilisées ;
  • classifications « Mises à jour de sécurité » et « Mises à jour critiques ».

Ne sélectionnez pas tous les produits et toutes les langues « au cas où ».

Chaque choix augmente :

  • le catalogue ;
  • le temps de synchronisation ;
  • la base ;
  • la charge des clients ;
  • la maintenance.

Le fichier DataStore.edb ne diminue pas

Microsoft précise que le fichier client :

DataStore.edb

ne rétrécit pas automatiquement après la suppression des detectoids.

Ce comportement est attendu et ne signifie pas que le nettoyage a échoué.

Évitez de supprimer systématiquement la base Windows Update de tous les clients uniquement pour récupérer de l’espace.

Limiter temporairement les connexions IIS

Dans certains environnements très chargés, Microsoft indique qu’il peut être utile de limiter temporairement les connexions simultanées du site WSUS Administration, puis de les augmenter progressivement.

L’objectif est de maintenir la charge IIS autour d’un niveau contrôlable pendant le rattrapage.

Cette action doit être :

  • testée ;
  • suivie ;
  • documentée ;
  • adaptée au nombre de clients ;
  • retirée ou ajustée après stabilisation.

Une limite trop basse peut rallonger inutilement le rattrapage.

Quand le problème n’est probablement pas KB5121986

Recherchez une autre cause si :

  • le problème existait bien avant juillet 2026 ;
  • la connexion à sws.update.microsoft.com échoue ;
  • TLS 1.2 ne fonctionne pas ;
  • SUSDB est hors ligne ;
  • le disque est plein ;
  • WsusPool s’arrête immédiatement ;
  • SQL signale une corruption ;
  • le proxy refuse la connexion ;
  • les certificats ne sont pas approuvés ;
  • seuls quelques clients sont touchés ;
  • l’erreur concerne une importation manuelle spécifique ;
  • Configuration Manager présente ses propres erreurs de synchronisation.

Que faire si un seul client ne scanne plus ?

Vérifiez d’abord :

  • stratégie WSUS ;
  • URL configurée ;
  • résolution DNS ;
  • certificat si SSL ;
  • heure du système ;
  • service Windows Update ;
  • proxy ;
  • erreurs dans WindowsUpdate.log ;
  • appartenance au bon groupe.

Affichez les stratégies appliquées :

gpresult /scope computer /h C:\Temp\GPReport.html

Vérifiez les valeurs de stratégie Windows Update dans le Registre, sans les modifier à l’aveugle.

Un incident global WSUS touche généralement de nombreux clients, pas un seul poste isolé.

Les erreurs à éviter

Réinstaller WSUS avant de sauvegarder SUSDB

Vous perdez les informations nécessaires au diagnostic et au retour arrière.

Exécuter la requête sur un seul serveur

Les répliques conservent leurs propres métadonnées.

Laisser MaxXMLPerRequest à zéro indéfiniment

Microsoft demande de revenir à la valeur par défaut après stabilisation.

Oublier la réindexation

Une suppression massive fragmente les index.

Réinitialiser tous les clients

Le rattrapage est normalement automatique.

Ignorer les produits inutiles

Un catalogue trop large augmente durablement la charge.

Appliquer un script SQL copié d’un forum

Utilisez la version officielle de KB5121986.

Confondre résolution Microsoft et serveur local nettoyé

L’incident est résolu côté service, mais les anciennes métadonnées peuvent rester dans SUSDB.

Checklist avant nettoyage

  • ☐ Le statut Microsoft a été vérifié.
  • ☐ Les symptômes correspondent à l’incident.
  • ☐ La topologie WSUS est documentée.
  • ☐ Tous les serveurs et répliques sont listés.
  • ☐ WID ou SQL Server a été identifié.
  • ☐ L’espace disque est suffisant.
  • ☐ Les services WSUS et IIS ont été contrôlés.
  • ☐ Le journal SoftwareDistribution.log a été sauvegardé.
  • ☐ Chaque SUSDB a été sauvegardée.
  • ☐ La restauration de la sauvegarde est comprise.
  • ☐ La requête provient de KB5121986.
  • ☐ Une fenêtre de maintenance est validée.

Checklist après nettoyage

  • ☐ La requête a été exécutée sur chaque SUSDB.
  • ☐ Les sorties SQL sont conservées.
  • ☐ Les clients pilotes ont analysé correctement.
  • ☐ Les erreurs 0x80244010 diminuent.
  • ☐ Le nombre d’entités évaluées a baissé.
  • ☐ MaxXMLPerRequest est revenu à 5242880.
  • ☐ SUSDB a été réindexée.
  • ☐ L’assistant de nettoyage a été exécuté.
  • ☐ WsusPool a été recyclé.
  • ☐ Une synchronisation complète a réussi.
  • ☐ Les correctifs de juillet sont présents.
  • ☐ Les postes hors conformité sont identifiés.
  • ☐ La supervision WSUS a été rétablie.

Conclusion

L’incident WSUS de juillet 2026 a eu une particularité : une partie du problème venait du service Microsoft et une autre partie restait stockée dans les catalogues WSUS existants.

La bonne réponse n’est donc ni :

  • attendre indéfiniment ;
  • réinstaller immédiatement ;
  • réinitialiser tous les clients.

La procédure correcte consiste à :

  1. confirmer les symptômes ;
  2. vérifier le statut Microsoft ;
  3. diagnostiquer réseau, TLS, IIS et base ;
  4. sauvegarder chaque SUSDB ;
  5. exécuter le nettoyage officiel ;
  6. laisser les clients se rattraper ;
  7. remettre la limite XML par défaut ;
  8. réindexer et nettoyer WSUS ;
  9. vérifier la distribution des correctifs.

Une fois le service rétabli, profitez de l’intervention pour réduire les produits, langues et classifications inutiles et mettre en place une maintenance régulière de SUSDB.

Besoin de remettre WSUS en état ?

AGE-Info accompagne les entreprises dans la maintenance de leurs infrastructures Windows.

Nous pouvons notamment :

  • diagnostiquer la synchronisation ;
  • vérifier IIS et SUSDB ;
  • sauvegarder la base ;
  • appliquer la procédure Microsoft ;
  • contrôler les clients ;
  • suivre les correctifs manquants ;
  • optimiser les produits et classifications ;
  • documenter la maintenance WSUS.