Une des raisons évidente de la virtualisation est l'indépendance des machines virtuelles avec le hardware. Il est donc beaucoup plus simple de gérer le clone d'une VM (Virtual Machine) dans une infrastructure virtualisée.
Mais peut-on cloner n'importe quelle VM ?
La réponse à cette question n'est pas simple. La réponse la plus intelligente devrait être de dire comme bien souvent : "Ça dépend".
Jusqu'à la version 2012 de Windows Server, le clonage d'une VM hébergeant ADDS (Active Directory Domain Services) était à proscrire. En effet, en opérant un clone ou un restore d'un domain controller (avant la version 2012 windows server), on risquait à coup sûr de provoquer un "USN Rollback".
Un des bénéfices majeurs qu'apporte Microsoft à la version 2012 de sa version Server est le VM-GenerationID.
Ce numéro est un identifiant codé sur 128 bits fourni par l'hyperviseur à travers un driver spécifique.
On peut voir ici de quoi il s'agit en explorant le device manager d'une machine virtuelle hostée grâce à un hyperviseur Hyper-V tournant sur une machine Windows 8. Vous pouvez consulter ici comment a été montée cette infrastructure virtuelle.
Si vous voyez le device "Microsoft Hyper-V Generation Counter", votre hyperviseur va pouvoir gérer le VM-GenerationID et de ce fait, vous allez pouvoir cloner un Domain Controller.
Le VM-GenerationID est généré et enregistré sur le Domain Controller comme un attribut de la base Active Directory. Cet attribut n'est pas répliqué.
Le VM-GenerationID est enregistré dans la base NTDS.dit de l'ad sous la forme de l'attribut msDS-GenerationID.
Vous pouvez le voir en vous connectant sur le DC que vous voulez observer et en affichant ses attributs. On peut facilement le faire via l'ADAC ou l'ADUC.
1) Prérequis
Il y a des prérequis à respecter pour pouvoir cloner un DC.
- Comme on vient de le voir, votre hyperviseur doit supporter le VM-GenerationID. C'est le cas pour Hyper-V tournant pour Windows 8 mais également sur Windows Server 2012. VMWare dit le supporter, on y reviendra dans un futur article.
- Le DC source doit tourner sous Windows Server 2012
- Le DC source ne peut pas hoster le rôle PDC emulator. De plus, le DC hostant ce rôle doit être disponible et doit tourner sous Windows Server 2012.
Donc, si on compte bien, vous devez avoir au minimum deux DCs dans votre infrastructure pour pouvoir commencer le clonage d'un DC.
2) Préparation du DC source
Afin de cloner un DC, vous devez d'abord le préparer à être cloner. La première étape est d'ajouter votre DC source au groupe de sécurité "Cloneable Domain Controllers". Vous avez plusieurs options pour ça.
La première via l'ADAC ou même l'ADUC.
La deuxième façon de faire est de le faire via powershell.
Add-ADGroupMember "Cloneable Domain Controllers" "CN=DC02,OU=Domain Controllers,DC=LABO,DC=COM"
Ok, notre DC source est désormais membre du groupe de sécurité "Cloneable Domain Controllers". On va pouvoir continuer à le préparer.
Technet nous apprend qu'il y a lieu de lancer une première commande avant de commencer le processus de clonage. En effet, nous avons besoin de déterminer quels sont les programmes et services qui ne sont pas présent dans le fichier "DefaultDCCloneAllowList.xml" ou dans un fichier personnalisé par l'utilisateur "CustomDCCloneAllowList.xml" et de ce fait non supporté par le processus de clonage car non évalués.
Get-ADDCCloningExcludedApplicationList
Chez moi le résultat de la commande est net : "No excluded applications were detected". On peut donc avancer. Néanmoins, dans certains cas vous devrez lancer une seconde commande afin de générer votre propre fichier .xml contenant la liste des applications ou services que vous voulez ajouter car supportés.
Voici un exemple (lancée sur une infra tournant sous ESXi 5.1).
On lance donc une seconde commande afin de générer le fichier .xml
Get-ADDCCloningExcludedApplicationList -GenerateXml
On retrouve bien le fichier "CustomDCCloneAllowList.xml" sous "C:\Windows\NTDS\".
Pour terminer cette préparation, il ne nous reste qu'une seule commande à lancer.
New-ADDCCloneConfigFile -Static -IPv4Address "192.168.1.12" -IPv4DNSResolver "192.168.1.10" -IPv4SubnetMask "255.255.255.0" -CloneComputerName "DC03" -IPv4DefaultGateway "192.168.1.1" -SiteName "Default-First-Site-Name"
Cette commande va générer un nouveau fichier .xml : "DCCloneConfig.xml". Ici, on a spécifié le nom du futur DC cloné et sa configuration réseau.
Le DC cloné doit se trouver dans le même site.
Si on édite le fichier de la configuration de la machine virtuelle DC02
On retrouve bien le numéro "genreration_id" avec pour valeur hexadécimale "5683b796635a6015936e3117daa5b751".
La valeur définie pour l'attribut msDS-GenerationId est 51 B7 A5 DA 17 31 6E 93. En inversant la valeur trouvée dans le fichier xml de la machine virtuelle on retrouve bien la même valeur 936e3117daa5b751 -> 51b7a5da17316e93
3) Export de la VM préparée et import dans une nouvelle VM
Éteignons le DC DC02 qu'on vient de préparer.
Au niveau d'Hyper-V, sélectionner la VM à exporter (ici DC02) et choisissez l'option d'"Export..."
Il suffit ensuite de spécifier l'endroit où vous désirez exporter votre VM.
J'ai pour ma part créer un dossier Export sous le dossier Labo sur mon disque G:\ qui est en réalité un disque virtuel sur un Nas Synology.
Laissez ensuite l'export se dérouler et quand celui-ci sera terminé, vous pourrez voir l'arborescence que Hyper-V a créé pour vous.
Un .vhdx a bien été exporté.
Et le fichier de configuration .xml.
Ok, on peut passer à l'import. Sélectionner votre noeud et "Import Virtual Machine...".
Le processus d'importation ne comporte rien de particulier "Next >"
"Browse".
On sélectionne le dossier racine de la VM clonée, ici DC02.
"Next >".
Hyper-V détecte une VM. et "Next >" ;-)
On demande à Hyper-V de nous créer un nouvel ID. "Next >".
>Et on store la VM où on désire. "Next >"
Ainsi que l'emplacement du .vhdx. "Next >"
C'est terminé. Vous pouvez voir le review de l'importation. Cliquez sur "Finish".
Hyper-V commence le processus d'importation
Une fois l'importation terminée, si vous éditez le fichier de configuration .xml de la VM importée, vous pourrez observer que le generation_id a bien été modifié.
.xml de DC02
.xml de DC03 (VM importée)
On peut renommer notre VM, faites un clic droit sur la VM fraîchement importée et cliquez sur "Rename..."
C'est fait. Démarrez le DC02 et ensuite le DC03.
Démarrage de DC03...
Le DC a détecté qu'il était un clone, il commence donc le processus de clonage.
DC03 redémarre une fois.
On peut voir le nouveau DC dans Sites and Services.
On le voit bien aussi dans l'ADUC et l'ADAC.
Si on édite les propriétés du DC03 (DC résultant du clonage), on peut voir que le VM-GenerationID est bien différent du DC source DC02.
4) Processus détaillé du clonage
Technet nous explique parfaitement ce qu'il se passe lors du process de clonage. Voici le schéma édité par Microsoft pour expliquer celui-ci.
5) Le clonage s'est mal passé ?
Dans le cas où votre clonage s'est mal passé, le DC source va redémarré en mode DSRM. Vous devrez vous loguer en local et supprimé le flag relatif au mode DSRM avant de pouvoir relancer un clonage et après avoir corrigé l'erreur qui vous a empêché de cloner correctement le DC source.
Vous pouvez le faire de deux façons.
b) Si vous êtes en CORE, via le command shell
bcdedit.exe /deletevalue safeboot
6) Conclusion
Nous en avons terminé avec ce tutoriel.
Nous pouvons voir le grand intérêt de l'ajout du VM-GenerationID par Microsoft puisque cela nous ouvre également la voie au snapshot d'un AD.
En effet, précédemment ceci pouvait mener à des incohérences graves dans notre base AD comme le montre ce schéma (source).
Ce qui est désormais géré comme le montre le schéma suivant (source).
Aucun commentaire:
Enregistrer un commentaire