Il y a quelques jours, un de mes clients a rencontré une série d’erreurs avec les Windows Update de ses Windows Server 2008 R2. À cette occasion, je me suis aperçu que le processus de mise à jour des serveurs était relativement obscur pour pas mal de monde. Voilà donc une bonne occasion d’expliquer, au travers de la correction de cette erreur, le fonctionnement du client de mise à jour Windows…
Identifier l’erreur
Lorsque l’on a ouvert la console d’un des serveurs concerné par le problème, l’agent Windows Update nous a immédiatement signalé qu’un redémarrage était en attente, bloquant le processus de mise à jour. Ok, jusque-là, rien d’impressionnant, procédons donc à un reboot… Sauf que voilà, de reboot en reboot, le système nous signale toujours que des fichiers sont verrouillés !
L’inconvénient ici, c’est qu’aucun code d’erreur ne peut nous être transmit par l’agent, celui-ci ne permettant pas de lancer le processus d’installation. Aucun problème, nous avons à notre disposition un journal de log particulièrement bien détaillé : C:WindowsWindowsUpdate.log. C’est à l’intérieur de celui-ci que nous avons identifié le code d’erreur 8024D00E.
WindowsUpdate.log
Lorsque vous parcourez le log de l’agent Windows Update, vous trouvez pas mal d’information. Le début du processus d’update commence toujours par la section :
START ## AU: Search for updatesLe log consigne alors tous les événements puis conclut avec la partie :
END ## AU: Search for updates [Callid = {…}].Dans l’exemple affiché ici, l’erreur est mise en évidence (encadré rouge et surlignage jaune) : noté par ailleurs la présence du mot clé error, sur lequel vous pouvez effectuer une recherche. Une fois le code d’erreur identifié, plongez-vous dans la lecture trépidante de ce KB M$ qui contient la liste des codes d’erreurs Windows Update (http://support.microsoft.com/kb/938205) :
REBOOTREQUIRED et l’agent Windows Update
Lorsque votre système exécute les mises à jour, il obtient pour chaque update un code de sortie. Si celui-ci est égal à 3010 alors l’agent Windows Update va créer une clé de registre volatile de type DWORD et lui donner pour valeur 1. Cette clé est placée dans la ruche :
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAuto UpdateRebootRequiredCette information est disponible également dans le log de l’agent (windowsUpdate.log) :
Voilà pour le processus « normal »… Seulement, dans notre cas, aucun update n’a été poussé et la ruche RebootRequiered n’existe pas !
« Selfupdate requires reboot » démystifié
Revenons dans notre log, à hauteur du code de sortie pour l’agent Windows Update :
On comprend qu’ici, en tout premier lieu, l’agent a reçu le résultat d’un contrôle (initié juste au-dessus dans le log) et qu’il a déterminé qu’il ne lui était pas possible de réaliser une opération d’update. Reste maintenant à comprendre comment ce contrôle est effectué : non seulement l’agent vérifie la présence de la ruche RebootRequired, mais en plus il réalise des contrôles sur l’état général du système.
Ainsi, l’installation d’une application peut bloquer les mises à jour : celle-ci en effet peut indiquer au système que certains fichiers actuellement verrouillés doivent être remplacés lors du prochain redémarrage. Ces nouveaux fichiers ayant été temporairement renommés sont indiqués dans une autre ruche de la base de registre :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerFileRenameOperationsLorsque une opération de renommage de fichier est présente (sous la forme d’une clé de type REG_MULTI_SZ), le système informe l’agent Windows Update qu’il ne peut pas effectuer de modification.
Enfin, il existe un dernier contrôle effectué par le système : l’altération du contenu du dossier Windows Side by Side Sharing (c:WindowsWinSxS). Ce dossier contient toutes les bibliothèques, fichiers manifestes et autres catalogues de sécurité dont le système a besoin pour faire tourner les applications.
Compte tenu de sa criticité, il n’est pas possible de modifier son contenu à la volée : Windows devra donc copier les nouveaux dossiers/fichiers et préparer les opérations de modifications à apporter lors du prochain redémarrage : cette opération est réalisée grâce à un fichier nommé pending.xml qui est situé à la racine du dossier WinSxS ; une fois le redémarrage effectué, le fichier est suppriméRésumons donc les trois points clés qui indiquent au système un reboot en attente :
<div style="text-align: justify;">La présence de clés dans l'une des deux ruches <span style="color: #ff6600;"><strong>HKEY_LOCAL_MACHINE</strong></span> de la base de registre :</div><div> </div>SOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAuto UpdateRebootRequired
SYSTEMCurrentControlSetControlSession ManagerFileRenameOperationsLa présence du fichier pending.xml dans le dossier c:windowsWinSxS
Résoudre le problème
En ce qui concerne les deux clés de registre, assurez-vous que les modifications en attentes ont bien été appliquées (présence du KB dans la liste des mises à jour avec l’état succès, pas de bug sur les applications installées présentes dans FileRenameOperations), vous pouvez tout simplement en supprimer le contenu (faites quand même une sauvegarde de la ruche avant).
Concernant le fichier pending.xml, vous pouvez le supprimer à une seule et unique condition : être sûr que les opérations en attente aient bien été appliquées. Dans mon cas, le fichier avait plus d’un an d’âge (belle cuvée!) et était complètement verrouillé : les opérations de prise de contrôle type TakeOwnership échouaient systématiquement. Il a fallu passer par le mode sans échec pour finalement supprimer le ficher et retrouver un fonctionnement normal du serveur…
