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. 

--> La suite est à lire sur le site : http://danstoncloud.com/blogs/simplebydesign/archive/2012/12/31/retour-exp-233-rience-migration-dfs-r-en-inter-for-234-t.aspx