Archives de catégorie : DFSR

DFSRMIG & SYSVOL (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.

Lors de la mise à niveau d’une infrastructure Active Directory, la mise à niveau des contrôleurs de domaine vers Windows Server 2008 doit être finalisée par une migration de NTFRS vers DFS-R. En effet, même avec des contrôleurs de domaine sous Windows Server 2008, c’est toujours NTFRS qui est utilisé pour répliquer le contenu de SYSVOL (sauf si on a pas migré). DFS-R présente un certain nombre d’avantages dont :

  • Une meilleure fiabilité dans les environnements complexes comprenant de nombreux contrôleurs de domaine
  • La possibilité de répliquer au niveau des changements opérés dans les fichiers (Remote Differential Compression)
  • Une meilleure sécurisation du contenu de SYSVOL sur les RDOC.
  • Jusqu’à seize transferts de fichiers simultanément, au lieu de quatre
  • Une gestion asynchrone des transferts
  • Une reconstruction automatique suite à un arrêt brutal du serveur

Pour bénéficier de ces avantages et de beaucoup d’autres, il est nécessaire de migrer  SYSVOL vers DFS-R. Ce processus doit être réalisé sur l’ensemble des contrôleurs de domaine de chaque domaine. le processus de migration est intégralement piloté au travers d’un seul et unique outil : “DFSRMIG.EXE”.

Pré-requis

  • La migration vers DFS-R n’est possible que dès lors que le mode de domaine est “Windows Server 2008”. Ceci implique que tous les contrôleurs de domaine de version antérieurs ont bien été migrés. Pour rappel, cette opération sera irréversible. Il ne sera plus possible de promouvoir des serveurs membre en contrôleurs de domaine pour les systèmes d’exploitation antérieur à Windows Server 2008.
  • Chaque contrôleur de domaine reportera son état de migration ainsi que son avancement dans des objets créés pour l’occasion dans l’annuaire Active Directory. Il est donc impératif que la réplication d’annuaire Active Directory soit opérationnelle. De ce fait, on peut tout de suite poser la règle suivante : “C’est la vitesse de propagation des mises à jour Active Directory qui donne le tempo de la migration et impose la durée globale de l’opération” (Commandant Sylvestre s’abstenir!).
  • Le processus de bascule vers DFS-R va reprendre le contenu du partage SYSVOL actuel. Il est donc impératif de s’assurer qu’il n’y a pas de problème à ce niveau. Par exemple qu’il y a bien cohérence entre la version de la GPO inscrite dans l’annuaire Active Directory et son contenu dans le partage SYSVOL.

Démarche

La démarche de l’outil DFSRMIG.EXE repose sur quatre phases :

  • Phase “Start” : DFSRMIG.EXE va mettre en place les moyens nécessaires au suivi de la migration pour chaque contrôleur de domaine. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • Phase “Prepared” : DFSRMIG.EXE va mettre en place un nouveau répertoire SYSVOL et alimenter son contenu. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • phase “Redirected” : DFSRMIG.EXE va continuer à maintenir l’ancien répertoire SYSVOL  mais rediriger le partage vers le nouveau répertoire SYSVOL. A ce stade, SYSVOL est toujours répliqué avec NTFRS.
  • Phase “Eleminated” : Lors de cette dernière phase, NTFRS sera démantelé. Seul DFS-R sera utilisé pour répliquer le contenu de notre nouveau partage SYSVOL.

 

Il est à noter que l’ensemble du processus sera intégralement pilote depuis le contrôleur de domaine hébergeant le rôle de maitre d’émulateur principal de domaine (PDCE). De plus, le processus de migration est réversible (possibilité de revenir à l’état précédent ou de tout annuler) sauf pour la dernière étape. On peut donc considérer que la migration ne présente pas de risque majeur pour l’infrastructure.

Dans quel état suis-je?

C’est la phase d’initialisation. L’objectif de cette phase est de mettre en place les moyens nécessaire au suivi de la migration. D’un point de vue technique, chaque contrôleur de domaine devra reporter son état de migration dans l’annuaire Active Directory toutes les cinq minutes. C’est grâce à cela que l’on va consolider les informations et déterminer l’avancement de la migration. Pour déterminer dans quel état se trouve la migration, on dispose de la commande DFSRMIG.EXE /GetGlobalState tel qu’illustré ci-dessous :

clip_image001

 

Dans le cas illustré ci-dessous, le processus de migration n’a pas encore commencé. Pour ma démonstration, mon environnement comprend un domaine composé de trois contrôleurs de domaine opérant sous Windows Server 2008, dans un seul site Active Directory.

Initialiser la migration : Phase “Start”

Pour passer d’un mode à un autre, on dispose de l’argument “/SetGlobalState” auquel on associe une valeur. Dans le cas présent, la valeur “0” pour initialiser la phase “Start”. tel qu’illustré ci-dessous :

clip_image002

 

On peut immédiatement s’assurer que la commande a bien été prise en compte avec une nouvelle exécution de la commande “DFSRMIG.EXE /GetGlobalState” tel qu’illustré ci-dessous :

clip_image003

 

On peut même obtenir un peu plus de précision avec l’argument “/GetMigrationState” :

clip_image004

 

Pour plus d’informations, on dispose même d’un journal d’exécution de chaque commande “DFSRMIG.EXE” dans le répertoire “C:\Windows\Debug” sur chaque contrôleur de domaine. A ce stade, rien n’a encore changé, on a juste initié le processus de migration.

Préparer la migration : Phase “Prepared”

Entrons dans le vif du sujet. Le passage à la phase “Prepared” va engendrer la création d’un répertoire “SYSVOL_DFSR” sur chaque contrôleur de domaine. Son contenu sera recopié à l’aide de ROBOCOPY.EXE.

clip_image005

 

L’exécution de la commande “DFSRMIG.EXE /SetGlobalState 1” indique que chaque contrôleur de domaine devra procéder à la création de son propre répertoire”SYSVOL_DFSR”. Pour accélérer les choses, on peut  forcer nos contrôleurs de domaine à travailler un peu plus rapidement avec la commande : “DFSRDIAG.EXE POLLAD” :

clip_image006

 

De cette manière, on force notre contrôleur de domaine à prendre en considération le changement d’état au lieu d’attendre cinq minutes. Avant de pouvoir continuer, il faut s’assurer que chaque contrôleur de domaine a bien pris en charge le changement d’état avec la commande “DFSRMIG.EXE /GetMigrationState”.

clip_image007

 

L’illustration ci-dessous nous indique que le contrôleur de domaine “DC2” n’a pas encore réaliser la première réplication initiale. Il n’est donc pas encore possible de passer à la suite.

clip_image008

 

Avec un peu de patience, tous les contrôleurs de domaine ont fini par créer leur propre répertoire “C:\Windows\SYSVOL_DFSR”. Pour s’en assurer, on trouvera même le journal d’exécution de la commande “Robocopy.Exe” dans le répertoire “C:\Windows\Debug”. On pourra y constater que l’opération à consister en une copie locale des données. On comprend donc pourquoi il est important que le contenu de SYSVOL soit cohérent entre tous les contrôleurs de domaine :

clip_image009

 

Un peu plus tôt dans ce billet, j’ai indique que chaque contrôleur de domaine reportait son état individuel de migration dans l’annuaire Active Directory. Chaque contrôleur de domaine va créer un conteneur “DFSR-LocalSettings” tel qu’illustré ci-dessous pour y référencer son état dans l’attribut msDFSR-Flags :

clip_image010

 

La valeur “16” indique un état “Prepared”. Voila donc un moyen fiable de suivre l’avancement de chaque contrôleur de domaine.

Une petite subtilité pour les RODC. Chaque contrôleur de domaine est censé maintenir son état en créant le conteneur et en renseignant l’attribut. Pour eux, ils ont besoin d’un petit coup de pouce avec la commande “DFSRMIG.EXE /CreateGlobalObjects” pour créer le conteneur à leur place. Les RODC maintiendront leur état en actualisant l’attribut directement sur le PDCE.

 

Redirection : Phase “redirected”

Jusqu’à maintenant, SYSVOL est toujours SYSVOL, il n’a pas changé. Pour s’en assurer, rien de mieux qu’une commande “NET SHARE” :

clip_image011

 

L’objectif de cette phase est de remplacer le répertoire partagé pour SYSVOL, tout en continuant à maintenir la réplication NTFRS, ce qui nous permet de toujours revenir en arrière, voire même d’annuler toute l’opération. Et bien basculons avant la commande “DFSRMIG.EXE /SetMigrationState 2” tel qu’illustré ci-dessous :

clip_image012

Lors de cette phase, chaque contrôleur de domaine va de nouveau effectuer un Robocopy entre son répertoire “SYSVOL” et “SYSVOL_DFSR” pour s’assurer qu’il dispose bien des fichiers les plus récents. Ici encore, on peut suivre chaque migration avec les fichiers de journalisation générés dans le répertoire “C:\Windows\Debug” ou bien plus globalement tel qu’illustré ci-dessous :

clip_image013

 

Si on va plus vite que la réplication, la commande “DFSRMIG.EXE /GetMigrationState” nous indiquera que nos contrôleurs de domaine n’ont pas encore commencé l’opération. Avec un peu de patience (ou à la méthode “Commandant Sylvestre”  : DFSRDIAG.EXE POLLAD + REPADMIN /SYNCALL /E = *** j’ai le réseau qui lag!), on arrive au résultat suivant :

clip_image014

 

Petite remarque, il serait opportun de “figer” les modifications réalisées sur “SYSVOL” avant de passer à la phase “Redirected” pour s’assurer que chaque contrôleur de domaine dispose bien des fichiers les plus récents.

L’avancement individuel de la migration peut être constaté en consultant la valeur de l’attribut msDFSR-Flags” qui doit être passé à 32 :

  clip_image015

 

Ou bien plus simplement avec une commande “NET SHARE”:

clip_image016

 

On constate donc que les partages “NETLOGON” et “SYSVOL” désignent maintenant un sous-répertoire différent. A ce stade, il est toujours possible de revenir en arrière, voire d’annuler toute la migration. Pour s’en convaincre, chaque contrôleur de domaine de dispose toujours de sa propre copie du répertoire SYSVOL, toujours maintenue :

clip_image017

 

Elimination: Phase “Eliminated”

L’ultime étape, celle qui est irréversible (merci de maintenir les commandants sylvestre à l’écart). L’exécution de la commande “DFSRMIG.EXE /SetGlobalState 3” va supprimer le répertoire “SYSVOL” ainsi que les souscriptions FRS de chaque contrôleur de domaine :

clip_image018

 

Comme toujours, on peut constater l’avancement avec la commande “DFSRMIG.EXE /GetMigrationState”

clip_image019

 

Une fois l’opération terminée :

clip_image020

Et dans l’annuaire Active Directory :

clip_image021

Le service NTFRS est arrêté et n’est plus considéré comme un service dépendant pour le démarrage de l’annuaire Active Directory.

Encore une fois, petite subtilités pour les RODC. Ils ne pourront supprimer les abonnements FRS eux même. Ils ont besoin d’aide avec la commande “DFSRMIG.EXE /DeleteRoNtfrsMember”

 

Rollback ?

Oui, c’est possible mais uniquement jusqu’à la phase “redirected”. Il suffit juste d’exécuter la commande “DFSRMIG.EXE /SetGlobalState’ avec le numéro de l’état correspondant.

 

Conclusion

C’est simple, transparent pour l’utilisateur final, sans risque majeur pour l’infrastructure. En plus, cela permettra d’éviter qu’un “commandant Sylvestre” auquel on aura accordé le privilège d’administrer un RODC de supprimer le contenu de son partage SYSVOL et par extension de répliquer son erreur sur l’ensemble de l’infrastructure. DFSR détectera la problématique et procèdera automatiquement à une restauration autoritaire du contenu du partage. La migration DFSR est donc impérative dès lors que notre infrastructure comprend des RODC.

BenoîtS – Simple by Design

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

DFSR Dirty Shutdown Recovery

Un sujet un peu “capilo-tracté” pour changer et un petit retour aux sources (Active Directory). Qu’est ce qui se passe au niveau DFSR lors d’un arrêt non planifié d’un contrôleur de domaine ou d’un serveur hébergeant le rôle DFS-R et participant à un groupe de réplication.

Pour rappel DFSR repose sur une base de données Jet qui va tracer tous les changements opérés sur les fichiers dépendant d’un replicated folder donné localisé sur un volume disque particulier. On comprend tout de suite que le bon fonctionnement de cette base de données est essentiel. Sans elle, DFSR n’est plus capable de répliquer les changements opérés localement ou de déterminer s’il doit prendre en comptes les mises à jour opérées sur les autre membres du groupe de réplication.

 

Avant c’était simple

DFSR a été introduit avec Windows 2003 mais réellement généralisé à partir de Windows Server 2008 où il était possible de basculer le SYSVOL vers DFSR avec l’utilitaire DFSRMIG.EXE. Depuis cette époque, lors d’un arrêt non planifié, on avait le message suivant dans le journal dédié à DFSR :

image

 

C’est clair, rien à faire, le système d’exploitation s’occupe de tout. Si le processus de recovery se passait bien, on avait un event 2214 :

image

 

ou 2216 dans le cas contraire :

image

Dans les deux cas, on n’avait rien à faire, DFSR s’occupait de tout. Mais ça c’était avant.

 

Mais c’était avant (2008 R2/2012)

Avec Windows Server 2012, Microsoft a considéré qu’il y avait un risque de perdre des données et que par défaut DFSR ne devait plus auto-réparer sa base de données.

image

 

L’event donne deux informations :

  • Premièrement, il faut que nous nous assurions de ne pas perdre de données lors de la remise en ligne, c’est de notre responsabilité
  • Deuxièmement, que la remise en ligne s’effectue à l’aide d’une ligne de commande qui doit être exécutée localement sur le serveur incriminé.

 

Cela devient problématique car en cas de crash d’un contrôleur de domaine, Active Directory est bien capable de revenir en ligne, le répertoire SYSVOL est bien partagé et visible par les utilisateur mais le contenu des GPO peut avoir été altéré et ne plus être cohérent avec les autres contrôleurs de domaine.

 

Comme Microsoft est cohérent, il a mis à disposition un correctif KB2663685 pour Windows 2008 R2 pour reproduire le mode de fonctionnement de Windows Server 2012. Tant que le correctif n’est pas généralisé sur tous les serveurs membre du groupe de réplication DFSR, le comportement du processus de recovery va donc varier. ce correctif permet aussi de configurer le comportement du processus de recovery avec la commande suivante :

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE/TRUE

 

Maintenant c’est subtil (2012 R2)

Comme c’était pas encore assez compliqué, on change encore. Il faut lire un billet décrivant les changements opérés sur DFSR dans Windows 2012 R2 pour le comprendre :

clip_image002

 

Il faut comprendre que Microsoft a mis à disposition une clé de registre pour configurer le comportement de DFSR dans le scénario du “Dirty shutdown” mais n’a pas réussi à démontrer qu’il y a réellement risque de perte de données. La racine DFS de domaine gui prend en charge la réplication de SYSVOL échappe au processus de “Dirty shutdown”. Seulement pour lui, le recovery redevient automatique. C’est une bonne nouvelle pour les administrateurs Active Directory qui n’ont plus à se soucier du “Dirty shutdown” sur les contrôleurs de domaine Windows Server 2012 R2 (uniquement).

 

Conclusion

J’avais bien annoncé que le sujet était “capilo-tracté”. Donc pour faire simple un petit tableau pour résumer la situation :

  Windows 2008 Windows 2008 R2 (sans KB2663685) Windows 2008 R2 (avec KB2663685) Windows 2012 Windows 2012 R2
Automatic Dirty shutdown recovery pour SYSVOL Oui Oui Non Non Oui

Non sauf reconfiguration avec WMIC

 

BenoîtS – Simple and secure by Design but business compliant

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

Superviser DFS-R efficacement

DFS-R est un sujet complexe. Pour s’en rendre compte, je recommande la lecture du blog de l’équipe en charge de son développement : The File cabinet. J’ai déjà eu l’occasion de présenter la mise en œuvre de DFS-R sous Windows 2008 (un challenge tout en ligne de commande).

Jusqu’à maintenant, la supervision, c’était SCOM ou maîtriser le DFSRDIAG.EXE. Maintenant, c’est plus simple et c’est français en plus. Didier GAUTHIER, PFE chez Microsoft vient de mettre à disposition DFSMON.EXE. Plutôt qu’un long discours, voila à quoi cela ressemble :

DFSRMON

Et surtout où le récupérer : http://blogs.technet.com/domaineetsecurite/archive/2010/04/14/surveillez-en-temps-r-el-la-r-plication-dfsr-gr-ce-dfsrmon.aspx

 

Pour faire court : C’est une excellente initiative, c’est à la fois simple et très complet.

 

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