Vous rencontrez un blocage Sysprep sur Windows Server 2025 24H2 ? Ce guide exhaustif explique pas à pas pourquoi l’erreur 0x80073CF2 se produit et comment la résoudre définitivement, y compris l’automatisation avec PowerShell.
Échec de Sysprep sur Windows Server 2025 (24H2 Build 26100.2314)
Vue d’ensemble du problème
- Contexte : l’exécution de Sysprep en mode Generalize échoue systématiquement avec le code
0x80073CF2. - Cause identifiée : le package
Microsoft.Winget.Sourceest installé pour l’utilisateur courant mais non « provisionné » pour tous les profils. Sysprep bloque dès qu’une application UWP (AppX) se trouve dans cet état hybride. - Symptôme observé : Sysprep se termine en quelques secondes, le journal setupact.log affiche :
AppxSysprep.dll::SysprepPackageRemove: ... 0x80073CF2
Comprendre la mécanique interne
Sysprep applique trois règles immuables avant la généralisation :
- Toute application UWP présente dans l’image doit être soit provisionnée (disponible pour chaque nouveau profil), soit totalement absente.
- Si un seul paquet AppX figure dans l’état « Installé pour l’utilisateur A mais non provisionné », Sysprep s’abort. Il n’existe aucun paramètre caché pour outrepasser cette sécurité ; l’intégrité de l’image prime.
- Le composant interne
AppxSysprep.dllréalise ce balayage très tôt dans la phase Generalize, avant le « système de mini-setup ». Tout échec lève le code0x80073CF2.
Pourquoi Microsoft.Winget.Source pose problème ?
Depuis Windows 11 et Server 2025, le moteur d’installation WinGet s’appuie sur plusieurs AppX auxiliaires (dont Microsoft.Winget.Source) distribués via le Microsoft Store. Si vous avez lancé WinGet ou ouvert le Store avant la généralisation, ces paquets s’installent seulement pour votre profil interactif. D’où l’état « installé mais non provisionné ».
Solution détaillée pas à pas
| Étape | Commande PowerShell | Objectif |
|---|---|---|
| 1 – Inventaire ciblé | Get-AppxPackage | Where-Object {$_.PackageFullName -like "*Winget.Source*"} Get-AppxProvisionedPackage -Online | Where-Object {$_.PackageName -like "*Winget.Source*"} | Identifier la présence du package côté user et côté provision. |
| 2 – Désinstallation tous profils | Get-AppxPackage -AllUsers *Winget.Source* | Remove-AppxPackage | Supprimer chaque instance installée pour chaque utilisateur existant. |
| 3 – Retrait de l’image | Remove-AppxProvisionedPackage -Online -PackageName Microsoft.Winget.Source_* | Éliminer la version « provisionnée », empêchant toute future installation automatique. |
| 4 – Vérification finale | Get-AppxPackage -AllUsers | Sort Name | S’assurer qu’aucun résidu AppX n’est présent. |
| 5 – Relance Sysprep | sysprep /generalize /oobe /shutdown | L’opération se conclut désormais sans erreur. |
Script d’automatisation prêt à l’emploi
Intégrez ce bloc dans votre pipeline CI/CD, votre séquence MDT ou votre playbook Ansible pour automatiser la correction :
#Requires -RunAsAdministrator
Write-Host "▲ Suppression des applications UWP conflictuelles..." -ForegroundColor Cyan
\$Pattern = "*Winget.Source*"
# 1. Désinstaller pour tous les utilisateurs
Get-AppxPackage -AllUsers \$Pattern |
ForEach-Object {
Write-Host " └─ Removing \$(\$*.PackageFullName)" -ForegroundColor Yellow
Remove-AppxPackage -Package \$*.PackageFullName -AllUsers
}
# 2. Retirer du provisioning
\$Prov = Get-AppxProvisionedPackage -Online | Where-Object PackageName -like \$Pattern
if (\$Prov) {
Write-Host " └─ Deprovisioning \$(\$Prov.PackageName)" -ForegroundColor Yellow
Remove-AppxProvisionedPackage -Online -PackageName \$Prov.PackageName
}
# 3. Contrôle post‑action
Write-Host "▲ Vérification..." -ForegroundColor Cyan
\$Left = Get-AppxPackage -AllUsers | Where-Object Name -like \$Pattern
if (-not \$Left) {
Write-Host " ✔ Aucun package \$Pattern restant." -ForegroundColor Green
} else {
Write-Host " ✖ Des packages subsistent !" -ForegroundColor Red
\$Left | Format-Table Name, PackageFullName
} Bonnes pratiques avant exécution de Sysprep
- Mettre à jour l’OS : appliquez les correctifs cumulés (
Dism /Online /Add-Package) pour éviter d’autres incompatibilités. - Déconnecter du domaine : Sysprep échoue souvent si la machine est toujours membre d’un AD.
- Désactiver la connexion Wi‑Fi ou LAN durant la phase préparatoire : empêche le Store de réinstaller de nouvelles UWP à la volée.
- Désactiver les mises à jour automatiques du Microsoft Store via la stratégie : Computer Configuration → Administrative Templates → Windows Components → Store → Turn off Automatic Download of Updates.
- Nettoyer les « Scheduled Tasks » WinGet/Store (
\Microsoft\Windows\Management\WinGet) si vous ne prévoyez pas d’utiliser WinGet dans l’image finale.
FAQ – Questions fréquentes
Sysprep échoue toujours alors que Microsoft.Winget.Source est supprimé ?
D’autres AppX, comme Microsoft.DesktopAppInstaller ou Microsoft.VCLibs, peuvent présenter le même état hybride. Adaptez le script avec un motif générique (ex. *Winget* ou la liste complète obtenue par Get-AppxPackage). Puis‑je réinstaller WinGet après Sysprep ?
Oui. Dès que l’image est déployée et la phase OOBE terminée, exécutez winget install winget ou laissez le Store réinstaller les dépendances. L’exigence de Sysprep ne s’applique plus. Le retrait de l’AppX menace‑t‑il la sécurité ou la compatibilité ?
Non ; Microsoft.Winget.Source n’est qu’un fournisseur de catalogue. WinGet fonctionne encore en mode EffectiveUserSource ou via des sources Rest personnalisées. Toutefois, sans le package, la source officielle community reste inutilisable jusqu’à réinstallation.
Conclusion
L’erreur 0x80073CF2 n’est plus une fatalité ! En supprimant proprement le package Microsoft.Winget.Source (et tout autre AppX non provisionné), vous restaurez la compatibilité Sysprep sur Windows Server 2025 24H2. Automatisez le correctif, verrouillez le Microsoft Store, puis déployez vos images en toute sérénité.