Restauration d’un contrôleur de domaine virtuel grâce à Veeam

Si la problématique de la sauvegarde de contrôleurs de domaine et surtout de leur restauration fut un temps épineuse, ce n’est plus tellement le cas de nos jours, grâce à des avancées côté Windows et côté outils de sauvegarde.

Dans le cadre d’un contrôleur de domaine virtuel, si réaliser un snapshot avant d’installer des mises à jour Windows par exemple peut partir d’un bon sentiment, c’est la catastrophe assurée en cas de retour en arrière, toute la cohérence de l’annuaire étant remise en question puisque le DC sera incapable de comprendre pourquoi il se voit présenter des mises à jour venant du futur puisqu’il aura été restauré à un état passé comme si rien ne s’était passé depuis la création du snap. L’outil Windows Server Backup peut être un bon point de départ pour la sauvegarde d’AD ; cependant l’emplacement de stockage n’est peut-être pas toujours défini à l’avance et l’outil peut ne pas s’intégrer dans les politiques de sauvegarde de l’infrastructure générale.

Récemment, j’ai pu effectuer sur une plateforme de tests la sauvegarde et la restauration de contrôleurs de domaines virtualisés sous vSphere ESXi grâce à Veeam Backup & Replication. Dans cet article, je vais aborder les points principaux d’une telle manipulation si un contrôleur de domaine ne démarre plus (et que par conséquent, la structure de l’AD est intacte), sans oublier de rappeler qu’il est indispensable de valider sur des environnements iso ces procédures de sauvegarde et restauration, en plus d’avoir connaissance de la documentation Veeam à ce sujet (p. ex. ces deux articles : ici et ). Dans le cas où la cohérence même de l’annuaire a été remise en question
(corruption, par exemple), d’autres étapes peuvent être requises
(je pense notamment par un passage par le DSRM) mais je ne les aborderai pas dans cet article.

La plateforme de test est composée de 4 machines : 3 contrôleurs de domaine 2012 R2 et un client Windows 10, sous vSphere 6.5 et sauvegardée par Veeam Backup & Replication en version 9.5.

Tout d’abord, il est important de vérifier que le job de sauvegarde des DC ait l’option Enable Application-aware Processing d’activée.

Bien sûr, avant de s’engager dans plus de manipulations, il sera bienvenu de s’assurer que les sauvegardes ont été réalisées avec succès en temps et en heures.

Suite à des manipulations sur dc03, j’obtiens un célèbre BSOD :

Ce DC doit donc être restauré. Dans VMware, je vais procéder à sa mise hors-tension, et à la suppression de la VM.

Dans Veeam, je vais procéder à la restauration de la VM, en utilisant les options Entire VM Restore puis Instant Recovery.

Je choisis de restaurer la VM to the original location, sans connecter le réseau ni directement démarrer la VM. Une fois cette opération terminée, la VM sera ajoutée dans VMware et stockée sur le pool de sauvegarde Veeam ; il faut la déplacer sur le stockage de production.

En allant sur Instant Recovery dans Veeam, je peux sélectionner mon dc03 et choisir Migrate to Production.

Une vérification des paramètres s’impose pour être sûr de finaliser la récupération au bon endroit, puis le déplacement sur l’environnement de production s’effectue.

Une fois l’opération terminée, je sélectionne l’option Stop Publishing sur dc03. Ainsi, il disparaît de VMware où il apparaissait en double : en tant que dc03 (fraîchement restauré) et dc03-xxxxx (la restauration de Veeam avant son déplacement sur l’environnement de production). Il ne reste donc plus que dc03.

Un petit tour dans les paramètres de la VM pour confirmer que tout est bien configuré : ne pas oublier de connecter la carte réseau avant de la démarrer.

Windows va s’initialiser puis redémarrer au bout de quelques minutes – c’est normal.

En réalité, Windows démarre en mode sans échec, se resynchronise avec les autres contrôleurs de domaine, réalise des mises à jour de fichiers de configuration avant de redémarrer. Une fois ce redémarrage terminé, l’OS est utilisable et répond aux requêtes AD comme si rien ne s’était passé. Tout le processus est entièrement automatique et géré par Veeam, qui lors de la sauvegarde, applique certains paramètres en détectant que la VM est un DC Windows.

Il ne reste plus qu’à réaliser quelques tests grâce à dcdiag et repadmin :

Un dcdiag /a /i devrait tout de même renvoyer quelques erreurs systèmes qui ont été journalisées dans l’event viewer en fonction de la manière dont le DC a planté mais tous les autres tests devraient être en succès, pour peu qu’ils l’aient été pré-crash. D’autres tests comme la jonction de stations aux domaine doivent toujours fonctionner sans anicroche.

Powershell : automatisation de la création et peuplement de groupes AD

Dans le billet précédent, j’expliquais la création de groupes ActiveDirectory pour cadrer les flux générés par le Windows Update Delivery Optimization. Afin de faciliter le process de création de groupes et de peuplement de ces groupes, j’ai développé un script Powershell qui, avec un peu d’adaptation, permet d’automatiser tout ce travail.

Ce script va importer un fichier CSV dans un tableau dont toutes les lignes seront traitées pour créer un groupe correspondant, renvoyer le GUID du groupe créé, puis ajouter à ce groupe les stations de travail correspondantes.

Dans cet exemple, le fichier CSV peut se présenter ainsi :

Le fichier CSV en question avec les « colonnes » ID et location qui seront ensuite importées dans un tableau.

Ensuite, en prenant comme nomenclature <SiteID><Type><No>, qui va donner des noms comme FR01F01 pour le premier desktop parisien ou UK02M03 pour le troisième laptop du site de Glasgow, on peut articuler la requête ActiveDirectory qui va lister les stations correspondantes au site pour ensuite peupler le groupe lié. Le passage d’un paramètre permet de sélectionner – si cela est possible – le type de station que l’on souhaite inclure. Il sera peut-être nécessaire de travailler le contenu de la requête ActiveDirectory afin qu’elle corresponde à la nomenclature de nommage des stations.

function adquery{
param($T)
$adQuery = "Get-ADComputer -filter 'Name -like ""$id$T*""'"
$compList = Invoke-Expression $adQuery
if($?) {
foreach($comp in $compList){
Add-ADGroupMember -Identity $GrpName -Members $comp
}
}
}

$siteList = Import-CSV site.csv
$dn = (Get-ADDomain).DistinguishedName
foreach ($site in $siteList){
$id = $site.ID
$loc = $site.Location
$GrpName = $id+"-WUDO"
New-ADGroup -Name $GrpName -Description "Groupe d'ordinateurs du site $id ($loc)" -GroupScope DomainLocal -GroupCategory Security -Path "OU=Groupes-WUDO,OU=Workstations,$dn"
Write-Host "Groupe $GrpName"
Write-Host (Get-ADGroup $GrpName).ObjectGuid.Guid
adquery("F")
adquery("L")
}

Restriction du Windows Update Delivery Optimization par groupe ActiveDirectory

Le WUDO ou Windows Update Delivery Optimization est un composant Windows présent sous Windows 10 qui permet d’optimiser la bande passante réseau consommée lors de la distribution de mises à jour système via WSUS par exemple. En imaginant un réseau d’une dizaine de stations, une seule d’entre elles pourrait utiliser le WAN pour récupérer les mises à jour depuis un serveur WSUS situé en central et les autres utilisent le LAN pour les télécharger à partir de celle les ayant obtenues via le WAN afin d’éviter une saturation de ce dernier. Ce qui peut être un gain de bande passante peut avoir des effets de bord notables ; c’est pourquoi il est possible de contrôler finement le comportement du WUDO via GPO. Un moyen de mieux centrer son action est de passer par la création de groupes ActiveDirectory pour regrouper des stations ; c’est ce que je vais présenter dans cet article.

La problématique est la suivante : des stations du site fictif de Paris utilisent le WAN pour télécharger des mises à jour WSUS sur des stations à Londres. Afin d’éviter de saturer ce lien, on souhaite donc limiter le WUDO à récupérer des données depuis des stations d’un même site uniquement.

Voici la composition de cette maquette de test :

  • OU computers, comprenant 3 OU paris, bxl et london, comprenant les stations propres à chaque site.
  • OU wudo-grp, qui contiendra les groupes AD wudo_paris, wudo_bxl et wudo_ldn dans lesquels seront placées les stations de chaque site.

Il est nécessaire de créer une GPO par groupe AD, d’où l’importance de bien définir ses besoins et surtout, l’organisation qui va être adoptée pour bien séparer les flux de communication WUDO. Une séparation trop granulaire demandera beaucoup de travail d’administration et l’inverse n’aura probablement aucun effet de correction des effets de bord ! Cette GPO va prendre en paramètre unique le GUID du groupe, il faut donc le récupérer et surtout, le stocker quelque part pour toujours avoir une association facile entre GUID et GPO associée.

En Powershell, l’instruction suivante nous permettra de récupérer le GUID du groupe.

(Get-AdGroup wudo_paris).ObjectGuid.Guid

Bien entendu, une boucle foreach dans un script récupérant tous les groupes d’une OU permettra de tous les obtenir facilement.

Désormais, il faut s’occuper de la création des GPO. Les réglages qui nous intéressent sont dans Computer Configuration > Policies > Administrative Templates > Windows Components > Delivery Optimization.

La première option est le Download Mode, qu’il faut passer à 2. La description du paramètre explique bien les différentes options possibles. Il est important de noter que ce qui est désigné comme « LAN » ici n’est pas un LAN au sens physique du terme mais un réseau interne ActiveDirectory. Par exemple, si votre domaine s’appelle schmitouille.net, alors le LAN englobera toutes les stations dans schmitouille.net. Si vous avez des sous-domaines, alors le LAN considèrera les stations du sous-domaine, par exemple fr.schmitouille.net.

Ensuite, l’autre paramètre est Group ID. C’est ici que devra être renseigné le GUID du groupe correspondant. Ici, je vais placer le GUID du groupe wudo_bxl car c’est la GPO qui va régir le WUDO des stations du site fictif de Bruxelles.

Il ne me reste plus qu’à lier cette GPO sur l’OU contenant les stations, et non celle contenant les groupes. Toujours en restant dans le cadre du site de Bruxelles :

… et à répéter l’opération autant de fois que nécessaire. En fonction de l’architecture de l’ActiveDirectory, il peut être nécessaire d’appliquer un Security Filtering sur le groupe d’ordinateurs concerné afin d’être sûr que la GPO ne s’applique que sur les stations désirées.

Afin de faire en sorte que les paramètres soient pris en compte le plus rapidement possible, il est possible de forcer un gpupdate à distance via Powershell. Voici un snippet que j’ai réalisé permettant de passer sur toutes les stations désormais régies par ces politiques de groupe pour mettre à jour ces dernières (à noter qu’en fonction de la disponibilité des stations, des paramètres firewall ou des droits du compte l’exécutant, il peut y avoir des erreurs) :

$grouplist = Get-ADGroup -Filter 'Name -like "wudo_*"'
foreach ($group in $grouplist){
    $complist = Get-AdGroupMember $group
    foreach ($comp in $complist){
        Write-Host "Processing:"$comp.Name
        Invoke-GPUpdate -Computer $comp.Name -RandomDelayInMinutes 0
    }
}

Enfin, pour vérifier que la GPO est bien redescendue, il est possible d’utiliser la fonctionnalité Group Policy Result et d’avoir un rapport indiquant si oui ou non la GPO a bien été appliquée. Si oui, le WUDO de la station concernée ne pourra donc interroger que les membres du groupe AD dont le GUID correspond à la GPO appliquée.

Powershell : duplication de groupe ActiveDirectory

Aussi surprenant que cela puisse paraître, il n’est pas possible de dupliquer nativement dans ActiveDirectory un groupe via l’interface graphique. Bien qu’il existe des outils comme Quest permettant de faire ce genre de tâches, il est possible de réaliser une duplication de groupe avec Powershell sans trop se prendre la tête.

Ce script va donc demander à l’utilisateur le nom du groupe d’origine puis le nom du nouveau groupe. Il va copier les informations de base (type de groupe, sécurité, nom, description et membres) pour les réinjecter à l’identique dans le nouveau groupe qui sera créé au même endroit.

Write-Host "ActiveDirectory Group Duplication Script"
Write-Host "========================================"
Write-Host "This script will make a copy of an AD group."
$origgrpname = Read-Host "Input the original group you want to duplicate"
$newgrpname = Read-Host "Input the new group's name"
Write-Host "Working... Depending on the size of your domain or the group, it might take some time..."
$origgrpdtl = Get-ADGroup $origgrpname -Properties Description, DisplayName
$origgrpmbr = Get-ADGroupMember $origgrpname
$path = $origgrpdtl.DistinguishedName.SubString(4+$origgrpname.length,$origgrpdtl.DistinguishedName.Length-4-$origgrpname.Length)
New-ADGroup -Name $newgrpname -GroupScope $origgrpdtl.GroupScope -Description $origgrpdtl.Description -DisplayName $origgrpdtl.DisplayName -GroupCategory $origgrpdtl.GroupCategory -Path $path
foreach($member in $origgrpmbr) {
Add-ADGroupMember $newgrpname $member.samAccountName
}
Write-Host "Duplication process over."
echo "Group $origgrpname has been duplicated to $newgrpname. The new group is located in $path along the original one."
Write-Host "Bye"

J’ai réalisé ce script dans le cadre de création de nouveaux groupes de partages pour un nouveau serveur, il me fallait donc un moyen rapide de recréer plusieurs groupes sans avoir à ajouter à la main les dizaines d’utilisateurs présents. Naturellement, on prendra soin d’exécuter ce script avec un compte ayant suffisamment de privilèges et en faisant attention au nom des groupes puisque je n’ai inclus aucun contrôle de robustesse.