Bonjour à tous,
Aujourd'hui nous abordons la partie 4 de notre série sur la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R, elle sera consacrée à l'étape Redirected.
En théorie
Déroulement de la migration
La migration se compose de 4 états globaux qui sont les suivants :
| Etat |
Actions |
Dossier SYSVOL |
Dossier SYSVOL_DFSR |
Dossier utilisé par les services AD DS |
| Start (Etat 0) |
Etat par défaut, FRS réplique le dossier SYSVOL. |
Présent |
Non présent |
SYSVOL |
| Prepared (Etat 1) |
FRS réplique le dossier SYSVOL et celui-ci est toujours utilisé par les services AD DS.
DFS-R réplique une copie de ce dossier.
|
Présent |
Créé |
SYSVOL |
| Redirected (Etat 2) |
FRS réplique le dossier SYSVOL.
DFS-R réplique toujours sa copie et celle-ci devient le
dossier utilisé par les services AD DS.
|
Présent |
Présent |
SYSVOL_DFSR |
| Eliminated (Etat 3) |
Le dossier SYSVOL répliqué par FRS est supprimé.
DFS-R réplique le dossier SYSVOL.
|
Supprimé |
Présent |
SYSVOL_DFSR |
Particularités
Comme vous pouvez le voir ci-dessus, l'état 2 (Redirected) est le plus impactant :
- En arrière-plan, le mécanisme de réplication DFS-R réplique une copie du dossier SYSVOL, toujours en parallèle de la version répliquée par le mécanisme FRS.
- En façade, c'est le dossier SYSVOL répliqué par le mécanisme DFS-R qui est présenté aux postes clients via les partages NETLOGON et SYSVOL
Il faut souligner les points suivants :
- Un retour arrière reste possible (il faut utiliser la commande dfsrmig /setglobalstate X où X est le numéro de l'étape voulue)
- Il convient de vérifier que la copie du dossier SYSVOL répliquée par le mécanisme DFS-R est intègre avant d'effectuer la bascule vers celle-ci. A toute fin utile, on pourra éxécuter un Rapport de Propagation de la Réplication DFS dans la console DFS Management pour le groupe de réplication Domain System Volume.
- Le dossier SYSVOL est copié une seule et unique fois lors de la premiere étape. Toute modification faite sur les GPOs ou le dossier SYSVOL lui même entre l'état 1 (Prepared) et l'état 2 (Redirected) est perdue.
- Les commandes de migration sont à lancer depuis le contrôleur de domaine possédant le rôle PDC
En pratique
Etat Prepared
Si l'étape précédente a été correctement réalisée, l'état de migration au niveau du domaine AD ainsi que celui de tous les contrôleurs de domaine doit être Prepared.
Etat global (Domaine AD) : dfsrmig /getglobalstate
Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate
Une fois ces deux points vérifiés, nous pouvons démarrer la migration vers l'état Redirected.
Passage vers l'etat Redirected
Etat global (Domaine AD) : dfsrmig /setglobalstate 2
On remarque que la bascule vers la version du dossier SYSVOL répliquée par le mécanisme DFS-R est bien indiquée.
Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate
On voit ici que la migration est en cours car aucun contrôleur de domaine n'est dans l'état defini au niveau du domaine Active Directory (Etat Global).
Etat Redirected atteint
Etat global (Domaine AD) : dfsrmig /getglobalstate
La commande dfsrmig /setglobalstate avait déjà configuré l'état de migration au niveau du domaine Active Directory à Redirected. Celui-ci reste donc inchangé.
Etats de migration locaux (Contrôleurs de domaine) : dfsrmig /getmigrationstate
Le message est explicite, tous les contrôleurs de domaine sont dans l'état Redirected, le même que celui défini au niveau du domaine AD (état global).
On dit que la migration a atteint un état consistant sur tous les contrôleurs de domaine.
Bonus :
En cas de succès, on constate également la présence sur tous les controleurs de domaine de l'evenement 8017 dans le journal d'évènements Applications and Servicies logs -> DFS Replication
La commande net share executée sur un contrôleur de domaine nous confirme que la version du dossier SYSVOL présentée aux postes clients est celle répliquée par le mécanisme DFS-R.
Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la troisième étape, Eliminated.