Breaking News
Home >> Non classé >> Windows Update : Erreur 80072EFD
Erreur 80072EFD

Windows Update : Erreur 80072EFD

Cet article concerne un problème que je viens de rencontrer chez un client, sur des serveurs virtuels (VM Hyper-V) en Windows Server 2008 R2. Impossible de faire fonctionner Windows Update. Erreur 80072EFD. Si vous êtes concernés par cette erreur, vous trouverez la solution dans cet article.

Erreur 80072EFD

En lançant une recherche des mises à jours sur deux serveurs virtuels (un contrôleur de domaine et un serveur applicatif) chez un client, je constate que la même erreur a lieu sur les deux. Erreur 80072EFD.

Sur le serveur physique (Windows Server 2008 SBS), les mises à jours sont trouvées sans problème. Ma première piste est donc un problème de paramétrage réseau. Mais ce n’est pas ca. La passerelle, le DNS, tout semble fonctionner.

Je regarde donc dans les logs, afin de savoir comment les mises à jours se font. Si vous ne le savez pas, le service Windows Update écrit dans un journal. On le trouve dans C:\Windows\SoftwareDistribution, et il se nomme ReportingEvents.log

Dans ce journal, je trouve la même ligne répétée inlassablement :

{96EE4D61-8641-4E33-AEA9-6833E286BE74} 2016-01-03 20:16:01:782+0100 1 148 101 {D67661EB-2423-451D-BF5D-13199E37DF28} 1 80072efd SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x80072efd.

Ok, donc toutes les fois que le service tente un update, la même erreur se produit.

Une info intéressante est donnée sur l’écran de mises à jours :

Window Update Erreur 80072EFDAucune mise à jour ne s’est installée depuis le 10 septembre 2012. Ce qui est intéressant, c’est que ces serveurs ont été installés en 2010. Donc le problème est venu en cours de route, pas du départ. On avance…

WSUS

Après avoir effectué quelques recherches, je trouve la cause du problème. Le service Windows Server Update Services (WSUS) a du être installé, puis désinstallé. Mais visiblement, un dysfonctionnement existe dans la désinstallation de WSUS. Si vous êtes dans le même cas, voilà comment vérifier qu’il s’agisse bien de ce problème, et comment le corriger.

Vérification et correction

Dans le registre, les informations relatives à la localisation des recherches de mises à jour ne sont pas retirées lors d’une désinstallation.

Pour le vérifier, avec l’éditeur de registre, vérifiez la clé suivante : HKLM/Software/Policies/Microsoft/Windows/WindowsUpdate

WSUS supprimer

On voit ici que les deux valeurs « WUServer » et « WUStatusServer » sont renseigné. En l’occurrence, il s’agissait d’une des deux VM (le contrôleur de domaine) qui avait donc été configuré comme serveur WSUS.

  • “WUServer”=http://nom_du_serveur:8530
  • “WUStatusServer”=http://nom_du_serveur:8530

Supprimez la clé Windows Update (entièrement) en prenant soin de l’exporter au préalable, par précaution.

Redémarrez le service Windows Update, et tout doit maintenant fonctionner normalement.

Votre service Windows Update est maintenant fonctionnel, et il vous restera à faire passer les mises à jour, afin de sécuriser le système.

About Samuel Monier

Informaticien indépendant Réseaux et systèmes - Infrastructure - Serveurs. J'interviens sur les départements 42 - 63 - 69 - 43 - 71, et à échelle nationale à distance. N'hésitez pas à me demander conseil!

A lire également

adobe-flash-player

Adobe Flash Player : Failles corrigées

A travers la version 21.0.0.182 de Flash Player, Adobe corrige 23 failles découvertes récemment. Encore …

  • Arthur Poitou

    Salut,
    Sur ton screen, on peut voir que « Vous recevez les mises à jour : Géré par votre administrateur système ».
    Cette phrase indique effectivement qu’un WSUS est paramétré. De façon plus propre (au lieu de checker le registre), tu aurais pu vérifier les stratégie de groupe local et à mon avis, tu aurais trouvé également http://nom_du_serveur:8530 dans une stratégie.

    • Pyrithe

      Salut,
      Pour le fichier de log, c’est effectivement une confusion de ma part. Le fichier de log C:WindowsSoftwareDistributionReportingEvents.log contient
      en réalité les problèmes applicatives ou événements systèmes (fichiers
      manquants, etc). J’ai rédigé cet article à posteriori et j’ai pris un
      raccourci.
      Pour ce qui est du registre, je l’indique volontairement
      comme ca. Car cet article a pour but d’aider à solutionner le problème,
      et la solution passe par la suppression de la clé. Donc vérifier ce
      qu’on va corriger est plus simple à expliquer, et à appliquer, non? 😉
      Et
      plus « propre » à mon avis, car je pense au contraire que la stratégie
      n’y est plus, car WSUS n’est plus utilisé. Mais cette clé prévaut, et
      oriente les recherche d’un Update sur un serveur qui n’est pas un
      serveur WSUS…
      Il s’agirait d’un bug de désinstallation de WSUS,
      sachant qu’on ne désinstalle pas ce genre de produit comme une simple
      application…