Depuis la version de Windows 2008, la technologie de réplication de fichier a été modifiée. La réplication est réalisée via la technologie DFS-r alors que avant 2008, celle-ci était réalisée avec FRS.
La réplication du répertoire SYSVOL d’Active Directory est réalisée via l’une des deux technologie selon l’historique de l’entreprise.
La migration de FRS vers DFS-R, n’est pas automatiquement réalisée lors des montée de version Active Directory. Pourtant si votre domaine est à minima à un niveau 2008, DFS-R devrait être utilisée. Nous allons voir comment réaliser cette migration lors d’un cas concret.
Dans la migration suivant, le domaine est composé de 12 contrôleurs de domaine. Il n’y a pas de RODC.
Pendant la migration, les GPO et script d’ouverture de session (tout les objets contenu dans le SYSVOL, ne doivent pas être modifiés. Selon la taille de l’entreprise, il est nécessaire de prévoir la communication autour.
Toutes les opérations sont réalisées avec un compte membre des groupes : “Administrateurs de l’entreprise” et “Admins du domaine”.
Sommaire
Prérequis
Avant de commencer l’opération, réaliser une sauvegarde tiers d’Active Directory et du répertoire SYSVOL.
Il est recommandé comme avant toute migration Active Directory de réaliser un diagnostic de celle-ci. Les utilitaires DCDIAD et RepAdmin sont là pour ça.
dcdiag.exe /e /test:sysvolcheck /test:advertising
repadmin.exe /replsum
Vérifier que votre domaine à le niveau fonctionnel suffisant. Le niveau minimum pour le domaine est Windows Server 2008, dans le cas présenté ci-dessous le niveau du domaine est 2008r2. Le niveau fonctionnel de la foret est négligeable, car celui-ci à minima du niveau du domaine ect…
Sauvegarde des GPO
Il est nécessaire de réaliser une sauvegarde de l’ensemble des GPO dans un format facilement restaurable.
Soit en Powershell selon la version disponible.
Import-Module ActiveDirectory
Backup-GPO -All -Path "C:\temp\BackupGPO"
Ou en utilisant la console gpmc.msc
Vérifier l'espace libre sur les contrôleurs de domaine
Il est important qu’un contrôleur de domaine ne soit jamais à court d’espace libre. Lors de la migration, le répertoire SYSVOL va être copier, ce qui va selon le volume utilisé par celui-ci engendrer surconsommation temporaire de l’espace libre.
Le script Powershell permet de vérifier l’espace disponible sur les contrôleurs de domaine :
Import-Module ActiveDirectory
$Result=@()
$LstDCInDomain=Get-ADDomainController -Filter * | Select-Object HostName
foreach($DC in $LstDCInDomain){
$volConDC=""
$LstvolConDC=Get-WmiObject -Query "SELECT systemname,DeviceID,FreeSpace FROM win32_logicaldisk" -ComputerName $DC.Hostname
foreach($volConDC in $LstvolConDC){
$ObjectUser = New-Object System.Object
$ObjectUser | Add-Member -Type NoteProperty -Name HostName -Value $volConDC.systemname
$ObjectUser | Add-Member -Type NoteProperty -Name Drive -Value $volConDC.DeviceID
$ObjectUser | Add-Member -Type NoteProperty -Name GB_Free -Value $([math]::round($volConDC.FreeSpace/1GB, 2))
$Result+=$ObjectUser
}
}
$Result | FT
Vérification du niveau fonctionnel
Import-Module ActiveDirectory
(Get-ADForest).ForestMode
(Get-ADDomain).DomainMode
Identification du PDC
Par habitude, je réalise ce type d’opération depuis le contrôleur de domaine depuis de PDC.
netdom query fsmo
S'assurer que la réplication est toujours en FRS
Vérifier que la réplication SYSVOL est toujours en FRS et n’a pas encore commencée
dfsrmig /getmigrationstate
S'assurer que le service DFS-R est démarré sur tous les DC
Vérifier ensuite que tous les contrôleurs de domaine aient le service “DFSR” de démarré.
Import-Module ActiveDirectory
$Result=@()
$LstDCInDomain=Get-ADDomainController -Filter * | Select-Object HostName
foreach($DC in $LstDCInDomain){
$DFSRServiceState=Get-Service -Name DFSR -ComputerName $DC.HostName
$ObjectUser = New-Object System.Object
$ObjectUser | Add-Member -Type NoteProperty -Name HostName -Value $DC.HostName
$ObjectUser | Add-Member -Type NoteProperty -Name ServiceName -Value $DFSRServiceState.Name
$ObjectUser | Add-Member -Type NoteProperty -Name Status -Value $DFSRServiceState.Status
$Result+=$ObjectUser
}
$Result | FT
Vérification de l'état des réplications SYSVOL
Vérifier que la réplication du SYSVOL fonctionne bien.
RepAdmin /ReplSum
Migration
La migration s’effectue avec l’outil DFSRMIG.EXE, celle-ci s’effectue en 4 étapes numérotées de 0 à 3.
La documentation de l’utilitaire DFSMIGR est disponible à l’adresse :
Étape 0 : initialisation de la migration
La première étape (l’étape 0) initie la migration.
dfsrmig /getmigrationstatedfsrmig /setglobalstate 0
dfsrmig /getmigrationstate
Étape 1 : préparation du SYSVOL
La préparation du SYSVOL est presque l’étape la plus longue de l’upgrade. Pendant cette étape, un nouveau répertoire “SYSVOL_DFSR” est créé sur chaque contrôleur de domaine, le contenu du SYSVOL actuel est copié dans ce nouveau répertoire puis la réplication DFS-R initiale est lancée.
dfsrmig.exe /setGlobalState 1
Le monitoring de cette étape et le contrôle de son succès doit être réalisé avec la commande :
dfsrmig.exe /getmigrationstate
Dès que l’emsemble des contrôleurs de domaine sont prêt (dans ce cas ci cette étape à duré 1 heure), vous obtenez l’état :
Sur chaque contrôleur de domaine, nous pouvons constater que :
- Il existe un répertoire C:\Windows\SYSVOL\
- Il esiste un répertoire C:\Windows\SYSVOL_DFSR\
- Le partage SYSVOL pointe encore sur C:\Windows\SYSVOL\
Get-ChildItem C:\Windows\SYSVOL*
net share
L’étape 1 de la migration est maintenant terminée.
Étape 2 : préparation du SYSVOL
Dans l’étape 2 de la migration à pour but de rediriger le partage SYSVOL de tous les contrôleurs de domaine vers le “nouveau répertoire SYSVOL” qui est répliqué via DFS-R (C:\Windows\SYSVOL_DFSR\sysvol).
dfsrmig.exe /setGlobalState 2
Cette étape va durer quelques minutes, elle-ci doit être monitorer (comme l’étape précédente) via la commande :
dfsrmig.exe /getmigrationstate
Lorsque sur tous les contrôleurs de domaine le répertoire SYSVOL est redirigé (dans ce cas ci cette étape à duré 30 minutes), vous obtenez l’état :
Sur chaque contrôleurs de domaine, nous pouvons constater que :
- Il existe un répertoire C:\Windows\SYSVOL\
- Il esiste un répertoire C:\Windows\SYSVOL_DFSR\
- Le partage SYSVOL pointe désormais sur C:\Windows\SYSVOL_DFSR\
Get-ChildItem C:\Windows\SYSVOL*
net share
Import-Module ActiveDirectory
$Result=@()
$LstDCInDomain=Get-ADDomainController -Filter * | Select-Object HostName
foreach($DC in $LstDCInDomain){
$ShareSYSVOL=""
$ShareSYSVOL=get-WmiObject -class Win32_Share -computer $DC.HostName -filter "Name LIKE 'SYSVOL'"
$ObjectUser = New-Object System.Object
$ObjectUser | Add-Member -Type NoteProperty -Name HostName -Value $DC.HostName
$ObjectUser | Add-Member -Type NoteProperty -Name ShareName -Value $ShareSYSVOL.Name
$ObjectUser | Add-Member -Type NoteProperty -Name Location -Value $ShareSYSVOL.Path
$Result+=$ObjectUser
}
$Result | FT
L’étape 2 est terminée et avec succès, next step.
Étape 3 : élimination de FRS
La dernière étape de la migration consiste à la suppression définitive du répertoire SYSVOL réplique par FRS : C:\Windows\SYSVOL\
dfsrmig.exe /setGlobalState 3
Comme lors des étapes précédentes, cette opération est à monitorer toujours avec la commande :
dfsrmig.exe /getmigrationstate
Lorsque l’étape 3 est terminée (dans ce cas ci cette étape à duré 30 minutes), vous obtenez l’état :
Nous pouvons constater que l’étape 3 à :
- Supprimer le répertoire : C:\Windows\SYSVOL\
- Le nouveau répertoire SYSVOL est : C:\Windows\SYSVOL_DFSR\
- Le partage SYSVOL pointe sur : C:\Windows\SYSVOL_DFSR\
- Le sercice FRS est arrêté et désactivé sur tous les contrôleurs de domaine.
Get-ChildItem C:\Windows\SYSVOL*
net share
Import-Module ActiveDirectory
$Result=@()
$LstDCInDomain=Get-ADDomainController -Filter * | Select-Object HostName
foreach($DC in $LstDCInDomain){
$NTFRSServiceState=Get-WmiObject -Class Win32_Service -Property Name,StartMode,State -Filter "Name='NTFRS'"
$ObjectUser = New-Object System.Object
$ObjectUser | Add-Member -Type NoteProperty -Name HostName -Value $DC.HostName
$ObjectUser | Add-Member -Type NoteProperty -Name ServiceName -Value $NTFRSServiceState.Name
$ObjectUser | Add-Member -Type NoteProperty -Name State -Value $NTFRSServiceState.State
$ObjectUser | Add-Member -Type NoteProperty -Name StartMode -Value $NTFRSServiceState.StartMode
$Result+=$ObjectUser
}
$Result
La migration est terminée !
Vérification post migration
Vérifier si l’état de la réplication DFR-R du SYSVOL a été initialisée avec la commande (CMD) l’état doit être à 4 . Si après quelques heures ce n’est pas le cas, il est nécessaire de pousser le diagnostic :
For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state
Pour le dépannage, le lien ci-dessous peut vous aider :
Vérifier l’état de la réplication du SYSVOL.
RepAdmin /ReplSum
Un dernier test est possible via la console de management DFS, celle-ci n’est pas installée par défaut sur les contrôleurs de domaine. Pour l’installer utiliser la commande Powershell suivante.
Add-WindowsFeatures RSAT-DFS-Mgmt-ConIl s’agit de la console de management DFS standard “dfsmgmt.msc”, car maintenant le SYSVOL est répliqué par DFS-R. Cette réplication bien que déclarée sur des contrôleurs de domaine, n’est qu’une “simple” réplication DFS-R standard qui peut être administrée comme toute réplication DFS-R. Et qui peut aussi dysfonctionné comme toute réplication DFS-R.
Selon le nombre de membres que comporte votre infrastructure, le rapport peut mettre plusieurs minutes à être généré.
Erreurs rencontrées
Erreur : ID 6804
Après la migration le rapport DFS-R affiche l’erreur suivante :
Cette erreur n’est pas inquiétante, Microsoft la reconnue comme faux positif.
Cette même erreur se retrouve aussi dans l’observateur d’événements Windows / Réplication DFS
Le service de réplication DFS a détecté qu’aucune connexion n’est configurée pour le groupe de réplication Domain System Volume.
Aucune donnée n’est répliquée pour ce groupe de réplication.
Informations supplémentaires :
ID du groupe de réplication : D3DD793C-C56B-408C-A81A-0FCF34D4A9A3
ID du membre : 91EA4C9B-54C8-49C6-BDC7-11DE9281DD91
Résolution : Redémarrer le service DFS-R ou le serveur.
Avertissement : "L’espace disque du volume C: est insuffisant"
Cet avertissement ne généré pas d’événement dans l’observateur d’événements , le message est plutôt clair, le lecteur est plein et il va falloir corriger cela.
Avertissement : ID 1004
Cette avertissement n’a rien d’alarmant, il indique juste que le service DFS-r a été redémarré plusieurs fois pendant la dernière semaine. En post migration du SYSVOL, cet avertissement n’est pas normal, mais si vous vérifier l’état des réplications plusieurs jours après la migration et que vos contrôleurs de domaine ont redémarré (ici cas d’une migration donc plusieurs reboot successifs) cet avertissement est négligeable.
Ce même événement se retrouve dans le journal d’événements Windows.
Cas RODC
Ce cas n’a pas été rencontré pour l’instant, mais si votre domaine possède des contrôleurs de domaine en lecture seule, il est nécessaire de prendre connaissance du Kb ci-dessous :
Et pour finir
Il peut rester un fichier de test de réplication FRS dans le format “CheckFRSRepl_XXXXXXXXX” localisé dans le répertoire :
\\domaine.name\SYSVOL\domaine.name\
Comme le dit son contenu, il doit être supprimé.
Le répertoire SYSVOL des futurs DC ajoutés dans le domaine auront le partage SYSVOL stockés à l’emplacement “C:\windows\SYSVOL\”.
Le répertoire “C:\windows\SYSVOL_DFSR\”, n’est présent que sur les DC qui étaient présent lors de la migration.
Bonjour,
y a t’il, à un moment donné, une rupture de service du SYSVOL et si oui combien de temps peut-elle durer?
Nous avons des scripts d’ouvertures de session qui configurent l’accès aux imprimantes et au proxy dans le SYSVOL, est-ce que les utilisateurs vont être perturbés et pendant combien de tps environ?
Merci pour vos réponses
Joli tutoriel!!
Cordialement
Thomas ARLOT
Bonjour,
Oui, il y a une petite interruption lors de la bascule entre l’ancien (SYSVOL) et nouveau (SYSVOL_DFSR) partage sur les DC (step 2).
Je n’ai jamais chronométré le temps que dure la bascule.
Par contre, Tous les DC ne basculent pas en même temps donc le sysvol est toujours accessible sur un second DC.
J’ai déjà réalisé cette migration un petit paquet de fois, en journée, je n’ai pas remarqué ou eu de retour sur une indispo du Sysvol.
Par contre, il est impératif d’attendre la fin de chaque étape avant de lancer la suivante.
Quand vous allez lancer une des étapes de migration avec “dfsrmig.exe /setGlobalState X”, le prompt est libéré instantanément sans vous indiquer que l’étapes est terminée ou pas, a vous de vérifier.
J’ai déjà eu le cas où, les étapes sont lancées successivement sans que la précédente ne soit terminée et là par contre, il y perte du Sysvol.
J’espère avoir répondu à vos questions.
Merci 🙂
Cordialement
Oui merci beaucoup pour vos précisions et retour d’expérience.
Je n’ai plus qu’à planifier cela!
Cordialement
Bonjour,
je n’ai pas encore pris le temps d’effectuer la migration, mais je compte le faire avant la fin de ce mois-ci. Une petite interrogation me reste : Nous avons encore le parc informatique, 2 machines sous “windows XP” hébergeant des applications spécifiques. Est-ce que ces machines pourront enocre s’authentifier sur le domaine après migration du sysvol en Dfsr?
Cordialement
Bonjour,
Aucun souci pour les machines en XP.
Vous ne modifier que la réplication du Sysvol entre les DC, il n’y a pas de modification concernant les protocoles d’authentification ou autre pour les clients.
Cordialement
Bonjour,
je viens d’effectuer la migration! Cela a mis pas mal de temps, mais tout c’est déroulé correctement.
Merci pour les informations et ce super tutoriel!
Cordialement
Bonjour,
J’ai un nouveau contrôleur de domaine (arrivé post migration sysvol_dfsr) qui pointe sur SYSVOL au lieu de SYSVOL_DFSR (dossier SYSVOL_DFSR absent sur C:\windows et dans la console DFSR le chemin est c:\windows\sysvol, contrairement à tous les autres DC du domaine)
Savez vous quelle manipulation est à effectuer dans le cas d’un nouveau contrôleur de domaine qui arrive dans une infra déjà migrée?
Merci de votre aide
Bonjour,
Si je reprends votre contexte, vous avez :
– Réalisé une migration du “SYSVOL” FRS –> DFSR.
– Tous les DC ont leurs “SYSVOL” dans un répertoire : “C:\windows\SYSVOL_DFSR\”
– Vous ajoutez un nouveau DC.
– Le répertoire “SYSVOL” du nouveau DC est dans : “C:\windows\SYSVOL\”
Si cela est le cas, je vous confirme que ce comportement est normal.
Le répertoire “SYSVOL_DFSR” n’est créé que sur les DC qui ont subit la migration FRS –> DFSR.
Votre nouveau DC est arrivé après la migration, par défaut le SYSVOL est dans “C:\windows\SYSVOL\”.
Pour moi, votre nouveau DC doit répliquer par défaut en DFSR.
En me basant sur vos observations, le répertoire du nouveau DC est bien présent dans le membre de réplication de votre domaine (visible depuis la console DFS-R).
Vous pouvez vérifier le contenu du répertoire “C:\windows\SYSVOL\” sur votre nouveau DC, celui-ci doit avoir son contenu identique aux autres DC.
Je viens d’apporté la précision en bas du post, merci du retour.
Si je n’ai pas apporté la bonne réponse, n’hésitez pas à me faire un retour.
Merci
Merci pour le retour.
Effectivement le contenu du SYSVOL\domain sur ce DC est bien le même que sur SYSVOL_DFSR\domain sur les autres DC.
Je pense que l’erreur vient du fait que j’ai laissé le dossier par defaut c\windows\sysvol\ lorsque j’ai promu le controleur de domaine.
Par contre quand je fais un test de réplication avec dcdiag.exe /test:services il rapporte l’erreur comme quoi le service ntfrs est désactivé, ce qui est aussi le cas sur les autres DC dont la commande ne rapporte pas d’erreur. Comme si dans sa base il s’agit toujours du ntfrs qui est utilisé…Du coup j’ai un doute
Bonjour,
Effectivement le contenu du SYSVOL\domain sur ce DC est bien le même que sur SYSVOL_DFSR\domain sur les autres DC.
C’est tout bon, les réplication via DFSR fonctionnent.
Je pense que l’erreur vient du fait que j’ai laissé le dossier par defaut c\windows\sysvol\ lorsque j’ai promu le controleur de domaine.
Non, ce n’est pas une erreur, vous avez bien fait de laisser le répertoire par défaut. Juste si vous avez la possibilité pour les prochaines fois de déplacer le SYSVOL sur un lecteur dédier, c’est encore mieux.
Par contre quand je fais un test de réplication avec dcdiag.exe /test:services il rapporte l’erreur comme quoi le service ntfrs est désactivé, ce qui est aussi le cas sur les autres DC dont la commande ne rapporte pas d’erreur. Comme si dans sa base il s’agit toujours du ntfrs qui est utilisé…Du coup j’ai un doute.
Curieux, j’essaie de vérifier sur un DC sans tarder, je ne vois pas de raison pour avoir une erreur sur le service FRS …
Merci
Benoit