Correctif KB5036899 : résoudre l’erreur 1068 des services Windows Server 2016

Après l’installation du correctif cumulatif KB5036899 d’avril 2024 sur Windows Server 2016, de nombreux services refusent de démarrer avec l’erreur 1068. Cet article détaille les causes probables, les solutions de contournement et un plan d’action complet pour rétablir la disponibilité des serveurs tout en réduisant le risque sécuritaire.

Sommaire

Vue d’ensemble de la panne après KB5036899

Le déploiement du Build 14393.6897 déclenche, immédiatement ou au prochain redémarrage, une chaîne d’échecs dans le Gestionnaire de contrôle des services (Service Control Manager). L’événement 7000 ou 7001 apparaît dans l’Observateur d’événements et le message d’interface graphique signale :

« Windows n’a pas pu démarrer le service [Nom]… Erreur 1068 : le service ou groupe de dépendance n’a pas démarré. »

La suppression pure et simple du correctif rétablit les services concernés, démontrant que le problème n’est ni lié à une corruption système préexistante ni à la configuration propre des rôles serveur. De nombreux témoignages concordants émanent du forum Microsoft Q&A, de listes de diffusion d’administrateurs Active Directory et de blogs spécialisés.

Pourquoi l’erreur 1068 apparaît‑elle ?

Ordre de chargement modifié : KB5036899 introduit une nouvelle dépendance pour certains services réseaux (NLA, DHCP Client, DNS Client). Si cette dépendance ne répond pas à temps, la chaîne de démarrage se brise.
DLLs partagées mises à jour : des bibliothèques système (notamment netcfgx.dll) sont remplacées. Des produits tiers de téléphonie, de sauvegarde ou d’inventaire qui les injectent dynamiquement ne reconnaissent plus leur signature et se terminent inopinément.
Déphasage pile SSU / LCU : lorsque la dernière mise à jour de la pile de maintenance (SSU) n’est pas présente, l’environnement WinSxS peut charger simultanément plusieurs versions d’un même composant.
Antivirus hors support : certains moteurs EDR non mis à jour bloquent le chargement des nouveaux pilotes signés SHA‑2, intensifiant l’échec.

Plan d’action prioritaire

Priorité	Mesure	Détails
1	Désinstaller KB5036899	Exécutez `wusa /uninstall /kb:5036899 /quiet /norestart` puis redémarrez. Procédure graphique possible via Panneau de configuration › Programmes et fonctionnalités › Mises à jour installées. Source : Microsoft Learn.
2	Empêcher la réinstallation automatique	Dans WSUS, refuser ou expirer le correctif. Via GPO : stratégie Configurer les mises à jour automatiques → « Notifier pour téléchargement et installation ». Serveur non‑joint : outil Microsoft Show or hide updates pour masquer KB5036899.
3	Relancer les services de dépendance (provisoire)	Ouvrez `services.msc` › Propriétés du service en échec › onglet Dépendances. Démarrez manuellement chaque parent, puis redémarrez le service enfant.
4	Tester hors production	Reproduisez l’installation dans une VM de pré‑production, activez la journalisation `sc.exe` (`sc config EventLog GlobalFlags=1`) et surveillez les ID 7000/7001.
5	Mettre en pause Windows Update	Pause de 7 à 30 jours afin de limiter l’exposition aux failles sans alourdir la dette de patching. Ré‑évaluer à chaque Patch Tuesday.
6	Réparer d’éventuels fichiers système	`sfc /scannow` puis `DISM /Online /Cleanup-Image /RestoreHealth` après désinstallation, si l’erreur persiste.
7	Mettre à jour la SSU	Installez ou réinstallez la SSU KB5037016 publiée le 9 avril 2024. Plusieurs administrateurs rapportent une ré‑installation réussie de KB5036899 après cette opération.

Pas‑à‑pas : désinstallation détaillée

Audit préalable : exécutez Get-HotFix -Id KB5036899 pour confirmer la présence du patch.
Notification utilisateurs : programmez un redémarrage dans une fenêtre de maintenance, car la désinstallation redémarre le système.
Désinstallation silencieuse :
Start-Process "wusa.exe" -ArgumentList "/uninstall /kb:5036899 /quiet /norestart" -Wait
Redémarrage contrôlé : shutdown /r /t 0.
Vérification post‑action :
Get-EventLog -LogName System -Newest 20 | Where-Object {$_.EventID -eq 7036}

Empêcher la réinstallation – méthodes pas à pas

WSUS

1) Recherchez KB5036899 dans « Mises à jour ». 2) Clic droit › Refuser. 3) Exécutez une synchronisation descendante. Les ordinateurs dotés de la stratégie « Installer les mises à jour approuvées » ne re‑téléchargeront pas le correctif.

GPO

Ouvrez gpmc.msc › éditez l’objet lié à l’OU « Servers » › chemin : Configuration ordinateur › Stratégies › Modèles d’administration › Composants Windows › Windows Update. Activez « Notifier pour téléchargement et installation » pour reprendre la main manuellement.

Serveurs isolés

Téléchargez l’utilitaire Show or hide updates. Lancez l’assistant › Hide updates › cochez KB5036899 › Suivant. Une fois masqué, Windows Update l’ignore.

Analyse et contournements avancés

Redémarrage ciblé des services

Lorsque la suppression du patch est proscrite (contrats SLA, disponibilité 24/7), relancez seulement la chaîne de dépendances :

sc queryex type= service state= inactive | findstr /R /C:"SERVICE_NAME.*<NomService>"

Puis :

net start <NomServiceParent>

Mise à jour de la pile de maintenance (SSU)

La SSU KB5037016 inclut une amélioration de la logique de référencement des binaires dans WinSxS. Installez‑la isolément :

wusa.exe Windows10.0-KB5037016-x64.msu /quiet /norestart

Réparation du magasin de composants

Si DISM /RestoreHealth retourne Erreur 0x800f081f, copiez le dossier SxS d’une machine saine et spécifiez‑le :

DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\SxS /LimitAccess

Services tiers sensibles

Les produits MiVoice Connect et certains agents de supervision lancent leurs services sous des comptes « Network Service » dépendant de nsi. Après KB5036899, nsi échoue à cause d’un retard de RpcSs. Un délai (*DelayedAutoStart*) peut sauver la situation :

sc config "MiVoiceService" start= delayed-auto

Sécurité et conformité

Désinstaller un cumulatif rend le système vulnérable à toutes les CVE corrigées dans le lot d’avril 2024, notamment CVE‑2024‑29988 (élévation de privilèges Win32K). Atténuez :

Renforcement du pare‑feu : blocage des flux SMB, RDP non chiffrés, LDAP 389 exposé.
Limitation des comptes à privilèges élevés : implémentez la stratégie Protected Users.
Mise à jour de Microsoft Defender for Endpoint (mpcmdrun -SignatureUpdate) et configuration du mode bloc ASR.

Surveillance et gouvernance

Le correctif cumulatif de mai 2024 (KB5036972) n’incluait pas de rectification de l’erreur 1068. Une révision est attendue dans la Cumulative Preview d’août. Surveillez :

Notes de version officielles (Windows Server 2016 update history).
Canal MSRC pour les mises à jour hors bande (OOB).
Flux RSS « Known Issues » de Windows.

Script PowerShell de détection

Le script suivant recense les serveurs sous OU « Production » n’ayant pas KB5036899 et collecte les services en échec :

Import-Module ActiveDirectory
$servers = Get-ADComputer -Filter {OperatingSystem -like "Windows Server*2016*"} -SearchBase "OU=Production,DC=contoso,DC=local"
foreach ($srv in $servers) {
    if (-not (Get-HotFix -ComputerName $srv.Name -Id KB5036899 -ErrorAction SilentlyContinue)) {
        Get-WinEvent -ComputerName $srv.Name -FilterHashtable @{LogName='System';ID=7000,7001} |
          Select-Object @{n='Computer';e={$srv.Name}}, TimeCreated, Message
    }
}

Foire aux questions (FAQ)

Q : Puis‑je appliquer uniquement l’ESU de sécurité ?
R : Non ; Windows Server 2016 ne dispose pas d’ESU distinct. Les correctifs de sécurité sont inclus dans les cumulatives.
Q : Le problème concerne‑t‑il toutes les éditions ?
R : Oui, Standard et Datacenter sont affectées. L’édition Core l’est également.
Q : Les clusters Hyper‑V sont‑ils vulnérables ?
R : Rien n’indique une défaillance de clussvc. Toutefois, un nœud dont les services réseau ne démarrent pas peut être éjecté du cluster.
Q : Peut‑on injecter KB5036899 dans une image WIM ?
R : Il est déconseillé d’intégrer un correctif problématique ; préférez une image RTM + SSU + dernières cumulatives validées.

Bonnes pratiques de déploiement

La mise à jour en anneaux (ring deployment) limite l’impact :

Ring 0 : lab virtuel isolé ; prise de cliché instantané avant patch.
Ring 1 : serveurs pilotes hors production (systèmes non critiques).
Ring 2 : 10 % des serveurs applicatifs ; surveillance renforcée durant 48 h.
Ring 3 : production complète.

Utilisez Azure Update Management ou Endpoint Configuration Manager pour automatiser la progression conditionnelle des anneaux.

Conclusion

L’erreur 1068 rencontrée après l’installation de KB5036899 représente un cas classique de régression introduite par un cumulatif. La stratégie gagnante combine une désinstallation rapide, un gel temporaire des mises à jour et une analyse minutieuse des dépendances de services. En appliquant les procédures détaillées ci‑dessus — y compris la mise à jour de la SSU, la réparation des fichiers système et le déploiement en anneaux — vous rétablissez la disponibilité des services tout en maintenant une posture de sécurité robuste. Restez vigilant aux bulletins officiels : Microsoft publie fréquemment des correctifs hors bande une fois le problème confirmé. L’automatisation du suivi via PowerShell et la centralisation des journaux d’événements permettront d’anticiper toute récidive lors de futurs Patch Tuesday.

Correctif KB5036899 : résoudre l’erreur 1068 des services Windows Server 2016