Archives de catégorie : DFSN

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

Retour expérience migration DFS-R en inter-forêt

Les migration Active Directory se suivent et se ressemblent à quelques exceptions près. Chaque nouvelle version de système d’exploitation Microsoft vient apporter son lot de nouvelles fonctionnalités que les clients pourront mettre en œuvre à loisir. C’est lors d’une ces ces migrations que j’ai eu l’occasion de travailler sur la migration de namespaces DFS-N et groupes de réplication DFS-R, le tout hébergé sur plateforme Windows Server 2008 R2.

 

Quelques points à connaitre

Une racine DFS-N de domaine est basées sur le nom du domaine. Lors de la migration, la racine DFS recréée portera donc un nouveau nom. A priori, cela ne semble pas poser de problème, sauf quand il existe des liaisons. C’est par exemple le cas entre des classeurs Excel. C’est le chemin UNC qui est référencé, pas le lecteur réseau. Il existe bien des outils sur le marché pour traiter ces problème, mais cela implique que l’utilisateur n’ait pas verrouillé son fichier avec un mot de passe.

La configuration d’une racine de domaine DFS-N est stockée dans partition de domaine de l’Active Directory. Lorsque le serveur migrera vers le domaine “cible”, les informations relatives à la racine ne migreront pas, voir : About the DFS Namespaces service and its configuration data on a computer that is running Windows Server 2003 or Windows Server 2008 pour savoir comment effacer les informations proprement.

La configuration d’un groupe de réplication DFS-R est nécessairement stocké dans l’annuaire Active Directory. Ici encore, la configuration ne suivra pas lors de la migration vers le domaine ”cible”. Si la configuration ne suit pas, c’est qu’il faudra reconstruire le groupe de réplication DFS-R. On peut reconstruire à partir de zéro avec un processus de réplication initial standard mais on peut aussi utiliser le Pre-seeding pour accélérer le processus. La procédure est un peu particulière mais bien documentée : http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx. Veuillez à respecter scrupuleusement la procédure, sinon, on perd l’avantage du pre-seeding.

Il n’est pas possible de désinstaller les sous-rôles DFS-N et DFS-R si le rôle ADDS est aussi installé. Conclusion, si le serveur est aussi contrôleur de domaine, une rétrogradation en simple serveur membre et une désinstallation du rôle sont nécessaires avant de commencer.

Lorsque deux membres d’un groupe de réplication DFS-R sont connectés à un réseau local et que les fichiers à répliquer sont de petites tailles, désactiver le protocole RDC, c’est bien plus efficace.

 

Avant de commencer

Cela peut paraitre bête à dire mais si on ne supervise pas DFS-R, on ne sait pas si tous les serveurs membres du groupe de réplication DFS-R sont synchronisés. Pour cela quelques outils :

  • “DFSRDIAG.EXE Replication state” : Permet de déterminer si des réplications sont en cours
  • “DFSRDIAG.EXE BACKLOG” : Pour suivre précisément ce qui est en cours et en attente de réplication entre deux membres d’un même groupe de réplication DFS-R
  • Le Health Report proposés par la console DFS Management

 

Dès lors qu’on est assuré de la bonne synchronisation de tous les membres d’un groupe de réplication DFS-R on peut s’attaquer à la migration. Chaque serveur devra être migré individuellement. L’objectif est de désactiver progressivement les target DFS-N correspondants pour que les clients ne puissent plus utiliser qu’un seul target DFS-N, c’est ce serveur qui sera migré en dernier et utilisé comme maitre pour la réplication initiale ainsi que le pre-seeding.

 

Lors d’une migration inter-forêt, il est nécessaire de remplacer les références aux objets de sécurité du domaine “source” par celles équivalentes dans le domaine “cible”. Cette opération nommée Reacling va avoir un impact sur le processus de réplication DFS-R dans la mesure ou les ACL de tous les fichiers vont être modifiées. Ces modifications devant être répliquées vers les autres membres du groupe de réplication DFS-R, elles peuvent saturer le staging folder. Il conviendra donc de prévoir une taille suffisante pour celui-ci. Si possible se reposer sur le SID-History, à moins d’être contraint de le faire, on économise ainsi une phase de reacling. L’erreur serait de réaliser une opération de reacling alors que le groupe de réplication DFS-R vient de finir sa synchronisation initiale.

 

Réalisation de l’opération
  • Supprimer les objets connexions DFS-R pour les serveurs à migrer
  • Supprimer les “membership” DFS-R pour les serveurs à migrer
  • Supprimer les “replicated Folder” avant de supprimer les “Replication Group”
  • Si le serveur est “Root Namespace server” pour une racine DFS-N, penser à le supprimer avant la migration, sinon, il ne pourra plus le redevenir une fois migré
  • Désinstaller DFS-R et DFS-N des serveurs à migrer
  • Supprimer les données contenues dans le “staging folder” des groupes de réplication DFS-R, elles ne serviront plus.
  • Migrer les serveurs vers le nouveau domaine
  • Réinstaller les sous-rôles DFS-N et DFS-R
  • S’assurer que les correctifs relatifs à DFS-N et DFS-R sont bien installés sur les serveurs migrés : KB968429
  • Si on pense effectuer le pre-seeding des futurs membres DFS-R avec ROBOCOPY.EXE, alors s’assurer qu’on dispose bien de la dernière version : KB979808
  • Recréer la racine DFS-N
  • N’activer qu’un seul “target DFS” le temps que le groupe de réplication DFS-R ne réalise sa synchronisation initiale
  • Recréer le groupe de réplication DFS-R
  • Bien penser à configurer des tailles de “staging folder” suffisantes, sinon, la réplication initiale ne pourra être réaliser
  • Sur les serveurs membres du groupe de réplication DFS-R qui n’ont pas été désignés comme primaire, on droit trouver trace de l’évènement ci-dessous indiquant le début de la synchronisation initiale :

image

Puis, si le processus de preseeding s’est bien déroulé, on doit trouver trace de l’évènement ci-dessous indiquant la fin de la phase de synchronisation initiale.

image

  • Réactiver les “Target DFS” pointant sur les membres de groupes de réplication DFS-R qui ont été identifiés comme synchronisés.

 

Bonne fêtes.

 

BenoîtS – Simple and Secure by design but Business compliant