J'ai réfléchi à cela pendant quelques heures aujourd'hui. C'est un peu perplexe, mais comme je l'ai indiqué dans mon commentaire, ma meilleure supposition est que vous avez une sorte de mise en cache du disque en cours qui n'est pas validée sur le disque avant que la panne de courant / l'arrêt sale n'efface le contenu du cache ... Ou, étant donné que vous utilisez un volume RAID hébergeant ntds.dit, la panne de courant peut provoquer une interruption ou une incohérence temporaire de votre volume RAID, ne serait-ce qu'un instant.
Nous savons que la ligne de parti sur les restaurations USN se produit lorsqu'un contrôleur de domaine est restauré dans un état tel qu'il était auparavant, l'exemple classique étant la restauration d'un contrôleur de domaine virtualisé à partir d'un instantané. Je sais que cela ne s'applique pas exactement à vous ... mais même dans le cas d'un disque avec un cache d'écriture, vous pouvez penser que les données qui se trouvent physiquement sur le disque contiennent un "état précédent", tandis que le cache d'écriture est ce qui contient en fait l'état le plus à jour du DC ... même si les deux états ne sont séparés que par une demi-seconde.
Ruminate sur ces commentaires de Microsoft:
Instructions pour les contrôleurs de domaine virtualisés
Les disques SCSI virtuels offrent des performances accrues par rapport à l'IDE virtuel et prennent en charge l'accès forcé aux unités (FUA). FUA garantit que le système d'exploitation écrit et lit les données directement à partir du support en contournant tous les mécanismes de mise en cache.
Je sais que votre DC n'est pas une VM, mais le concept s'applique toujours. La mise en cache du disque et les contrôleurs de domaine ne se mélangent pas. C'est pourquoi l'installation d'Active Directory désactive la mise en cache d'écriture en tant que stratégie Windows, mais vous pouvez toujours avoir des mécanismes de mise en cache dans votre contrôleur RAID matériel, etc.
Scénario B: démarrage d'Active Directory à partir d'autres lecteurs dans un miroir cassé
Promouvoir un contrôleur de domaine. Recherchez le fichier Ntds.dit sur un lecteur en miroir.
Brisez le miroir.
Continuez la réplication entrante et la réplication sortante à l'aide du fichier Ntds.dit sur le premier lecteur du miroir.
Démarrez le contrôleur de domaine en utilisant le fichier Ntds.dit sur le deuxième lecteur dans le miroir.
C'est un tueur de réplication qui m'a beaucoup mordu sur les contrôleurs de domaine physiques avec des volumes RAID 1. Personnellement, je n'ai jamais eu de retour en arrière de l'USN, mais cela tuera la réplication sur ce contrôleur de domaine. Je veux dire, imaginez un volume RAID 1 de 2 disques. 1 lecteur meurt. Vous le supprimez, insérez un nouveau lecteur ... aaaaaaand DSA Not Writable.
Depuis le blog AskDS :
Si vous ne disposez pas d'alimentations sans coupure (UPS) pour vos hôtes VM ou le disque de stockage où réside la base de données Active Directory, assurez-vous que la mise en cache en écriture est désactivée sur l'ordinateur hôte de la machine virtuelle. Veuillez consulter ce lien pour obtenir des conseils supplémentaires. Inversement, si la mise en cache d'écriture doit rester activée pour l'hôte VM qui héberge le contrôleur de domaine, installez un onduleur pour éviter d'endommager le ou les contrôleurs de domaine.
Encore une fois, il s'agit de contrôleurs de domaine virtualisés, mais le concept de mise en cache de disque s'applique également aux contrôleurs de domaine physiques.
Voilà donc mon idée. Je pense que cela a quelque chose à voir avec votre système de stockage. Vous voulez certainement désactiver tous les mécanismes de mise en cache au moins sur le volume ntds.dit, surtout si vous êtes sujet à des pannes de courant.