MENU
  1. Accueil
  2. Python
  3. Erreur 0x800f081f lors de KB5048654 sur Windows Server 2022 : comment la résoudre avec l’in‑place upgrade

Erreur 0x800f081f lors de KB5048654 sur Windows Server 2022 : comment la résoudre avec l’in‑place upgrade

Python

La mise à jour cumulative KB5048654 de décembre 2024 refuse de s’installer sur certains serveurs Windows Server 2022 Standard et interrompt le processus avec le code 0x800f081f / CBS_E_SOURCE_MISSING. Le serveur signale que les fichiers requis sont absents du magasin WinSxS et qu’aucune source valide n’est détectée.

Sommaire

Problématique

Lors du redémarrage de l’hôte ou après l’exécution manuelle de Windows Update, l’installation de la CU KB5048654 échoue systématiquement :

  • État : Échec  |  Heure d’installation ≈ 10–15 min.
  • Identifiant d’erreur : 0x800f081f (désigne l’absence ou la corruption des sources de mise à jour).
  • Journal CBS.log : entrées répétées “CBS_E_SOURCE_MISSING” et “Payload file is missing”.

Le scénario se rencontre fréquemment sur des environnements où :

  1. Des optimisations de disque ont supprimé des composants WinSxS.
  2. La machine est isolée du réseau ou n’accède qu’à un WSUS incomplet.
  3. Un précédent Servicing Stack Update a été interrompu ou annulé.

Symptômes supplémentaires observés

En parallèle du code 0x800f081f, les administrateurs notent parfois :

  • Arrêts du service TrustedInstaller avant la phase « Commit ».
  • Erreur “Session: _XXXXXXX – Failed to finalize updates” dans le journal Setup‑et‑Maintenance.
  • Échec de montage de l’image lorsque la commande DISM /Get-Packages est utilisée.

Dépannages déjà tentés

TentativeCommandes / actions principalesRésultat
Réinitialisation de Windows UpdateArrêt des services BITS, WUAUSERV, CryptSvc, AppIDSvc ; renommage de SoftwareDistribution et catroot2 ; redémarrage des servicesL’erreur réapparaît lors de la réinstallation
Outils d’intégritéDISM /StartComponentCleanup  |  DISM /RestoreHealth  |  sfc /scannowAucun fichier système critique manquant, mais la CU échoue toujours
Dépanneur Windows UpdateDétecte un dysfonctionnement et indique l’avoir corrigéLa tentative suivante reste bloquée à 0x800f081f
Installation manuelleTéléchargement du .msu > extraction du .cab > DISM /online /add‑package /packagepath:…Même code d’erreur, source introuvable
Nouvelle réinitialisation complèteRépétition des scripts d’arrêt/renommage/redémarrageAucun changement ; échec persistant

Analyse technique de l’erreur 0x800f081f

Cette erreur est renvoyée par le moteur CBS (Component‑Based Servicing) lorsqu’il ne peut localiser le payload d’un composant référencé par la mise à jour :

  • Le composant a été supprimé lors d’un nettoyage (StartComponentCleanup ou Réduction d’image).
  • La SSU installée ne reconnaît pas le format du package.
  • Le point d’accès réseau (Internet / WSUS) remet un package tronqué ou chiffré par un proxy.

DISM recherche d’abord les fichiers dans %windir%\WinSxS, puis interroge l’emplacement configuré dans la stratégie de groupe (Specify settings for optional component installation), enfin interroge Windows Update si autorisé. Faute de réponse, CBS s’interrompt et renvoie 0x800f081f.

Solution éprouvée : réparation in‑place upgrade

Prérequis

  • ISO de Windows Server 2022 (même édition, même langue). Un build supérieur est accepté si la CU est plus récente.
  • 10 Go d’espace disque libre minimum sur la partition système.
  • Sauvegarde ou snapshot de la VM.

Étapes détaillées

  1. Monter l’ISO ou connecter le DVD sur le serveur.
  2. Ouvrir une session Administrateur / Admin Domain et exécuter setup.exe.
  3. Sélectionner « Conserver les fichiers, applications et paramètres ».
  4. Décocher la récupération des mises à jour en ligne pour minimiser la durée (optionnel).
  5. L’assistant copie un nouveau install.wim, réimporte les composants manquants, met à jour le registre, puis redémarre deux fois.
  6. Une fois l’OS restauré, rechercher les mises à jour : la KB5048654 se télécharge et s’applique sans erreur.

Pourquoi cela fonctionne

La réparation in‑place remonte un install.wim sain comme source prioritaire. Les packages corrompus sont remplacés, les métadonnées Servicing régénérées et le Component Store re‑indexé. Aucun rôle ni application n’est perdu car le processus conserve la configuration actuelle.

Retours d’expérience

  • Plusieurs administrateurs confirment une réussite immédiate.
  • Un échec isolé provenait d’une perte de connectivité réseau pendant le téléchargement des packages additionnels.
  • La durée totale varie de 30 min à 2 h selon les performances disque.

Alternatives avant l’in‑place upgrade

Si une fenêtre d’indisponibilité prolongée n’est pas envisageable :

  1. Installer manuellement la dernière SSU disponible (KB503XXXX) avant de réessayer la CU.
  2. Monter l’ISO du même build et expliciter la source :
    dism /online /add-package /packagepath:"C:\Temp\KB5048654.cab" ^ /source:wim:D:\sources\install.wim:1 /LimitAccess D: représente ici la lettre du lecteur virtuel.
  3. Vérifier qu’aucune stratégie Specify settings for optional component installation ne bloque Windows Update.
  4. Exécuter Get-WindowsPackage -Online | ? InstallationState ‑eq "Superseded" pour repérer les composants orphelins.

Bonnes pratiques de maintenance

  • Planifier un nettoyage périodique : DISM /Online /StartComponentCleanup /ResetBase après chaque Patch Tuesday.
  • Conserver un ISO “Gold” du même build que le serveur, stocké sur le réseau, pour servir de source de secours.
  • Surveiller l’espace disque : WinSxS peut dépasser 12 Go ; déclencher un nettoyage quand la partition système approche 80 %.
  • Documenter les périodes de gel (change freeze) pour éviter la suppression prématurée de packages non encore sécurisés.

Résumé opérationnel

  • Erreur : KB5048654 échoue avec 0x800f081f car la source est absente ou endommagée.
  • Tentatives classiques (réinitialisation WU, DISM, installation hors‑ligne) → échecs répétés.
  • Solution fiable : réparation in‑place upgrade depuis l’ISO, en conservant données et rôles.
  • Étapes clés : monter ISO → setup.exe → conserver données → redémarrer → relancer Windows Update.
  • Prévention : sauvegarde, SSU à jour, source install.wim explicite, nettoyage récurrent du magasin de composants.

Focus sur le composant WinSxS

Le dossier %windir%\WinSxS stocke toutes les versions de chaque composant déployé sur le système. Chaque mise à jour cumulative ajoute ses propres métadonnées, tandis que les anciennes versions sont marquées comme superseded. Le nettoyage par StartComponentCleanup supprime physiquement ces versions obsolètes, mais laisse les manifests XML nécessaires à l’historique. Si ce processus est interrompu (redémarrage brusque, coupure d’alimentation, limite d’espace disque), certaines références deviennent orphelines ; lors d’une mise à jour ultérieure, CBS ne trouve alors plus le fichier « payload » associé et génère 0x800f081f.

La réparation in‑place dispose d’un install.wim complet : elle recalcule la table COMPONENT\_BASED\_SERVICING du registre, restaure la version de base de chaque composant, puis réapplique les mises à jour préalablement installées. Cette opération, bien que plus longue qu’un simple DISM /RestoreHealth, garantit l’intégrité binaire et la cohérence des dépendances.

Gérer les environnements Core et clusterisés

Sur Server Core, l’in‑place upgrade reste possible en lançant setup.exe /auto upgrade /dynamicupdate disable depuis la console. Dans un cluster, retirez le nœud du quorum ou placez-le en mode maintenance pour éviter de déclencher un basculement inattendu le temps de l’opération.

Automatisation via PowerShell

Pour auditer plusieurs serveurs, le script suivant remonte la présence du KB et détecte 0x800f081f dans le journal CBS :

$servers = @("SRV‑APP01","SRV‑SQL02")
foreach($s in $servers){
 Invoke‑Command -ComputerName $s -ScriptBlock {
  $kb = Get‑HotFix -Id KB5048654 -ErrorAction SilentlyContinue
  if(!$kb){
   $cbs = Get‑Content C:\Windows\Logs\CBS\CBS.log -Tail 2000 |
       Select‑String "0x800f081f"
   if($cbs){Write‑Host "$env:COMPUTERNAME : échec 0x800f081f" -ForegroundColor Red}
   else     {Write‑Host "$env:COMPUTERNAME : autre échec"      -ForegroundColor Yellow}
  }else{
   Write‑Host "$env:COMPUTERNAME : KB déjà installée" -ForegroundColor Green
  }
 }
}

Ce rapport permet de cibler les machines réellement affectées avant de planifier une réparation.

Foire aux questions

La réparation in‑place change‑t‑elle la clé de produit ? Non. Le processus conserve l’activation existante et réimporte automatiquement le certificat KMS ou la clé MAK. Perd‑on les rôles AD DS, DNS ou DHCP ? Tous les rôles et fonctionnalités restent configurés, car le programme d’installation se limite aux composants système. Peut‑on appliquer cette méthode sur un serveur hébergeant le rôle Hyper‑V ? Oui. Les VM restent intactes. Il est néanmoins recommandé d’éteindre ou d’exporter les VM critiques en amont.

Python
Sommaire