WSUS en panne de synchronisation : le correctif manuel proposé par Microsoft

Depuis quelques jours, il y a des problèmes de synchronisation sur les serveurs WSUS, ce qui provoque des lenteurs et même des échecs lors de la synchronisation avec les serveurs de Microsoft. Bien que le problème soit désormais résolu, il y a des étapes supplémentaires que vous pouvez accomplir pour nettoyer votre serveur. Voici ce que propose Microsoft.

Pour rappel, WSUS (Windows Server Update Services) est le rôle de Windows Server qui centralise la distribution des mises à jour Microsoft sur les postes et les serveurs d'une entreprise. Si vous débutez avec cet outil, IT-Connect propose un cours complet pour installer et configurer un serveur WSUS. C'est un service que Microsoft ne fait pourtant plus évoluer depuis l'annonce de l'arrêt de son développement à partir de Windows Server 2025, mais qui reste massivement déployé en entreprise.

Depuis le vendredi 17 juillet 2026, des administrateurs constatent que leurs serveurs WSUS mettent un temps anormalement long à se synchroniser. Au-delà d'être longue, la synchronisation peut aller jusqu'à échouer. Ce qui est gênant, c'est que sans cette synchronisation, il n'est pas possible de récupérer les métadonnées associées aux dernières mises à jour Windows via WSUS (ou Configuration Manager).

Dans un premier temps, Microsoft a confirmé le problème avant de déployer une première parade au niveau de son Cloud. "Le 18 juillet 2026, Microsoft a déployé une mesure corrective côté serveur qui rétablit les délais de synchronisation et le fonctionnement normal des opérations de synchronisation pour les nouvelles installations et les réinstallations de WSUS. Après cette date, les serveurs WSUS nouvellement installés ou réinstallés ne devraient plus rencontrer ce problème.", peut-on lire sur le site Microsoft.

Puis, le 20 juillet 2026, une procédure de nettoyage à destination des serveurs encore affectés a été mise en ligne par Microsoft. Regardons ce qu'il en est dans la suite de cet article.

Une accumulation de détectoïdes de test à l'origine des blocages

Selon Microsoft, et pour reprendre les termes exacts, cet incident est lié à une dégradation de service liée à l'accumulation de détectoïdes de test publiés par erreur sur le canal WSUS. Derrière ce nom se cache des objets avec un intitulé du type Product Detectoid for ProductName TestProduct%. Sauf qu'à force de s'accumuler, ils surchargent la base de métadonnées que WSUS doit traiter, au point de faire exploser les temps de synchronisation et de provoquer des échecs.

Dans son document de support, Microsoft explique aussi qu'il y a des répercussions au niveau des postes de travail, en particulier dans Windows Update. Plusieurs messages et codes d'erreurs sont évoqués, et vous les avez peut-être déjà rencontrés si vous avez eu quelques péripéties avec votre WSUS.

Vous pouvez par exemple rencontrer l'erreur 0x80244010 (WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS), qui signale que l'analyse Windows Update a dépassé le nombre maximal d'allers-retours autorisés avec le serveur WSUS. D'autres codes peuvent apparaître, comme 0x80244022 (ou une erreur HTTP 503) lorsque le pool d'applications WsusPool est saturé, ou encore 0x80072EE2 en cas de problème de connexion réseau.

La procédure de nettoyage manuel signée Microsoft

Pour les serveurs encore concernés par ces problèmes de synchronisation, Microsoft recommande de suivre les instructions définies dans sa procédure de remédiation (KB5121986). Elle a été publiée le 20 juillet 2026, dans la continuité de cet incident et s'applique à toutes les versions de Windows Server.

Quand on regarde de plus près ce que propose Microsoft, on comprend rapidement qu'on s'attaque à la base de données WSUS. Surtout, ce qui est proposé comme nettoyage va supprimer définitivement des métadonnées de mise à jour. Voici les grandes étapes à accomplir :

• Sauvegarder chaque base SUSDB avant toute intervention, la suppression étant permanente.
• Exécuter la requête de nettoyage depuis SQL Server Management Studio, sur toutes les bases SUSDB, y compris celles des serveurs réplicas. Les suppressions ne se propagent pas d'un serveur à l'autre : chaque catalogue doit donc être nettoyé individuellement, faute de quoi les clients rattachés à un serveur non traité continueront de voir les détectoïdes de test.
• Laisser la requête supprimer les détectoïdes incorrects et fixer la valeur MaxXMLPerRequest à 0. Cette bascule lève temporairement la limite de 5 Mo et aide les clients à pouvoir se resynchroniser correctement.
• Une fois WSUS stabilisé et les clients synchronisés avec succès, rétablir MaxXMLPerRequest à sa valeur par défaut, soit 5242880.

"Il peut s'avérer nécessaire de limiter le nombre maximal de connexions simultanées pour le site d'administration WSUS dans IIS, puis de l'augmenter progressivement afin de permettre aux clients de mener à bien l'analyse. L'objectif est de maintenir l'utilisation du processeur par IIS à environ 80 %.", précise Microsoft.

Une fois le nettoyage terminé, l'éditeur conseille de réindexer la base SUSDB, de lancer l'Assistant de nettoyage du serveur WSUS, puis d'exécuter IISReset ou de recycler le pool d'applications WsusPool afin de vider le cache du catalogue. Vous avez donc du travail côté serveur WSUS, tandis que ça devrait suivre naturellement côté postes de travail (sinon regardez le fichier WindowsUpdate.log).

Vos serveurs WSUS ont-ils été touchés par ces lenteurs de synchronisation ?

Ajouter IT-Connect à mes
sources préférées

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.