Contexte
Suite à la restauration d’un snapshot ou d’une sauvegarde d’un contrôleur de domaine virtuel, l’erreur USN Rollback peut apparaître.
L’USN (Update Sequence Number) permet un versionning des objets utilisé par l’annuaire Active Directory, chaque modification d’un objet AD depuis un contrôleur de domaine va incrémenter le numéro USN de l’objet. En comparant entre les différents DCs leur numéro d’USN il est possible de déterminer quelle base est la plus à jour.
Lors d’une restauration d’un DC virtuel, et si l’outil de sauvegarde utilisé ne supporte pas la restauration Active Directory, il est probable qu’une erreur USN soit provoquée.
Les autres contrôleurs de domaine – en comparant leur numéro USN – vont détecter le DC restauré comme n’étant pas à jour en ne répliqueront pas avec lui.
Eviter l’USN Rollback
Les solutions suivantes permettent d’éviter une situation d’USN Rollback :
- Utiliser une solution de sauvegarde avec prise en charge de l’AD,
- Ne pas restaurer des backup dont la date excède le “Tombstone lifetime” qui est de 60 jours par défaut,
- Utiliser un contrôleur de domaine virtuel sous Windows Server 2012 ou ultérieur. Windows Server 2012 ajoute au contrôleurs de domaine un attribut supplémentaire (qui est géré par Hyper-V 2012) et qui évite l’USN rollback lors de la restauration d’un snapshot.
Symptômes de l’USN Rollback
- La commande ”repadmin /showutdvec” retourne de différents numéros d’USN,
- Le service NETLOGON est en pause,
- La valeur de la clé “DSA Not Writable” est à “4”,
- Les erreurs 2095 (NTDS Replication), 2013 (NTDS General), 2103 (USN Rollback),
- Les réplication entrantes/sortantes sont désactivées (visible à l’aide de la commande repadmin /showrepl ),
Résolution
Microsoft préconise (après l’apparition d’un USN Rollback) de retirer le contrôleur de domaine défaillant, après avoir transféré les éventuels rôles FSMO qu’il héberge (NTDSUtil permet de transférer les rôles ou de les saisir s’il est impossible de les transférer correctement).
Egalement dans le cas où la de-promotion du contrôleur de domaine ne se passe pas correctement, il faudra s’aider du switch “/forceremoval” de al commande DCPromo. Il faudra aussi bien penser à nettoyer les métadonnées du contrôleur de domaine défaillant, depuis un contrôleur de domaine fonctionnel.
L’idéal est – lorsque l’on souhaite restaurer le snapshot d’un contrôleur de domaine alors que le snapshot ne supporte pas la VM-GenerationID – de démarrer le contrôleur de domaine directement en mode DSRM. Une fois démarré en mode DSRM, mettre la valeur de registre “database restored from backup” à “1”.
Si le contrôleur de domaine a déjà été démarré en mode “normal”, il faudra le retirer (après avoir pris soin de récupérer les rôles hébergés).