La mise à jour cumulative KB5034439 échoue systématiquement sur certains hôtes Windows Server 2022 dépourvus de partition Windows Recovery Environment (WinRE). Cette analyse vous aide à comprendre la cause, à décider s’il faut intervenir et à appliquer, le cas échéant, la stratégie de remédiation la plus adaptée à votre infrastructure.
Échec de l’installation de KB5034439 (WinRE) – Vue d’ensemble
Publié le 9 janvier 2024, le correctif KB5034439 corrige la vulnérabilité CVE‑2024‑20666 en mettant à jour le composant WinRE. Lorsqu’aucune partition de récupération n’est présente, l’installateur retourne l’erreur 0x800F081F (« The source files could not be found ») ou 0x80242016 après plusieurs tentatives, puis bascule en état Échec. Les articles officiels de Microsoft recommandent de recréer WinRE, mais cette opération n’est pas toujours nécessaire ni souhaitable sur des VM cloud minimalistes.
Pourquoi l’échec est‑il normal dans certains cas ?
- Absence de partition WinRE : de nombreux fournisseurs IaaS suppriment la partition de récupération afin de réduire la taille des images « golden » et diminuer le temps de clonage.
- Installateur conditionnel : KB5034439 cible exclusivement l’image WinRE (
Winre.wim). Sans destination valide, le programme d’installation considère la source comme introuvable. - Pas d’impact fonctionnel : si vous externalisez déjà la reprise d’urgence (snapshots, solutions de sauvegarde), l’absence de WinRE ne fragilise ni la sécurité du noyau, ni la stabilité du rôle serveur.
Solutions possibles et critères de choix
| Solution proposée | Détails clés | Étapes pratiques |
|---|---|---|
| Aucune action si WinRE est absent | La mise à jour est conditionnelle : sans partition, l’échec est normal et bénin. | Ouvrez un Command Prompt en mode administrateur et exécutez :reagentc /info Si le résultat indique Windows RE Status : Disabled ou WinRE location : Not set, aucune partition WinRE n’existe. Considérez la tentative d’installation comme non pertinente et masquez le correctif via wusa /hide ou une règle WSUS/SCCM. |
| Créer ou réparer WinRE (optionnel) | Recommandé si vous avez besoin des outils de récupération ou d’images personnalisées. | Réservez au minimum 750 Mo d’espace libre sur le disque système. Lancez diskpart, puis :create partition primary size=750 format quick fs=ntfs label="Recovery" set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac gpt attributes=0x8000000000000001 assign letter=R exit Copiez WinRE :robocopy C:\Windows\System32\Recovery R:\Recovery /r:1 /w:1 Réactivez l’image :reagentc /setreimage /path R:\Recovery reagentc /enable Redémarrez puis relancez Windows Update ou appliquez le fichier .cab de KB5034439 avec dism /online /add-package. |
| Installer hors ligne (image ou ISO) | Utile pour préparer des images gold prêtes pour le déploiement. | Montez le fichier install.wim dans un dossier de travail. Injectez le correctif :dism /image:D:\Mount /add-package /packagepath:KB5034439.cab Vérifiez avec dism /image:D:\Mount /get-packages puis commit et démontez. Utilisez ensuite cette image actualisée pour vos futurs déploiements. |
Critères de décision
Avant toute modification, posez-vous trois questions :
- Le serveur a‑t‑il besoin de WinRE ? Pour un contrôleur de domaine ou un cluster Hyper‑V, disposer de l’environnement de récupération peut simplifier la maintenance hors ligne. Pour une passerelle RDS stateless, le gain est discutable.
- L’espace disque est‑il critique ? La partition Recovery n’est pas compressée. Sur des disques système de 30 Go, chaque mégaoctet compte.
- Existe‑t‑il une chaîne CI/CD d’image ? Si vos VM proviennent d’un pipeline Packer/DevOps, préférez l’injection hors ligne afin de garder la cohérence sur tout le parc.
Vérifications préalables et diagnostics étendus
Si le message d’erreur n’est pas explicite, consultez le journal CBS (%windir%\Logs\CBS\CBS.log) ou analysez WindowsUpdate.log généré par PowerShell 7 (Get-WindowsUpdateLog). Cherchez la séquence :
!!! WIM Mount Location not found, update cannot be installed
CBS_E_SOURCE_MISSING - Package_55_for_KB5034439La présence de cette ligne confirme que la source WinRE est absente.
Automatiser la détection et la correction
Dans un parc de plusieurs centaines de VM, vous pouvez automatiser l’audit et la création de WinRE :
# Detect-WinRE.ps1
$info = (reagentc /info) -join "`n"
if ($info -notmatch "Windows RE Status.*Enabled") {
Write-Host "WinRE missing – KB5034439 will fail." -ForegroundColor Yellow
# Optional remediation
# .\Create-WinRE.ps1
}Déclenchez ce script via Azure Automation Account ou un runbook AWS SSM. Les administrateurs reçoivent un e‑mail ou un incident ITSM uniquement lorsque l’option corrective s’exécute, ce qui réduit le bruit opérationnel.
Bonnes pratiques pour environnement cloud
- Standardisez les images : maintenez une « golden image » par type de workload (SQL, IIS, Remote Desktop) et appliquez vos décisions WinRE au moment du bake.
- Documentez votre choix : chaque création de machine doit embarquer un tag («
WinRE=False» ou «WinRE=True») pour aider le centre d’exploitation à filtrer les alertes. - Soyez cohérent entre production et DR : si la prod n’a pas WinRE, il est inutile que le site de secours l’ait, ou inversement.
- Intégrez l’audit dans le pipeline de sécurité : un scanner vulnérabilité peut signaler l’absence de KB5034439 comme un faux positif. Alimentez les exceptions de manière déclarative (JSON/YAML).
FAQ rapide
Ignorer KB5034439 réduit‑il le niveau de correctifs de mon serveur ? Non, le patch cible uniquement le micro‑environnement de récupération (WinPE). L’OS et ses pilotes restent protégés. Puis‑je masquer définitivement la mise à jour ? Oui : Hide-WindowsUpdate -KBArticleID KB5034439 -HideStatus Hide via le module PSWindowsUpdate. Qu’arrive‑t‑il si je crée WinRE dans six mois ? Le correctif ne sera pas présent. Réexécutez simplement wuauclt /detectnow ou installez KB5034439 en différé.
Surveiller les futurs correctifs WinRE
Microsoft publie en moyenne un correctif WinRE critique tous les 12 à 18 mois. Ajoutez donc à votre feuille de route :
- Un contrôle mensuel de la taille et de la présence de la partition Recovery – scripté.
- Une revue semestrielle des modèles ARM/CloudFormation/Terraform pour garantir la cohérence.
- Un processus d’obsolescence : si vous changez de stratégie (p. ex. réintégrer WinRE), documentez le rollback et les phases pilotes.
Conclusion
Face à l’échec de KB5034439, la priorité est d’évaluer si WinRE constitue réellement une exigence opérationnelle. Dans les architectures cloud modernes, l’espace disque et la vitesse de déploiement priment souvent sur la présence d’un environnement de récupération local. Si vos procédures de reprise reposent déjà sur des instantanés ou une automatisation d’infrastructure, l’absence de WinRE et le message d’erreur associé peuvent être ignorés sans risque. À l’inverse, si vos équipes support utilisent les outils de dépannage WinRE, créez ou réparez la partition dès que possible et appliquez le correctif. Dans tous les cas, consignez la décision dans votre documentation d’exploitation et vos scripts d’orchestration pour éviter des surprises lors des prochains Patch Tuesdays.