lundi 15 avril 2013

Active directory : récupération des rôles FSMO dans votre forêt par Powershell

Il existe bien évidemment plusieurs manières de récupérer l'information concernant l'emplacement de chacun des rôles FSMO de votre forêt.

J'aime bien éviter la façon manuelle, voici donc une petite fonction qui peut se révéler bien utile dans le cas où l'on vous demande où se situe vos rôles ;-)



function Get-FSMOPlacement {  

    Import-Module activedirectory                      

    $forestDomain = Get-ForestDomain 

    $forest = $forestDomain.forest
    $domain = $forestDomain.domain

    Write-Host "FSMO Roles" -ForegroundColor white -BackgroundColor Blue  

    $fsmoPlacement = New-Object PSObject -Property @{       
          "Schema master" = $forest.SchemaMaster
          "Domain naming master" = $forest.DomainNamingMaster
          "RID master" = $domain.RIDMaster
          "PDC emulator" = $domain.PDCEmulator  
          "Infrastructure master" = $domain.InfrastructureMaster  
    }   
    return $fsmoPlacement           
 }


L'utilisation est toute simple :



Get-FSMOPlacement

jeudi 28 mars 2013

MCSE 2012 Server Infrastructure

C'est officiel depuis ce matin 4:46 du matin et l'envoi du mail de confirmation de Microsoft.

Je suis désormais MCSE 2012 Server Infrastructure.

J'avais posté précédemment. la skills development roadmap qui permet de voir le chemin parcouru et les prérequis nécessaire à l'obtention de ce titre.


Je vais certainement revenir sur la dernière certification (Implementing an Advanced Server Infrastructure 70-414) afin d'exposer la manière dont je me suis préparé pour obtenir cette dernière.


lundi 11 mars 2013

Hyper-V 3 - Qu'est-ce que le "Smart Paging" ?

Hyper-V dans sa nouvelle version propose désormais une nouvelle fonctionnalité : Le Smart Paging.

Préambule : comprendre la mémoire dynamique dans Hyper-V

Pour bien comprendre à quoi le Smart Paging peut bien servir, il faut tout d'abord comprendre le fonctionnement de l'allocation de mémoire dans Hyper-V et plus particulièrement de la mémoire dynamique (ajouté par Microsoft depuis le release du SP1 de Windows Server 2008 R2 et Microsoft Hyper-V Server 2008 R2 SP1).

Pour voir tout ceci, direction les "Settings..." d'une machine virtuelle (VM).



Ok, cliquez sur "Memory". Voici donc l'écran en question.


Vous pouvez déjà vous rendre compte que, parmi les options de la mémoire dynamique, apparaît une nouvelle possibilité : Minimum RAM.

Mais rappelons d'abord brièvement l'utilité de chacune des options disponibles pour la mémoire dynamique.

1) Startup RAM : il s'agit de la quantité de mémoire RAM allouée par Hyper-V à la VM au démarrage. Cette quantité de RAM doit correspondre à la quantité de mémoire dont a besoin la VM pour démarrer.

2) Minimum RAM : il s'agit de la quantité minimum de mémoire RAM au-dessous de laquelle plus aucune mémoire ne pourra être libérée par Hyper-V sur la VM  C'est donc la mémoire minimale dont a besoin votre VM pour tourner. La suppression de RAM se fait par la technologie de "Ballooning" présente au sein de chaque VM.

3) Maximum RAM : c'est la mémoire maximale attribuable par Hyper-V à la VM. L'ajout de mémoire se fait par la technologie "HotAdd".

4) Memory Buffer : Il est basé sur le "Current Commit", autrement dit sur la mémoire allouée à l'instant t à la VM par Hyper-V. La valeur par défaut du Memory Buffer est paramétré à 20%.

Le Memory Buffer se calcule comme suit :


Memory Buffer(MB) = (1 / (1 - Memory buffer(%)) - 1) x Current Commit(MB)


L'objectif de ce Buffer est de permettre l'allocation très rapide de mémoire RAM supplémentaire lorsque la charge s’accroît sur la VM.  Le Memory Buffer est donc une zone sur chaque VM où est pré-allouée de la RAM. Lors d'une montée en charge, le Global Memory Object (GMO) tentera donc en premier lieu (dans un processus pouvant aller jusqu'à 4 étapes si nécessaire) de fournir la RAM nécessaire via ce Memory Buffer.

Ce Memory Buffer est borné à droite par la valeur Maximum RAM.

À retenir :
a) Vous définirez une valeur basse à cette zone tampon lorsque le logiciel fonctionnant à l'intérieur de la VM essaie d'utiliser autant de RAM que disponible. C'est typiquement le cas d'un serveur SQL.
b) Une valeur haute sera utilisée dans le cas où vous avez un process qui peut avoir besoin d'un système de cache fichier important ou bien dans le cas où une application demande fréquemment une importante quantité de RAM supplémentaire et ensuite la relâche.
c) La mémoire cible de chaque VM est donc l'addition du Current Commit Charge (borné par les valeurs Minimum RAM et Maximum RAM) et du Memory Buffer.

5) Memory Weight

Lors de la version beta du SP1 de 2008 R2, ce paramètre s'appelait "Memory Priority". Il a pour objectif de déterminer la façon dont les VMs sont impactées lorsqu'il y a lieu de redistribuer la mémoire. Le paramètre ne garantit en rien la disponibilité de la mémoire. C'est une des raisons qui, à l'époque, a poussé Microsoft à modifier le nom de ce paramètre.

À quoi sert le Smart Paging ?

Nous y voilà. Nous avons passé en revue les différentes options que nous confère Hyper-V, et abordé très brièvement le fonctionnement de l'allocation dynamique de RAM par l'hyperviseur Microsoft.

Dans sa précédente version, vous pouviez rencontrer un problème de taille lors du redémarrage d'une VM ou de l'hyperviseur. En effet, la mémoire étant allouée dynamiquement, elle est soit ajoutée, soit supprimée. On peut donc arriver à une situation où une VM (ou plusieurs) se retrouvent à un seuil d'allocation de mémoire inférieure au paramètre "Startup RAM" tout en respectant le paramètre "Minimum RAM". Dans ce cas, la VM ne pouvait pas redémarrer, où seulement certains services. Peu pratique n'est-ce-pas ?

C'est la qu'intervient la nouvelle fonctionnalité délivrée par Microsoft. En effet, désormais si lors du démarrage d'une VM, Hyper-V n'est pas capable d'allouer suffisamment de RAM (correspondant au paramètre Startup RAM) et qu'il n'est pas non plus possible de récupérer la RAM nécessaire depuis les autres VMs, un fichier "Smart Paging" sera créé à l'endroit spécifié (comme ci-dessous) et utilisé par la VM en lieu et place de mémoire RAM.



Le fichier n'est créé que lorsque c'est nécessaire. La mémoire rendue disponible par ce mécanisme est présente jusqu'à la fin du processus de démarrage de la VM. Hyper-V se charge de désallouer cette RAM par la technologie de "Ballooning" et ce jusqu'à ce que la VM arrête d'utiliser le "Smart Paging". C'est donc bien un mécanisme temporaire (ne devant pas durer plus de 10 minutes) utilisé seulement dans le cas du démarrage et dans aucun autre cas. Dès que la VM arrête d'utiliser ce fichier, il est supprimé.

samedi 9 mars 2013

Microsoft met à disposition de multiples labs pour aider aux certifications 70-410 à 70-412 (MCSA 2012)


Vous avez planifié votre parcours vers le titre de MCSA Windows Server 2012?


Microsoft vous vient en aide avec de nombreux Labs destinés à vous aider à appréhender les différents sujets abordés par les 3 certifications 70-410, 70-411 et 70-412.

C'est vraiment un super travail fourni par Microsoft pour ceux qui n'ont pas l'occasion de configurer un environnement de test @home.





Le lien contenant les différents Labs mis à disposition par Microsoft : http://technet.microsoft.com/en-us/windowsserver/hh968267.aspx

Enjoy !

mardi 26 février 2013

Delete Subfolders and Files - Définir des droits précis sur une arborescence grâce à .Net

Afin d'automatiser la création d'une arborescence et de définir précisément les droits pour certains utilisateurs dans un domaine Windows Active Directory, j'ai créé un script en Powershell. Le dossier se trouve sur un serveur de fichiers Windows 2000.

Malheureusement, à l'époque où j'ai créé le script, je n'ai jamais pu trouver comment définir le droit spécifique "Delete Subfolders and Files" tout en supprimant le droit "Delete" et ceci en Powershell v2.


Sous forme graphique, le résultat qu'on aimerait obtenir :


J'ai donc créé un petit second script écrit en .Net et appelé par mon script Powershell afin de réaliser cette opération. Le script écrit en powershell fournit deux arguments au script .net compilé et disponible sous le forme d'un simple exécutable: le username qui doit posséder les droits et le dossier sur lequel définir les permissions.

Voici le code .Net pour réaliser l'opération décrite ci-dessus :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.DirectoryServices;
using System.Security.AccessControl;
using System.IO;


namespace GroupADUploadRights
{
    class Program
    {
        static void Main(string[] args)
        {                 
            try
            {
                String[] Args = Environment.GetCommandLineArgs();
                if (Args.Length != 3)
                {
                    System.Console.WriteLine("Wrong command usage.");
                    System.Console.WriteLine("1 mandatory parameter should be given: ");
                    System.Console.WriteLine("Argument 1 : Username");
                    System.Console.WriteLine("Argument 2 : Directory");

                }
                else
                {                  
                    string userDn = "CN="+Args[1]+",OU=myOU,DC=contoso,DC=com"; string groupDn = "CN=Domain Users,OU=Group,DC=contoso,DC=com";
                    DirectoryEntry dirEntry = new DirectoryEntry("LDAP://" + groupDn);
                    dirEntry.Properties["member"].Remove(userDn);
                    dirEntry.CommitChanges();
                    dirEntry.Close();

                    try
                    {
                        string fileName = "f:\\" + Args[2] + "\\folderToRestrict";
                        // Add the access control entry to the file.
                        AddFileSecurity(fileName, Args[1],
                            FileSystemRights.DeleteSubdirectoriesAndFiles, AccessControlType.Allow);

                        // Remove the access control entry from the file.
                        RemoveFileSecurity(fileName, Args[1],
                            FileSystemRights.Delete, AccessControlType.Allow);                      
                    }
                    catch (Exception e)
                    {
                        //Console.WriteLine(e);
                    }

                }
            }
            catch (System.DirectoryServices.DirectoryServicesCOMException Exc)
            {
                //doSomething with E.Message.ToString();
            }          

        }

        // Adds an ACL entry on the specified file for the specified account.
        public static void AddFileSecurity(string fileName, string account,
            FileSystemRights rights, AccessControlType controlType)
        {

            // Get a FileSecurity object that represents the
            // current security settings.
            FileSecurity fSecurity = File.GetAccessControl(fileName);

            // Add the FileSystemAccessRule to the security settings.
            fSecurity.AddAccessRule(new FileSystemAccessRule(account,
                rights, controlType));

            // Set the new access settings.
            File.SetAccessControl(fileName, fSecurity);

        }

        // Removes an ACL entry on the specified file for the specified account.
        public static void RemoveFileSecurity(string fileName, string account,
            FileSystemRights rights, AccessControlType controlType)
        {

            // Get a FileSecurity object that represents the
            // current security settings.
            FileSecurity fSecurity = File.GetAccessControl(fileName);

            // Remove the FileSystemAccessRule from the security settings.
            fSecurity.RemoveAccessRule(new FileSystemAccessRule(account,
                rights, controlType));

            // Set the new access settings.
            File.SetAccessControl(fileName, fSecurity);

        }
    }
}

samedi 23 février 2013

Larger Cover Exam Ref 70-413: Designing and Implementing a Server Infrastructure

Ça y est !

Je suis officiellement MCSA 2012 :-) J'ai passé la certification 70-417 (J'en avais déjà parlé ici : http://sysadminconcombre.blogspot.be/2013/01/larger-cover-exam-ref-70-417-upgrading.html)


Beaucoup de boulot pour y arriver, mais la certif est dans la poche, on va pouvoir se concentrer sur la suivante : 70-413 Designing and Implementing a Server Infrastructure

En effet, j'ai reçu un voucher de la part de Microsoft me permettant de bénéficier d'un examen gratuit sur les trois (70-417; 70-413; 70-414) me séparant du titre de MCSE Server Infrastructure 2012. Un examen coûtant 150€, c'est bienvenu et surtout bien joué commercialement ;-) En effet, ça pousse à ne pas s'arrêter au titre de MCSA 2012.

Le livre acheté : http://shop.oreilly.com/product/0790145370242.do


Je viens d'en finir la lecture, il est très bien écrit comme d'habitude avec les bouquins de chez Microsoft. Beaucoup de liens sont faits vers des articles très précis de Technet.

On sent bien qu'il va falloir beaucoup bosser la pratique... C'est donc reparti pour de longues soirées à bosser en labo.

dimanche 10 février 2013

Microsoft Surface 8 pro 128 GB : Sold out !

À peine quelques heures après sa sortie sur le store US, la tablette Microsoft Surface 8 Pro 128 GB vendue 999$ est sold out !

Il reste encore des exemplaires de la version possédant 64 GB d'espace de stockage en vente : http://surface.microsoftstore.com/store/msstore/Content/pbpage.Surface_Pro?ESICaching=off


Gagnez une visite du Datacenter Microsoft à Dublin !



Il ne vous reste que quelques jours pour tenter de gagner une des dix visites du Datacenter Microsoft à Dublin. En effet, le concours se termine le 14 février à minuit.

Afin de promouvoir la sortie de son OS serveur 2012, Microsoft offre la visite d'un jour et le voyage (aller-retour) jusqu'à Dublin.

Pour participer, vous devez résider en France Métropolitaine (Corse comprise) et être âgé de 16 ans au moins.


Pour faire partie du tirage au sort, il vous suffit de téléchager Windows server 2012.

Lien : http://technet.microsoft.com/fr-fr/evalcenter/hh670538.aspx

Bonne chance !


mardi 29 janvier 2013

Comment déléguer la gestion d'une liste de distribution dans Exchange 2010 ?

Préambule : le modèle de permissions RBAC d'Exchange 2010

Si vous désirez donner la possibilité à vos utilisateurs finaux de gérer leurs listes de distribution, il faut d'abord que vous sachiez que la manière de faire ça dans Exchange 2010 est complètement différente que dans les versions précédentes d'Exchange.

En effet, le modèle de permissions dans Exchange 2010 est basé sur le RBAC (Role Based Access Control). Ceci permet la gestion très fine des permissions. L'intérêt sera évidemment de déléguer des tâches très précises à des utilisateurs à différents niveaux dans l'entreprise.


Le modèle RBAC appliqué à la délégation de gestion d'une liste de distribution

Imaginons qu'un département a besoin de gérer une liste de distribution fréquemment mise à jour. Il est peu intéressant de laisser cette tâche entre les mains d'un administrateur de messagerie Exchange ou même des membres du helpdesk de votre entreprise.

On veut donc donner la possibilité au gestionnaire de cette liste de distribution le droit d'ajouter et de retirer des membres de cette liste.


1) Donner le droit de gestion de la liste à votre utilisateur

Ceci peut se faire via l'ADUC, l'ADAC, mais également via la console EMC (Exchange Management Console).

Nous allons réaliser l'opération via cette dernière.

Recipient Configuration > Distribution Group > 'Votre liste de distribution" > Properties



Cliquez sur l'onglet Group Information et ensuite il vous suffit d'ajouter l'utilisateur gestionnaire de cette liste de distribution.


Via Powershell


Set-DistributionGroup -Identity "DistributionList01" –ManagedBy "Pierre-Alexandre Braeken" -BypassSecurityGroupManagerCheck



2) Le rôle de gestion MyDistributionGroups n'est pas suffisamment granulaire

Rendons-nous sur notre console ECP (Exchange Control Panel) afin de définir un rôle de gestion dont l'objectif est la gestion des membres de la liste de distribution dont notre utilisateur est responsable.


ECP > Role & Auditing > Default Role Assignment Policy > Details




On tombe très rapidement sur ce rôle de gestion : MyDistributionGroups. Mais nous n'allons pas pouvoir l'utiliser. En effet, ce rôle permet à un utilisateur de créer et supprimer des listes de distribution. Ce rôle n'est donc pas assez restrictif puisque nous ne voulons permettre à notre utilisateur que l'ajout/suppression des membres de la liste de distribution.



3) Il nous faut créer notre propre rôle de gestion

Nous allons devoir créer notre propre rôle de gestion, et c'est ici qu'on va pouvoir apprécier la puissance du modèle de permissions RBAC d'Exchange 2010.

Let's Powershell !

Ouvrez une invite Exchange Management Shell.


New-ManagementRole -Name MyDistributionGroupsMembers -Parent MyDistributionGroups



Cette commande permet la création d'un rôle enfant du rôle vu précédemment. Nous devons donc logiquement retirer les possibilités de création/suppression d'une liste de distribution à ce nouveau rôle.

Vous pouvez également ajouter une description à votre nouveau rôle grâce au paramètre Description. La description devra être entourée de " ".


Powershell est à nouveau notre ami et nous entrons les deux commandes suivantes :


Remove-ManagementRoleEntry MyDistributionGroupsMembers\New-DistributionGroup -Confirm:$false




Remove-ManagementRoleEntry MyDistributionGroupsMembers\Remove-DistributionGroup -Confirm:$false





Nous sommes fin prêts désormais à assigner ce nouveau rôle que nous venons de créer à notre policy par défaut.

Nous avons encore besoin d'un peu de Powershell pour ceci :


New-ManagementRoleAssignment -Role MyDistributionGroupsMembers -Policy "Default Role Assignment Policy"



Si nous retournons à nouveau éditer notre policy "Default Role Assignement Policy", nous voyons que notre rôle a bien été ajouté comme enfant du rôle MyDistributionGroups.



Vos utilisateurs responsable de listes de distribution peuvent désormais ajouter/supprimer des membres des celles-c !

dimanche 27 janvier 2013

Windows Server 2012 : Supprimer un contrôleur de domaine corrompu, hors service, en panne de l'Active Directory + seize des rôles FSMO

Scénario

J'ai une infrastructure composée de 3 DC : DC01, DC02, DC03

Le scénario est le suivant :

Le DC01 possède les 5 rôles FSMO.

La zone DNS est intégré à l'active directory et se situe donc dans la partition d'application de notre base Active Directory.

Les DC02 et DC03 sont deux RWDC.

DC01 tombe en panne. Il est irrécupérable. Nous n'avons pas de backup de ce DC.

Nous allons donc devoir :

1) Réaliser le seizing des 5 rôles FSMO
2) Supprimer le DC de notre base Active Directory.

1) Seizing des rôles FSMO

Nous nous connectons au DC02 (un Domain Controller fonctionnel de votre infrastructure, sur lequel vous désirez seizer les rôles FSMO) pour réaliser les opérations qui vont suivre.

Une fois connecté à DC02, lancer un command prompt et entrez la commande "ntdsutil".



Ensuite, entrez la commande "roles". Le prompt affiche désormais "fsmo maintenance:".  Arrivé à ce stade, on peut interroger le système à propos des options disponibles en entrant le symbole "?".

On peut voir que différentes options sont proposées. D'une part, on a toutes les opérations de seizing et d'autre part, les opérations de transfert. Il y a également la commande "Connections" qui va nous servir dès maintenant afin de nous connecter au DC02.



Ok, nous encodons donc la commande "Connections".



Le prompt attend maintenant de nous que nous lui indiquions à quel DC se connecter en mentionnant "server connections: _". On encode la commande suivante "connect to server DC02".



Nous avons connecté ntdsutil à notre DC02. On peut quitter l'utilitaire de connexion en encodant la commande "q".



C'est le moment de réaliser le seizing. Les différentes commandes sont :

seize naming master
seize PDC
seize RID master
seize schema master
seize infrastructure master

Nous commençons par le rôle domain naming master en encodant la commande suivante : "seize naming master". Un message de confirmation nous demande si on est bien certain de vouloir réaliser l'opération qui consiste à demander à DC02 de seizer le rôle domain naming role. On clique sur "Yes".



Voici ce que vous pourrez voir au niveau du prompt. On peut observer que ntdsutil tente d'abord de transférer le rôle. Il rencontre une erreur et seulement ensuite, entreprend le seizing du rôle. Nice.



Il vous faut répéter cette étape avec les 4 autres rôles FSMO pour finalement obtenir tous vos rôles seizés.



Pour les plus paranoïaques d'entre-vous, vous pouvez encore vérifier que DC02 détient les rôles que vous venez de seizer en entrant la commande suivante : 

netdom query /domain:labo fsmo

Il faut remplacer labo par votre nom de domaine.



Ok, nous voici rassuré. Nous allons pourvoir passer à la deuxième partie de notre test.


2) Supprimer le DC de notre base Active Directory.

Selon Technet, il n'y a plus lieu de réaliser un metadata cleanup après la suppression forcée d'un DC.
When you use Remote Server Administration Tools (RSAT) or the Active Directory Users and Computers console (Dsa.msc) that is included with Windows Server 2008 or Windows Server 2008 R2 to delete a domain controller computer account from the Domain Controllers organizational unit (OU), the cleanup of server metadata is performed automatically. Previously, you had to perform a separate metadata cleanup procedure.

Nous allons donc tenter de vérifier ceci afin de voir si les différents enregistrements DNs sont bien purgés.

Avant la suppression de notre DC01, nous prenons un peu la température en vérifiant quelques enregistrements DNS (ici les ressources SRV). On voit bien les enregistrements relatifs à notre DC01.



Je n'ai pas une capture de l'ensemble des enregistrements, mais on a bien saisi l'idée ;-)



Au niveau enregistrement DNS A et NS, pas de problème c'est bien là également.



Selon Technet, on peut utiliser les RSAT, l'ADUC, ADSS ainsi que ntdsutil. On a choisi l'ADUC. Repérer votre DC, et clic droit > "Delete".



Un premier warning nous demande si on veut vraiment supprimer notre DC01. On  répond "Yes". On est venu spécialement pour ça ;-)



Un nouvel avertissement nous prévient qu'il faut utiliser dcpromo lorsqu'on veut dé-commissionner un DC. Il nous faut donc cocher la case "This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO)".



Et on clique sur "Delete".



Il s'agit en plus d'un catalogue global. Une nouvelle demande de confirmation apparaît, on clique sur "Yes".



C'est parti pour un check du DNS. Tout a l'air bien purgé.





Ici, on a encore un enregistrement NS, on va laisser le scavenging agir.



Pareil ici.



Un petit tour au niveau de ADSS nous montre par contre la présence du DC01 dans les serveurs présents dans mon site. Je choisi donc de le supprimer "Delete".



On répond au message d'avertissement par un "Yes".



Allons-y pour les vérifications au niveau réplications (vous pouvez répéter la même opération sur le DC03).


repadmin /showrepl





dcdiag /test:replications




dcdiag /test:netlogons



Pour terminer les vérifications j'ai créé une OU, sur le DC02 et, après la réplication, l'OU est bien apparu sur le DC03.


Cloner un contrôleur de domaine Windows Server 2012 avec Hyper-V (VM-GenerationID)

Préambule : VM-GenerationID

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.

a) Via Msconfig



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).