Votre serveur Windows Server 2016 reste bloqué à 0 % lors du téléchargement des mises à jour ? Suivez ce guide opérationnel pour diagnostiquer, corriger et sécuriser durablement Windows Update dans les environnements connectés à Internet, derrière proxy/pare‑feu ou reliés à un WSUS.
Problème
Sur Windows Server 2016, il arrive que Windows Update reste figé à 0 % pendant la phase de téléchargement, que ce soit pour une mise à jour cumulative, une pile de maintenance (SSU) ou un pilote. Le Gestionnaire de serveur affiche « Téléchargement : 0 % » indéfiniment, parfois avec une activité réseau nulle et sans message d’erreur expliquant l’arrêt. Le phénomène peut se produire après un redémarrage planifié, un changement de proxy, l’application d’une GPO ou à la suite d’un échec précédent de Windows Update.
Pour éviter les itérations improductives, ce guide combine vérifications rapides, procédures de remise à zéro, contrôles GPO/WSUS, et tests réseau afin de lever les causes les plus probables et de valider le retour à la normale.
Causes et vérifications essentielles
Domaine | Points de contrôle |
---|---|
Connectivité | Vérifier l’accès Internet (ping externe, navigation). Tester la résolution DNS, la sortie HTTP/HTTPS et la latence. Ex. : ping 8.8.8.8 , nslookup download.windowsupdate.com . |
Services Windows Update | S’assurer que le service Windows Update est démarré et en démarrage Automatique. Vérifier aussi BITS, Cryptographic Services et Windows Installer. |
Cache de mise à jour | Contenu obsolète ou corrompu dans SoftwareDistribution et Catroot2 pouvant bloquer la file de téléchargement. |
Espace disque | Confirmer qu’il reste assez d’espace sur la partition système. Les mises à jour cumulatives exigent souvent plusieurs Go (téléchargement + décompression). |
Stratégies de groupe (GPO) | Aucune règle ne doit bloquer les mises à jour (forçage d’un WSUS non joignable, désactivation BITS, planification restreinte, débits limités). |
Fichiers système | Corruptions éventuelles (SFC/DISM) empêchant la détection, l’évaluation ou la mise en cache des packages. |
Pare‑feu / proxy | Ports ou URL de Windows Update peut‑être filtrés, inspection SSL ou authentification proxy incompatible avec WinHTTP. |
Commandes de contrôle rapides
Exécutez ces commandes en tant qu’administrateur pour un premier diagnostic :
- État des services :
sc query wuauserv && sc query bits && sc query cryptsvc && sc query msiserver
- WinHTTP proxy :
netsh winhttp show proxy
- DNS et sortie HTTPS :
nslookup windowsupdate.microsoft.com PowerShell: Test-NetConnection download.windowsupdate.com -Port 443
- Quota et espace :
PowerShell: Get-Volume -DriveLetter C | ft DriveLetter,SizeRemaining -Auto
- GPO appliquées :
gpresult /H C:\Temp\gpresult.html
Procédure de résolution pas à pas
- Redémarrer les services Windows Update
net stop wuauserv net stop cryptSvc net stop bits net stop msiserver ren C:\Windows\SoftwareDistribution SoftwareDistribution.old ren C:\Windows\System32\catroot2 Catroot2.old net start wuauserv net start cryptSvc net start bits net start msiserver
Effet : réinitialise complètement le cache de mise à jour. Pourquoi : les répertoiresSoftwareDistribution
etCatroot2
contiennent l’historique, les métadonnées et les téléchargements. Un cache incohérent empêche la reprise du téléchargement. Cette remise à zéro force une nouvelle détection. Valider : relancer une recherche (UsoClient StartScan
) et surveiller l’évolution du pourcentage. Contrôler aussi%windir%\WindowsUpdate.log
généré viaGet-WindowsUpdateLog
.
Arbre de décision rapide
- Aucune sortie réseau → tester DNS/HTTPS, proxy, certificats, inspection TLS. Si
Test-NetConnection ... -Port 443
échoue, corriger le réseau avant tout. - Services désactivés → remettre les services BITS/WUAUSERV en Automatique et démarrer.
- Cache corrompu → renommer SoftwareDistribution et Catroot2 puis relancer une détection.
- GPO WSUS actives mais serveur WSUS injoignable → désactiver temporairement ou pointer vers un WSUS opérationnel.
- Erreur DISM/SFC → réparer l’image, puis relancer Windows Update.
- Seul ce serveur est affecté → chercher corruption locale (journal WU, BITS), pilotes réseau, espace disque.
- Tous les serveurs sont affectés → suspecter réseau/proxy/pare‑feu ou panne WSUS.
Cas particuliers en environnement WSUS
Si une GPO impose un WSUS et que le téléchargement reste à 0 % :
- Vérifier l’approbation des mises à jour, les groupes cibles et la synchronisation WSUS.
- Contrôler l’espace disque sur le serveur WSUS (répertoire WsusContent) et la base de données.
- Tester une dérogation temporaire pour interroger directement Microsoft Update (à n’utiliser qu’en maintenance contrôlée) :
REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v UseWUServer /t REG_DWORD /d 0 /f net stop wuauserv && net start wuauserv UsoClient StartScan
Revenez ensuite à la configuration WSUS attendue (UseWUServer=1
) et appliquezgpupdate /force
.
Dépannage réseau avancé
- Présence d’une inspection TLS : exclure les domaines Windows Update du déchiffrement, sinon les connexions échouent.
- Versions TLS : Windows Server 2016 prend en charge TLS 1.2. Évitez de forcer TLS 1.0 uniquement via des durcissements SChannel. Vérifier les clés SchUseStrongCrypto si un durcissement a été appliqué.
- Résolution DNS : latence excessive ou échecs sporadiques peuvent figer la barre de progression. Essayez un autre résolveur temporairement pour lever le doute.
Journalisation et observation
Quand le pourcentage reste à 0 %, Windows Update attend souvent un jeton BITS, une réponse du WSUS, une validation de contenu ou une ressource réseau. Observez :
- Événements : Observateur d’événements → WindowsUpdateClient/Operational.
- Queue BITS :
PowerShell: Get-BitsTransfer -AllUsers | fl * bitsadmin /list /allusers /verbose
- Déclencheur de détection :
UsoClient StartScan UsoClient StartDownload UsoClient StartInstall
- État des services avec types de démarrage :
PowerShell: Get-Service wuauserv,bits,cryptsvc,msiserver | Select Name,Status,StartType
Erreurs fréquentes et actions recommandées
Code/Message | Interprétation probable | Action |
---|---|---|
0x80072EE2 | Délai dépassé (timeout) HTTP(S) | Vérifier proxy/pare‑feu, latence WAN, exclusion de domaines WU, test Test-NetConnection . |
0x8024402C | Nom proxy/WSUS mal résolu ou syntaxe GPO incorrecte | Corriger GPO WSUS/proxy, nettoyer WinHTTP (netsh winhttp reset proxy ). |
0x8024401C | Timeout WSUS côté client | Vérifier santé WSUS, IIS, bande passante, et taille du pool d’applis. |
0x80070422 | Service désactivé | Mettre wuauserv et BITS en Automatique, démarrer les services. |
0x800F081F | Source de réparation introuvable | Réparer l’image DISM /Source , puis relancer SFC et Windows Update. |
0x8024A105 | Composant WU instable | Réinitialiser SoftwareDistribution/Catroot2, redémarrer, retester. |
Script d’automatisation fiable
Conservez ce script .cmd pour vos fenêtres de maintenance :
@echo off
:: Réinitialisation Windows Update (Server 2016)
sc stop wuauserv
sc stop bits
sc stop cryptsvc
sc stop msiserver
takeown /F "%windir%\SoftwareDistribution" /A /R /D Y
icacls "%windir%\SoftwareDistribution" /grant Administrators:F /T
ren "%windir%\SoftwareDistribution" "SoftwareDistribution.old"
ren "%windir%\System32\catroot2" "Catroot2.old"
sc start cryptsvc
sc start bits
sc start msiserver
sc start wuauserv
echo Lancement d'une détection...
UsoClient StartScan
echo Terminé. Redémarrez le serveur si des mises à jour sont installées.
Astuce : stockez le script et supprimez les dossiers .old
après résolution pour récupérer de l’espace.
Bonnes pratiques pour éviter les blocages
- Planifier des redémarrages après grosses mises à jour (CU + SSU) pour libérer les DLL verrouillées et finaliser le nettoyage des composants.
- Surveiller l’espace disque sur C: et sur les volumes contenant SoftwareDistribution (si déplacé).
- Maintenir le pilote réseau à jour, surtout sur les serveurs virtualisés ou très chargés.
- Stabiliser le proxy et exclure les domaines Microsoft des inspections TLS.
- Documenter les GPO liées à Windows Update/WSUS pour faciliter le retour arrière.
Informations complémentaires utiles
Astuce | Détails |
---|---|
Synchronisation horaire | Une date/heure incorrecte peut bloquer TLS et l’authentification des mises à jour. |
Pilote réseau | Un pilote obsolète peut causer des erreurs de téléchargement ; mettre à jour si disponible. |
Redémarrage complet | Après toute réinitialisation importante, redémarrer le serveur pour libérer les DLL verrouillées. |
Nettoyage post‑incident | Une fois le problème réglé et les mises à jour installées, vous pouvez supprimer SoftwareDistribution.old et Catroot2.old pour récupérer de l’espace. |
WSUS hors ligne | Si le serveur n’a pas d’accès Internet fiable, envisager WSUS Offline ou un point de distribution interne. |
Vérifications complémentaires et pièges courants
- Conflit antivirus/EDR : certains agents bloquent l’écriture dans SoftwareDistribution. Prévoir des exclusions de répertoire/processus le temps des mises à jour.
- Quota système : sur des systèmes fortement journalisés, la taille des logs peut croître et saturer le disque. Rotate et compressez.
- Comptes de service restreints : BITS ou Windows Update doivent fonctionner sous leurs comptes par défaut. Éviter les durcissements qui retirent des droits essentiels.
- MTU/fragmentation : en VPN/IPsec, une MTU trop basse peut casser le téléchargement. Testez sans tunnel pour isoler la cause.
Checklist de validation après correctifs
- La recherche de mises à jour s’achève sans erreur (État : Votre appareil est à jour).
- Le téléchargement dépasse 0 % et progresse de manière régulière.
- Les services wuauserv et BITS sont actifs et en Automatique.
- Aucun événement récurrent d’échec
0x8024*
n’apparaît dans WindowsUpdateClient/Operational. - Un redémarrage finalise l’installation sans rollback.
FAQ express
Dois‑je réinstaller le serveur ?
La grande majorité des blocages à 0 % se résolvent par la remise à zéro du cache, la correction réseau/proxy et le nettoyage des composants. Gardez la réinstallation en tout dernier recours (ou une réparation sur place) après sauvegarde. Dans quel ordre exécuter SFC et DISM ?
Exécutez SFC
, puis DISM /RestoreHealth
. Si SFC échoue, lancez DISM
avec une source valide, redémarrez, puis relancez SFC
. Comment forcer une détection/installation ?
Vous pouvez déclencher : UsoClient StartScan
, UsoClient StartDownload
, UsoClient StartInstall
. Sur 2016, ces commandes existent mais n’affichent pas toujours de sortie console. Que faire si seul un type de mise à jour bloque ?
Essayez l’installation manuelle via un .msu (catalogue), puis laissez Windows Update reprendre. Si un pilote est en cause, cachez‑le temporairement et installez d’abord la CU.
Conclusion
Un téléchargement bloqué à 0 % sur Windows Server 2016 provient le plus souvent d’un cache Windows Update endommagé, d’un réglage GPO/WSUS inadapté ou d’un blocage réseau/proxy. En appliquant méthodiquement les étapes décrites — réinitialisation des composants, vérifications réseau, contrôle des stratégies, analyse SFC/DISM et, si besoin, installation manuelle — vous restaurez un cycle de mise à jour fiable, sans recourir à une réinstallation.