Dans cet article, j'aimerais vous en dire un peu plus sur les instantanés Active Directory, et vous expliquer comment vous pouvez (ou ne pouvez pas) les utiliser.

« Avant toute chose, mettons les choses au clair : les instantanés de machine virtuelle des contrôleurs de domaine ne sont pas pris en charge ! »

Je le répète : si vous disposez d'un contrôleur de domaine virtualisé et que vous envisagez de créer un instantané de cette machine virtuelle à partir de votre hôte (Hyper-V, VMware ou tout autre fournisseur de cloud public), arrêtez tout de suite !

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 créez pas et n'utilisez pas d'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.

Voyons maintenant un peu 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 !

Imaginons donc que notre DC1 ait un USN maximal engagé de 5 000 et que notre DC2 ait un USN maximal engagé de 6 000. (Pour reprendre l'exemple des agents de sécurité, l'agent n° 1 a compté 5 000 personnes à l'entrée et l'agent 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

Donc, si on reprend l'exemple des agents de sécurité, cela signifie qu'à un moment donné, ils s'appellent pour se dire : « Salut, j'ai compté 5 000 personnes, voici leurs noms », et l'autre répond : « Super, j'en ai compté 6 000, voici leurs noms. »

Voyons maintenant ce qui se passe lors d'une restauration à partir d'un instantané (retour en arrière du serveur dans le temps).

Imaginons que l'on restaure DC1 à un instant où son USN validé le plus élevé était de 3 000. Or, n'oublions pas que la table de vecteurs UTD sur DC2 conserve toujours la valeur de l'USN validé le plus élevé de DC1, à savoir 5 000. Lorsqu'ils tentent de répliquer, DC1 indique : « J'ai des modifications jusqu'à 3 000. » DC2 « le regarde d’un air perplexe » et répond : « Mais la dernière fois que nous avons effectué la réplication, tu avais des modifications jusqu’à 5 000. Qu’est-ce qui ne va pas ? ».

Un exemple avec des agents de sécurité ? Après ce premier coup de fil, il y en a un autre où l'agent de sécurité n° 1 dit : « Salut, j'ai compté 3 000 personnes. » Et la réponse de l'agent de sécurité n° 2 ? « La dernière fois qu'on s'est parlé, tu disais en avoir compté 5 000. Qu'est-ce qui cloche ? »

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 effectuez une restauration à l'aide d'une méthode prise en charge, le processus de restauration modifie en réalité la manière dont le contrôleur de domaine apparaît dans la table du vecteur de mise à jour, en modifiant le GUID de la base de données (également appelé « InvocationID »). Les entrées du vecteur de mise à jour ne correspondent pas en réalité aux noms des contrôleurs de domaine, mais plutôt aux GUID des bases de données des contrôleurs de domaine faisant l'objet d'une réplication 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 contrôleur de domaine (DC) est rétabli à l'aide d'une méthode prise en charge, le GUID de la base de données est modifié ; par conséquent, le DC2 sait qu'il n'est désormais plus répliqué avec le DC1, mais avec le DC1a (qui conserve le même nom d'ordinateur, le même GUID de serveur, etc., mais dispose d'une base de données AD différente, ce qui est déterminant pour la réplication).

Dans ce cas de figure, c'est donc comme si DC2 avait commencé à se répliquer avec un tout nouveau contrôleur de domaine ; il n'y a donc pas de retour en arrière de l'USN.

Voilà pourquoi les « Snapshots » 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.