DFS-N et DFS-R en ligne de commande (republication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2009. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet.

Tout est dans le titre. Comment mettre en place une racine DFS ainsi que sécuriser son contenu en le répliquant entre deux serveurs, le tout en ligne de commande ? Certes il est possible de le réaliser en passant par les assistants de la console “Server Manager”, mais pour en comprendre les arcanes, il faut mettre les mains dans le moteur.

Environnement

Histoire de faire simple, mon environnement est composé d’un unique contrôleur de domaine et de deux serveurs membres. L’objectif est de proposer un point d’accès unique à un contenu qui sera hébergé sur les deux serveurs membres.

Installation

DFS-N et DFS-R sont des sous-ensembles du rôle “File Services”. N’ayant besoin que d’eux, une simple commande “ServerManagercmd.Exe” me permettra de les installer sur chaque serveur membre :

clip_image001

Qui dit DFS-R, dit répertoire à répliquer. On va donc créer un répertoire sur chaque serveur membre :

clip_image002

On va monter un peu le niveau en positionnement des permissions sur notre répertoire avec ICACLS.EXE, successeur de CACLS.EXE sous Windows 2008 :

clip_image003

Reste plus qu’à partager ce répertoire avec des permissions sur le partage qui sont cohérentes avec celles positionnées sur le répertoire NTFS :

clip_image004

Jusqu’à maintenant, rien d’insurmontable. On passe à la vitesse supérieure ?

Création de la racine DFS

La création de toute racine DFS requiert la création d’un partage dit “racine”. Personnellement, je suis d’avis de toujours laisser ce répertoire vide. De ce fait, les permissions positionnées sont restrictives.

clip_image005

A noter le paramètre “Cache” configuré à “none”. Il ne faut jamais oublier que la mise en cache en mode “Hors ligne” est activée sur les partages. Cela peut devenir problématique pour des répertoires dont le contenu est partagé entre plusieurs utilisateurs.

Attaquons-nous à DFSUTIL.EXE, la boite à outil de DFS-N. Pour commencer, la création de la racine DFS de domaine (de type Windows Server 2008) :

clip_image006

On a constaté que la création de la racine s’est bien passée. Le serveur SRV1 héberge cette racine. Cependant que se passe-t-il si ce serveur est indisponible ? Pour assurer la disponibilité d’une racine DFS, on va juste lui ajouter un “target”, référençant lui aussi un répertoire partagé sur le serveur SRV2. :

clip_image007

Maintenant que notre racine DFS est plus fiable, on va s’attaquer à son contenu. Pour faire simple, notre racine DFS va héberger un lien nommé DATAS pour lequel on va fournir deux emplacements UNC (toujours une histoire de disponibilité) que DFS-R nous permettra de maintenir synchronisé. Donc on commence par créer un lien auquel on va ajouter un “target” en plus :

clip_image008

Note racine DFS n’est pas totalement opérationnelle, il reste un peu de configuration, en particulier comment la sélection des liens sera réalisée par le client (deux “targets” pour la racine et deux chemins UNC pour Datas). Je vais me reposer sur la topologie Active Directory et donc sur la notion de proximité de site. Encore faut-il le configurer dans la racine DFS:

clip_image009

Depuis Windows 2003, on peut activer la fonctionnalité (Access-Based Enumeration) sur un partage pour en cacher le contenu pour lequel l’utilisateur n’a pas la permission lire. Depuis Windows Server 2008, c’est aussi possible sur la racine DFS :

clip_image010

Dans ma configuration, j’ai deux “targets” pour la racine et deux chemins UNC pour le lien “DATAS”. Donc, en cas d’indisponibilité, on utilise l’autre lien. Mais comment fait-on pour indiquer aux clients de revenir sur le premier s’il est de nouveau opérationnel ? Avec la notion de FailBack, il suffit juste de l’activer :

clip_image011

A ce stade, la partie DFS-N est opérationnel. Si on utilise un client, on peut effectivement accéder au contenu du lien “DATAS” mais il est vide sur les deux serveurs.  Il est possible de configurer d’autres propriétés à ce niveau (Priority, Rank, …) mais commençons par quelque chose de simple. Jusqu’ici tout va bien. On passe la troisième ?

Configuration de DFS-R

C’est maintenant que cela devient sportif. DFSRADMIN.EXE est un peu moins facile à utiliser. La première étape, c’est de créer un groupe de réplication DFS-R pour lequel on va spécifier que toute la planification de réplication sera réalisée selon le fuseau horaire local du serveur (très utile quand on fait du DFS-R entre les continents !).

clip_image012

Par défaut, le planning de réplication sera complet, c’est à dire 24h/24h sans aucune restriction de bande passante.

Pour répliquer du contenu entre deux serveurs, encore faut-il que nos serveurs soient déclarés comme membre de notre groupe de réplication :

clip_image013

 

A ce stade, pas encore de réplication car DFS-R ne sait pas quel répertoire il faut répliquer. Il faut donc déclarer un “Replicated Folder” qui va correspondre à notre lien DATAS dans notre racine DFS-N de domaine :

clip_image014

Avant de poursuivre, j’ai besoin de créer une structure de répertoire pour DFS-R. L’objectif est d’isoler dans ce répertoire les “Staging Folder” et “Conflict and Deleted Folder” pour lesquels des exceptions doivent impérativement être mises en œuvre au niveau des des antivirus.

clip_image015

C’est maintenant l’heure de la ligne de commande à coucher dehors, à savoir la configuration des propriétés de chaque membre du groupe de réplication pour répliquer le “Replicated Folder”. Pour chaque membre, on spécifie :

  • L’emplacement local des données à répliquer
  • L’état du membre dans le groupe de réplication
  • L’emplacement du “Staging Folder” (répertoire utilisé pour gérer la réplication entre les membres d’un même groupe de réplication)
  • La taille du “Staging Folder”, une notion très importante
  • La taille du répertoire “Conflict and Replicated”
  • Le lien DFS lié à l’emplacement local
  • Si le serveur membre doit être utilisé comme source pour la première réplication ou non

clip_image016

Bien évidemment, c’est une opération à réaliser pour chaque membre. On remarquera que seulement l’un d’entre eux est désigné comme serveur primaire pour la réplication initiale.

A ce stade, la réplication n’a pas encore commencé. Pourquoi ? La raison est simple, on sait quels serveurs, quel répertoire mais pas selon quelle topologie de réplication. Dans notre cas, c’est assez simple puisqu’il y a deux serveurs. Il faut donc deux objets de connexions :

clip_image017

Dans Windows Server 2008, pour qu’une topologie soit considérée comme valide, il faut que chaque serveur soit lié à un autre et inversement. Dans Windows Server 2008 R2, il est possible de configurer une topologie avec des connexions unidirectionnelles et donc de la réplication unidirectionnelle.

A ce stade, la réplication devrait commencer. Cependant, si on regarde le contenu de notre répertoire “C:\DATAS” sur nos deux serveurs, il semble que cela ne fonctionne pas encore. La raison est simple, le service DFS-R actualise sa configuration toutes les soixante minutes. Avec une commande DFSDIAG.EXE, on va forcer chaque serveur à actualiser sa configuration :

clip_image018

Si on consulte le journal d’évènements “DFS Replication” de SRV2, on devrait trouver l’évènement suivant m’indiquant que la réplication initiale de mon “Replicated Folder” est terminée. C’est normal de trouver cet évènement sur SRV2 puis que SRV1 était déclaré comme serveur primaire pour la réplication initiale.

clip_image019

 

Superviser DFS-R

La supervision de DFS-R est un sujet complexe. Pour ceux qui veulent en savoir plus, je recommande les articles de l’équipe en charge de son développement et plus particulièrement celui-ci.

La première solution consiste à utiliser le module de reporting dans la console d’administration. C’est très complet mais c’est manuel. Une seconde possibilité serait d’utiliser le Management Pack de SCOM dédié à DFS-N et DFS-R. Il y a un peu plus de travail mais le résultat en vaut le coup.

Enfin il reste WMI. Une simple commande WMIC nous retourne l’état de la réplication pour le “Replicated Folder” au sein du groupe de réplication :

clip_image020

A la lecture de ces informations, mon groupe de réplication est opérationnel, la réplication initiale est bien terminée et il y a bien cohérence entre les deux serveurs. La taille de mon “Staging Folder” ne dépasse pas les seuils, donc tout va bien. Pour ceux qui veulent obtenir plus d’informations sur la supervision de DFS-R, c’est la classe WMI DFSRReplicatedFolderInfo.

Pour faire simple, la signification des valeurs d’état sont : 0 =Non initialisé, 1=Initialisé, 2= Réplication initiale en cours, 3=Mode récupération automatique, 4=Condition normale, 5=En erreur.

Voilà une mise en œuvre simple de DFS-N/DFS-R. Pour ceux que la mise en œuvre intéresse, je conseille vivement de lire le blog l’équipe en charge de son développement. DFS-R peut vite devenir un casse-tête à exploiter s’il n’est pas correctement mis en œuvre.

Benoîts – Simple By Design

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.