Windows Server 2022 : corriger le blocage « Waiting NTDS » au démarrage (Active Directory)

Un contrôleur de domaine Windows Server 2022 reste bloqué sur « Waiting NTDS » puis démarre en mode sans échec ? Voici un guide terrain, détaillé et actionnable, pour diagnostiquer, réparer AD DS et restaurer un démarrage normal, sans données perdues.

Sommaire

Vue d’ensemble et symptômes

« Waiting NTDS » indique que le service Active Directory Domain Services (NTDS) ne parvient pas à se charger assez tôt au démarrage. Sur un second DC, le phénomène est souvent déclenché par une dépendance indirecte — DNS, temps/NTP, réplication SYSVOL, base NTDS, disque — plutôt que par Windows lui‑même. Les signes les plus fréquents :

Démarrage ralenti : écran « Waiting NTDS » ≈ 30 s, puis bascule en mode sans échec ou ouverture de session très tardive.
Événements Directory Service/DFSR/Netlogon en erreur (ex. échec de montage de la base, réplication gelée après un arrêt brutal, résolution DNS SRV manquante).
Résolution DNS incohérente, horloge dérivant de plus de 5 minutes vis‑à‑vis du PDC, ou volume NTDS saturé (< 20 % d’espace libre).

Procédure express

Si vous devez remettre le DC sur pied rapidement (sans tout réparer d’un coup), exécutez ces actions prioritaires :

DNS : sur le DC en panne, fixez le DNS primaire sur l’adresse IP du PDC (et le secondaire sur un autre DC sain). Redémarrez le service DNS Client : Restart-Service Dnscache.
Temps/NTP : resynchronisez immédiatement : w32tm /config /syncfromflags:domhier /update puis w32tm /resync /force.
Démarrage normal forcé si le serveur boucle en mode sans échec : bcdedit /deletevalue {current} safeboot et redémarrage.
Vérification rapide AD : dcdiag /v /c /e /fix > C:\temp\dcdiag.txt, repadmin /replsummary. Lisez les erreurs majeures et corrigez d’abord DNS et DFSR/SYSVOL.

Tableau de résolution pas‑à‑pas

Étape	Objectif	Commandes/outils clés	Commentaires utiles
Vérifier la connectivité réseau	S’assurer que le DC problématique peut joindre le contrôleur principal (PDC), le DNS, le catalogue global, etc.	`ping`, `nslookup`, `Test-Connection`, test de ports 389/636/3268	Un DNS ou routage incorrect retarde NTDS au boot.
Consulter les journaux d’événements	Trouver des erreurs NTDS, Netlogon, AD WS, DFS R, volsnap	Observateur d’événements → Journaux Système & Service Directory	Notez l’ID d’événement et la source pour cibler la recherche.
Démarrer en « Directory Services Repair Mode » (DSRM)	Travailler hors ligne sur la base AD	Au boot : menu de récupération → « Active Directory Repair »	Connectez‑vous avec le mot de passe DSRM.
Tester la santé AD	Diagnostics de réplication, noms, rôles FSMO	`dcdiag /v /c /e /fix`, `repadmin /replsummary`	Repérez les messages « failed test KCC », « failed test FrsEvent », etc.
Analyser / réparer la base NTDS	Vérifier son intégrité, défragmenter, ressusciter d’un backup	`ntdsutil` → `files` → `integrity`, `semantic database analysis`, `compact to <chemin_temp>`	Un `ntds.dit` corrompu explique souvent le blocage.
Vérifier et réparer les fichiers système	Écarter un OS corrompu	`sfc /scannow`, `DISM /Online /Cleanup-Image /RestoreHealth`	Exécuter depuis un invite admin ou WinRE.
Valider le service Netlogon	Indispensable au chargement NTDS	`sc query netlogon`, `net start netlogon`	S’il échoue, inspecter la résolution DNS SRV.
Restaurer ou recréer le DC (en dernier recours)	Revenir à un état sain	Restauration autoritaire/non autoritaire ; démotion forcée + nettoyage des métadonnées puis promotion propre	Toujours vérifier la cohérence des rôles FSMO après coup.
Exclure un défaut matériel	RAM, disque, contrôleur RAID	`chkdsk /f`, tests SMART, diagnostics constructeur	Une panne de disque système ralentit la lecture de `ntds.dit`.

Étapes détaillées et commandes

Connectivité, DNS et NTP : les trois pivots

DNS : sur un DC secondaire, configurez temporairement le DNS primaire vers le PDC (et un autre DC sain en secondaire). Vérifiez ensuite les enregistrements SRV et le catalogue global.

ipconfig /all
# Exemple PowerShell (adapter l’alias d’interface et les IP) :
Get-DnsClientServerAddress -AddressFamily IPv4
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.0.0.10,10.0.0.11

# Validation SRV :

nslookup -type=SRV _ldap._tcp.dc._msdcs.votre-domaine.local
nslookup -type=SRV _gc._tcp.votre-domaine.local

# Ports critiques :

# LDAP 389, LDAPS 636, GC 3268/3269, DNS 53, Kerberos 88, RPC 135 + ports dynamiques 49152–65535.

Test-NetConnection -ComputerName PDC01 -Port 389
Test-NetConnection -ComputerName PDC01 -Port 3268

Temps/NTP : une dérive > 5 minutes casse Kerberos et retarde fortement NTDS.

w32tm /query /status
w32tm /config /syncfromflags:domhier /update
w32tm /resync /force

Sur le PDC Emulator, assurez‑vous d’une source NTP externe fiable puis laissez les autres DC se synchroniser via la hiérarchie de domaine.

Observer les journaux essentiels

Ouvrez l’Observateur d’événements et ciblez en priorité :

Directory Service : erreurs de montage de la base, KCC, réplication AD.
DFS Replication : blocage de la réplication SYSVOL après arrêt brutal (p. ex. événement « service en état de récupération »), backlog élevé.
System : Netlogon, DNS Client/Server, volsnap, stockage.

Automatisez l’extraction :

# Rapport DCDIAG complet
dcdiag /v /c /e /fix > C:\temp\dcdiag.txt

# Synthèse réplication

repadmin /replsummary
repadmin /showrepl * /csv > C:\temp\repl.csv

# Liste des DC et rôles

nltest /dclist:votre-domaine.local
netdom query fsmo

Démarrer en DSRM sans écran

Sur les générations récentes, le menu F8 n’est pas toujours disponible. Utilisez bcdedit pour basculer en Directory Services Restore Mode :

# Activer un prochain boot en DSRM
bcdedit /set {current} safeboot dsrepair

# (Optionnel) consigner le boot

bcdedit /set {current} bootlog Yes

# Revenir ensuite en mode normal

bcdedit /deletevalue {current} safeboot

Connectez‑vous avec le mot de passe DSRM défini lors de la promotion du DC.

Réparer la base AD DS (NTDS)

En DSRM, la base est hors ligne : vous pouvez l’inspecter et la réparer. Sauvegardez d’abord les fichiers.

# Emplacement par défaut
# C:\Windows\NTDS\ntds.dit et journaux EDB*.log

# Copie de sécurité

mkdir C:\RepairNTDS
copy C:\Windows\NTDS* C:\RepairNTDS\

# NTDSUTIL & intégrité

ntdsutil
activate instance ntds
files
integrity
quit

# Analyse sémantique (répare certaines incohérences)

ntdsutil
activate instance ntds
semantic database analysis
go fixup
quit

# Défragmentation hors ligne (libère & reconstruit)

ntdsutil
activate instance ntds
files
compact to C:\RepairNTDS\Compact
quit

# (Dernier recours) Vérification bas niveau ESE

esentutl /g C:\Windows\NTDS\ntds.dit

# Ne lancez PAS /p sans sauvegarde et sans comprendre les implications.

Vérifiez l’espace libre du volume NTDS. Si une sauvegarde System State n’a pas tourné depuis longtemps, les journaux EDB ne se tronquent pas : réalisez immédiatement une sauvegarde pour débloquer la troncature.

# Sauvegarde System State (exemple vers E:)
wbadmin start systemstatebackup -backuptarget:E: -quiet

SYSVOL et DFS Replication

Sur Windows Server 2022, SYSVOL repose sur DFSR. Après une panne électrique ou un arrêt brutal, la réplication peut se mettre en pause « préventive ». Symptômes typiques : le DC n’« s’annonce » pas, Netlogon défaillant, GPO non appliquées.

Vérifiez l’état de DFSR et le backlog : Get-WinEvent sur le journal DFS Replication et dfsrdiag replstate.
Si DFSR est en pause suite à un « dirty shutdown », reprenez la réplication sur le ou les volumes concernés (commande d’administration DFSR), puis forcez une sonde d’AD : dfsrdiag pollad.
Validez que C:\Windows\SYSVOL\domain est partagé et identique entre DC : net share, comparaisons de dossiers, et observateur d’événements sans erreurs DFSR.

Si la topologie DFSR est incohérente ou si la réplication ne repart pas, envisagez une réinitialisation contrôlée de SYSVOL (non destructive) en suivant un plan de reprise : déclarer un DC de référence, réinitialiser la base DFSR et resynchroniser.

Netlogon, canaux sécurisés et SRV

Le service Netlogon doit publier les enregistrements SRV et établir le canal sécurisé. Assurez‑vous qu’il est démarré et qu’il peut publier dans le DNS.

sc query netlogon
net start netlogon

# Vérifier/rafraîchir le canal sécurisé

Test-ComputerSecureChannel
Test-ComputerSecureChannel -Repair -Credential "votre-domaine\Administrateur"

# Re‑publication des enregistrements SRV

nltest /dsregdns </code></pre>

<h3>Réparer Windows si nécessaire</h3>
<p>Écartez une corruption système avant d’incriminer AD&nbsp;:</p>
<pre><code>sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

# Vérification disque & redémarrage

chkdsk C: /f </code></pre>

<h3>Forcer un retour en démarrage normal</h3>
<p>Certains serveurs restent en mode sans échec parce que l’option <code>safeboot</code> est restée active dans le BCD. Assurez‑vous de l’effacer, puis redémarrez.</p>
<pre><code>bcdedit /deletevalue {current} safeboot
shutdown /r /t 0
</code></pre>

<h3>Dernier recours&nbsp;: restauration ou reconstruction du DC</h3>
<p>Quand la base est irrécupérable ou que la réplication a divergé durablement, vous avez deux voies :</p>
<h4>Restauration du System State</h4>
<ul>
  <li><strong>Non autoritaire</strong>&nbsp;: vous restaurez l’état système du DC, puis laissez la réplication le remettre à jour (recommandé si un autre DC sain existe).</li>
  <li><strong>Autoritaire</strong>&nbsp;: vous marquez certaines partitions (ou des objets) comme faisant autorité (<code>ntdsutil authoritative restore</code>) lorsque vous devez imposer leur version restaurée au reste de l’environnement.</li>
</ul>

<h4>Reconstruction propre</h4>
<ol>
  <li><strong>Démotion forcée</strong> (le DC est isolé et ne peut pas contacter les autres)&nbsp;:
    <pre><code>Uninstall-ADDSDomainController -ForceRemoval `
  -LocalAdministratorPassword (Read-Host -AsSecureString "Mot de passe admin local") `
  -Force
</code></pre>
  </li>
  <li><strong>Nettoyage des métadonnées</strong> (depuis un DC sain)&nbsp;: supprimez l’ancien contrôleur de domaine d’AD&nbsp;DS (objet serveur et <em>NTDS Settings</em>) et purgez ses enregistrements DNS. Vous pouvez utiliser la console <em>Sites et Services AD</em> ou&nbsp;:
    <pre><code>ntdsutil
metadata cleanup
connections
connect to server PDC01
quit
select operation target
list domains
select domain &lt;ID&gt;
list sites
select site &lt;ID&gt;
list servers in site
select server &lt;ID&gt;
quit
remove selected server
quit

<p>Ensuite, supprimez ses enregistrements A/AAAA et SRV associés dans la zone DNS du domaine.</p>

Promotion fraîche : réinstallez les rôles AD DS/DNS, puis promouvez ce serveur en DC. Après promotion, vérifiez la réplication et le statut de catalogue global.

Arbre de décision rapide

Symptôme	Cause la plus probable	Action immédiate	Validation
« Waiting NTDS » puis mode sans échec	DNS primaire mal pointé ou temps en dérive	Basculer DNS primaire vers PDC, resync NTP	`Resolve-DnsName` SRV OK, `w32tm /query /status` OK
SYSVOL non partagé	DFSR en pause après arrêt brutal	Reprendre la réplication DFSR, forcer `dfsrdiag pollad`	Journal DFSR propre, `net share` affiche SYSVOL
Erreurs NTDS au montage	Base `ntds.dit` corrompue	DSRM → `ntdsutil` integrity/compact	Démarrage normal, `repadmin` sans échecs
Journaux EDB volumineux	Absence de sauvegarde System State	Lancer une sauvegarde System State	Troncature des logs, espace libéré
Échecs Netlogon	SRV non publiés, canal sécurisé rompu	`nltest /dsregdns`, `Test-ComputerSecureChannel -Repair`	SRV présents, netlogon démarré
Lenteurs disque/erreurs volsnap	Stockage défaillant ou saturé	`chkdsk /f`, vérifier SMART/RAID	Événements Système stables

Contrôles et remédiations détaillés

Configuration DNS recommandée sur les DC

Chaque DC doit pouvoir se résoudre lui‑même et au moins un autre DC. Pendant un incident, privilégiez le PDC en DNS primaire pour accélérer la découverte.
Activez la scavenging DNS pour éviter les enregistrements obsolètes (hors incident).
Validez les délégations et zones intégrées à AD (réplication correcte sur tous les DC DNS).

Réplication AD DS

Une réplication bloquée entraîne des arborescences de nom ou des rôles FSMO incohérents, ce qui retarde le montage de NTDS.

# Résumé et latence
repadmin /replsummary

# Détails par partenaire

repadmin /showrepl 

# Forcer la réplication entrante

repadmin /syncall /AdeP

Rôles FSMO et catalogue global

Le second DC dépend souvent du PDC pour Kerberos/NTP et du catalogue global pour certaines requêtes. Vérifiez la localisation des rôles et du GC :

netdom query fsmo
# Activer GC si nécessaire (via Sites et Services AD)

Assainir les enregistrements DNS SRV

Les dossiers _msdcs, _sites, _tcp, _udp doivent contenir les SRV des DC actifs. Supprimez les SRV d’un ancien DC retiré et republiez ceux du DC réparé :

ipconfig /registerdns
nltest /dsregdns

Vérifications matérielles et stockage

La base NTDS est sensible aux latences disque. Vérifiez l’intégrité du stockage et l’état SMART, ainsi que l’IOPS des volumes NTDS et SYSVOL. Sur Windows Server, vous pouvez interroger les compteurs de fiabilité du disque :

# Vue synthétique (si Storage Spaces)
Get-PhysicalDisk | Get-StorageReliabilityCounter | Select-Object *

Checklist post‑incident

Réplication : repadmin /showrepl sans échec et latence raisonnable ; repadmin /replsummary propre.
SYSVOL partagé et GPO appliquées (gpupdate /force sur un poste test, suivi d’un gpresult /r).
DNS : zones intégrées à AD en bonne santé, SRV à jour.
NTP : w32tm /query /status OK sur chaque DC.
Rôles FSMO : netdom query fsmo renvoie les propriétaires attendus.
Sauvegardes : planifiez des sauvegardes System State quotidiennes et testez une restauration de laboratoire.

FAQ pratique

Faut‑il que le DC pointe d’abord sur lui‑même en DNS ?
En régime stable, oui, à condition d’avoir un secondaire vers un autre DC. Pendant un incident, pointer le primaire vers le PDC accélère la découverte et évite « Waiting NTDS ».

Comment savoir si le serveur démarre en mode sans échec à cause d’un paramètre restant ?
Exécutez bcdedit et vérifiez l’absence de safeboot. S’il existe, supprimez‑le.

Quand utiliser une restauration autoritaire ?
Quand vous devez imposer la version restaurée d’un sous‑ensemble AD (ex. OU supprimée avec ses objets) au reste de la forêt. Dans la majorité des pannes de démarrage, une restauration non autoritaire suffit.

Bonnes pratiques de prévention

DNS & NTP prioritaires : verrouillez la configuration DNS des DC et synchronisez l’horloge du PDC sur une source fiable. Une dérive > 5 min bloque Kerberos.
Sauvegardes System State quotidiennes : elles permettent la troncature des journaux EDB et une restauration rapide (Windows Server Backup ou solution tierce).
Espace disque : maintenez au moins 20 % d’espace libre sur le volume NTDS.
Supervision : alertez sur événements Directory Service/DFSR, latence repadmin, âge de la dernière sauvegarde.
Test régulier de reprise : script « runbook » pour DSRM, ntdsutil, reprise DFSR, démotion/remontée d’un DC de labo.

Playbook récapitulatif

Basculer DNS primaire vers PDC → resynchroniser NTP → redémarrer.
Extraire dcdiag / repadmin → corriger DNS/SRV → vérifier Netlogon.
Si échec : DSRM → ntdsutil (integrity/compact) → vérifier espace disque et sauvegarde.
Rétablir SYSVOL/DFSR → dfsrdiag et journaux propres → gpupdate OK.
Toujours pas ? Restauration non autoritaire → sinon reconstruction (démotion forcée + metadata cleanup + promotion).

Exemples de blocs de commandes prêts à l’emploi

Diagnostic rapide

mkdir C:\temp -ErrorAction SilentlyContinue
dcdiag /v /c /e /fix &gt; C:\temp\dcdiag.txt
repadmin /replsummary &gt; C:\temp\replsummary.txt
repadmin /showrepl * /csv &gt; C:\temp\repl.csv
ipconfig /all &gt; C:\temp\network.txt
w32tm /query /status &gt; C:\temp\time.txt

Remédiation DFSR après arrêt brutal

# Forcer la détection de la configuration AD
dfsrdiag pollad

# Vérifier l’état des connexions

dfsrdiag replstate

# Si pause de réplication détectée, reprendre sur le volume SYSVOL

# (exécuter la commande d’administration adéquate pour reprendre la réplication sur le volume concerné)

Nettoyage BCD si le serveur boucle en mode sans échec

bcdedit /enum
bcdedit /deletevalue {current} safeboot
shutdown /r /t 0

Restauration System State (principes)

# Lister les versions disponibles
wbadmin get versions

# Restaurer la dernière version (exemple)

wbadmin start systemstaterecovery -version: -quiet

Conclusion

Le blocage « Waiting NTDS » est presque toujours le symptôme d’un prérequis défaillant (DNS/NTP/DFSR/stockage) ou d’une base NTDS altérée — rarement un « bug » Windows. En appliquant la séquence proposée (réseau → journaux → DSRM/NTDS → DFSR → restauration/reconstruction), vous rétablissez un démarrage normal de façon méthodique, tout en consolidant votre environnement Active Directory pour éviter les récidives.

Rappels utiles :

DNS & NTP prioritaires : un DC dont le DNS pointe uniquement sur lui‑même, sans seconde entrée « vivante », ou dont l’horloge dérive > 5 min du PDC se bloque souvent sur « Waiting NTDS ».
Sauvegardes System State : indispensables ; planifiez‑en quotidiennes.
Espace disque : réservez ≥ 20 % libres sur le volume contenant ntds.dit.
Surveillance post‑incident : après réparation, vérifiez la réplication (repadmin /showrepl) et les rôles FSMO, puis planifiez une tâche dcdiag /f:C:\temp\rapport.txt quotidienne.

Windows Server 2022 : corriger le blocage « Waiting NTDS » au démarrage (Active Directory)