Dans ce billet, j'aimerais expliquer un peu plus en détail les snapshots Active Directory, et comment vous pouvez ou ne pouvez pas les utiliser.

Tout d'abord, une chose doit être claire : les instantanés de VM des contrôleurs de domaine ne sont pas pris en charge !

Si vous avez un contrôleur de domaine virtualisé et que vous envisagez de prendre un instantané de cette VM à partir de votre hôte (Hyper-V, VMWare ou n'importe quel fournisseur de cloud public), arrêtez-vous !

Vous pouvez lire ici la déclaration officielle de Microsoft http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(WS.10).aspx

Ne pas prendre ou utiliser un instantané d'un contrôleur de domaine virtuel.

Il en va de même pour la copie du disque dur virtuel d'un contrôleur de domaine, l'utilisation de disques de différenciation ou toute autre fonction non encore inventée permettant de faire remonter la VM elle-même dans le temps sans utiliser une méthode de sauvegarde et de restauration prise en charge.

Parlons maintenant un peu du pourquoi.

Lorsque les contrôleurs de domaine se répliquent, ils utilisent un mécanisme appelé vecteur de mise à jour afin de suivre les changements répliqués.

Supposons que nous ayons deux contrôleurs de domaine DC1 et DC2, tous deux dans le domaine corp.contoso.com. Chacun de ces contrôleurs de domaine dispose d'un numéro de séquence de mise à jour (USN) local qui suit les modifications apportées à la base de données locale. Ces USN sont locaux et ne sont pas répliqués (ils sont donc différents entre les deux contrôleurs de domaine).

Pensez aux USN comme à des compteurs qui comptent les changements effectués sur chaque DC localement. Un exemple concret pourrait être un garde de sécurité à l'entrée d'un concert qui compterait les personnes qui entrent. Imaginons maintenant que ce concert ait deux portes, avec deux agents de sécurité. Le nombre serait-il le même ? Certainement pas !

Disons donc que notre DC1 a un USN le plus élevé de 5000, et que le DC2 a un USN le plus élevé de 6000. (pour revenir à l'exemple des agents de sécurité, l'agent de sécurité n° 1 a compté 5 000 entrées et l'agent de sécurité n° 2 en a compté 6 000).

Quel est donc le rapport avec le vecteur de mise à jour ? Eh bien, le vecteur UTD conserve une liste locale sur chaque DC de ce qui a été l'USN le plus élevé lors de la tentative de réplication précédente. Ainsi, si nous déclenchons la réplication dans l'état actuel, le vecteur UTD du DC1 affichera, une fois la réplication terminée avec succès, la mention suivante : "UTD vector" (vecteur de mise à jour) :

DC2 6000

Et le vecteur UTD sur le DC2 apparaîtrait :

DC1 5000

Note : vous pouvez afficher le vecteur de mise à jour en utilisant la commande repadmin :

Repadmin /showutdvec DCName PartitionDN

Si nous reprenons l'exemple des agents de sécurité, cela signifie qu'à un moment donné, ils s'appellent l'un l'autre en disant : "Hé, j'ai compté jusqu'à 5 000 personnes", voici leurs noms, et l'autre dit : "Super, j'ai compté jusqu'à 6 000, voici leurs noms" : Super, j'ai compté jusqu'à 6000 personnes, voici leurs noms.

Examinons maintenant ce qui se passe lors d'une récupération d'un instantané (retour en arrière du serveur).

Supposons que nous récupérions DC1 à un moment où son USN le plus élevé était de 3000. Souvenez-vous que la table des vecteurs UTD de DC2 contient toujours la valeur de l'USN le plus élevé de DC1, à savoir 5000. Lorsqu'ils essaient de répliquer, DC1 dit : "Hé, j'ai des changements jusqu'à 3000". DC2 le regarde bizarrement et lui dit : "Mais la dernière fois que nous avons répliqué, tu avais des changements jusqu'à 5000′, qu'est-ce qui ne va pas ?

Exemple des agents de sécurité ? Après ce premier appel téléphonique, il y a un autre appel téléphonique où l'agent de sécurité n°1 dit 'Hey, j'ai compté jusqu'à 3000 personnes', la réponse de l'agent de sécurité n°2 ? La dernière fois que nous nous sommes parlés, tu as dit que tu avais compté jusqu'à 5000 personnes, qu'est-ce qui ne va pas ?

Vous voyez le problème ?

Cette situation est appelée "USN rollback" et, à ce moment-là, les DC ont cessé de se parler et de répliquer toute information.

Comment résoudre ce problème ?

Lorsque vous restaurez à l'aide d'une méthode prise en charge, le processus de restauration modifie en fait la façon dont le contrôleur de domaine apparaît dans le tableau du vecteur de mise à jour, en changeant le GUID de la base de données (également appelé InvocationID). Les entrées du vecteur de mise à jour ne sont pas réellement des noms de DC, mais plutôt les GUID de base de données des contrôleurs de domaine répliqués pour le contexte de nommage spécifique.

Remarque : l'exécution de Repadmin /showutdvec DCName PartitionDN /nocache affichera les GUID mentionnés.

Ainsi, lorsqu'un DC est restauré à l'aide d'une méthode prise en charge, le GUID de la base de données est modifié, ce qui permet à DC2 de savoir qu'il n'est plus répliqué avec DC1, mais avec DC1a (qui a toujours le même nom d'ordinateur, le même GUID de serveur, etc. mais qui a une base de données AD différente, ce qui est important pour la réplication).

Ainsi, dans ce scénario, c'est comme si DC2 avait commencé à répliquer avec un tout nouveau contrôleur de domaine, de sorte qu'aucun rollback USN ne se produit.

Voilà l'explication complète de la raison pour laquelle les instantanés ne sont pas pris en charge !

Ceci étant dit, qu'est-ce qu'un bon cliché ?

Les bons instantanés sont ceux réalisés à l'aide de la commande ntdsutil, qui utilise VSS sous le capot pour créer un instantané de la base de données Active Directory. Ces snapshots ne peuvent pas être utilisés pour restaurer la base de données (pour exactement la même raison que celle expliquée ci-dessus), mais ils peuvent être montés, inspectés, et certaines informations peuvent en être extraites, et insérées dans la base de données de production par des outils tels que ldifde.exe et d'autres, mais nous reviendrons plus en détail sur les snapshots AD dans des articles ultérieurs.

Un point important à retenir de cet article. Utilisez la sauvegarde de l'état du système pour sauvegarder vos contrôleurs de domaine et assurez-vous de savoir comment restaurer à partir de cette sauvegarde dans tous les scénarios possibles.