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

Benoit

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

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.