Archives de catégorie : ADMT

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

Subtilité ADMT et Windows 2008 R2

ADMT, ca fait longtemps que je le pratique (NT4 vers Windows 2000). A force, on ne réfléchit même plus et on déroule.  L’outil n’a pas vraiment changé, donc j’ai déroulé jusqu’à tenter de migrer mon premier poste de travail Windows XP, avec une surprise :

“ERR3:7075 Failed to change domain affiliation, hr=800704f1 The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.”

 

Après quelques recherches, je confirme, ADMT n’a pas beaucoup changé. Pour corriger cette problématique, il faut réactiver les algorithmes cryptographiques de Windows NT 4.0 : KB942564. Ceux-ci sont désactivés depuis Windows 2008 pour des raisons évidentes de sécurité. Conclusion, l’agent ADMT n’a donc pas beaucoup changé, je confirme, …

 

J’ai pas eu le temps de tester mais il semble que cette problématique ait été adressée dans le pack de mise à jour RODC Compatibility Pack pour Windows XP. De mon point de vue, c’est effectivement une alternative plus intéressante que de dégrader la sécurité du système d’information. Encore faut-il pouvoir déployer cette mise à jour avant la migration.

 

Benoits – Simple and Secure by Design but Business compliant.

ADMT 3.2 problème de migration d’ordinateurs

J’avais déjà évoqué les première problématiques autour d’ADMT 3.2 dans un précédent billet. Cette première série concernait principalement des problèmes d’installation du produit. Cela n’empêche pas qu’il puisse y avoir des boques lorsqu’on utilise le produit.

 

Lorsqu’on utilise le “Computer Migration Wizard” avec une liste d’ordinateurs, l’assistant ne permet pas de poursuivre. C’est un blogue de l’interface d’ADMT 3.2. La problématique est décrite dans la KB2327195 qui heureusement propose un contournement. Celui-ci consistant à réaliser l’opération en ligne de commande :

ADMT computer /F:<include file> /IF:YES /SD:"<source_domain>” /TD:"<target_domain>" /TO:"<target_OU>"

Bonnes migrations malgré ce petit problème.

 

BenoîtS – Simple and Secure by Design  but Business compliant.

Problématiques autour d’ADMT 3.2

ADMT 3.2 est à peine disponible que la Directory Services Team publie sur son blog une liste de problématiques liée à cette nouvelle version. La liste des problématique est déjà assez complète. Elle vaut le détour, surtout pour les problématiques concernant la base de données, que celle-ci soit locale ou distante.

 

Petit rappel, cette version ne s’installe que sur Windows Server 2008 R2 car c’est une édition uniquement disponible en X64.

 

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

ADMT 3.2 enfin disponible

Il aura mis le temps à sortir de sa phase beta mais il est enfin disponible à cette adresse. Pour ceux qui ont réalisé des migrations avec ADMT 3.1, il ont certainement du faire face à la KB976659 ou même à la KB974625 (juste pour le fun!).

A noter qu’il n’y a pas de nouvelle version concernant l’agent Password Export Server.

 

Attention cependant à deux subtilités :

– Pas de prise en charge de Windows 2000 comme domaine source, ce qui peut rendre la trajectoire de migration nettement plus complexe.

– ADMT 3.2 n’est disponible que pour les plateformes X64

 

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)