Migration SYSVOL de FRS vers DFSR : vérifier chaque DC avant Eliminated

Qu’est-ce que la migration SYSVOL de FRS vers DFSR ?

Une migration SYSVOL de FRS vers DFSR change la manière dont les contrôleurs de domaine répliquent les fichiers utilisés pour les stratégies de groupe et les scripts d’ouverture de session. Cette opération exige une procédure à l’échelle du domaine : établir l’état actuel, valider la réplication sur chaque contrôleur de domaine et n’avancer que lorsque les preuves justifient l’étape suivante.

Revue technique : 4 octobre 2026. Les commandes ci-dessous sont des exemples fondés sur la documentation ; elles n’ont pas été exécutées sur un domaine de production.

File Replication Service (FRS) est déprécié, comme l’indique la documentation Microsoft sur la dépréciation de FRS. DFS Replication (DFSR) est disponible pour SYSVOL à partir du niveau fonctionnel de domaine Windows Server 2008. Le guide actuel de migration de SYSVOL reste le point de départ de la procédure prise en charge.

Traitez cette opération comme un projet de configuration et de disponibilité. Un signal de réplication ancienne n’établit ni une attaque, ni la compromission d’un contrôleur, ni le dysfonctionnement d’une GPO. De même, l’absence de constats ne peut autoriser un changement irréversible. Déterminez les preuves dont le responsable du domaine a besoin avant de planifier l’intervention.

Ce projet s’inscrit dans votre planification de la mise à niveau des contrôleurs de domaine Windows Server 2016, qui couvre les systèmes d’exploitation et les niveaux fonctionnels. Conservez des preuves distinctes pour la migration SYSVOL : remplacer un DC ou examiner son OS ne constitue pas un relevé de l’état de migration de chaque contrôleur.

Fonctionnement : direction globale et convergence locale

L’émulateur PDC détient la direction de migration définie par dfsrmig /setglobalstate. Chaque contrôleur de domaine doit atteindre l’état local correspondant. Une commande qui change la direction globale marque donc le début d’une phase ; elle ne prouve pas que tous les contrôleurs l’ont terminée.

La référence Microsoft des états de migration SYSVOL décrit les étapes stables suivantes :

Les états locaux peuvent être transitoires pendant l’opération. Gardez les contrôleurs hors ligne, injoignables ou encore en transition visibles dans le dossier de migration. Ne les retirez pas de la liste d’acceptation pour donner l’impression que le changement est terminé.

Détection : constituer un relevé des états avant tout changement

Lire l’état global sur l’émulateur PDC

Exécutez cette commande de consultation sur l’émulateur PDC, conformément à la référence de la commande dfsrmig :

dfsrmig /getglobalstate

Recueillez ensuite le rapport de convergence à l’échelle du domaine :

dfsrmig /getmigrationstate

La première commande lit l’état global du domaine. La seconde compare les états locaux à cette direction et signale les contrôleurs qui ne l’ont pas atteinte. La référence de la commande avertit qu’une lecture de l’état global sur un autre contrôleur peut produire des informations incohérentes en raison de la latence de réplication AD.

Interprétation illustrative, et non sortie observée : un état global Prepared avec un contrôleur encore à Start ou dans un état de transition signifie que le jalon Prepared reste ouvert. Un état global Redirected avec tous les états locaux concordants satisfait le contrôle d’état, mais exige encore la validation des partages et de la réplication. Un état global Eliminated sans rapport de convergence exploitable constitue une preuve incomplète, pas un achèvement vérifié.

Pour chaque relevé, consignez le domaine, l’identité du PDC, l’inventaire des contrôleurs, l’heure de collecte, la commande et sa sortie complète. Un contrôleur injoignable doit avoir un responsable et un plan de résolution. Conservez les relevés précédents pour que les relecteurs puissent distinguer une progression d’un changement d’inventaire.

Examiner les preuves d’abonnement LDAP et de services

Le fournisseur etc-collector examiné tente une recherche LDAP dans le sous-arbre sous son DN de base configuré, avec le filtre suivant, en demandant cn et en conservant au plus un résultat côté client :

(&(objectClass=nTFRSSubscriber)(name=Domain System Volume (SYSVOL share)))

Il s’agit du filtre littéral du fournisseur, présenté comme une preuve issue du code, et non comme une commande de client LDAP prête à l’emploi. Dans la révision du collecteur examinée (42bfefb), les parenthèses de la valeur du nom ne sont pas échappées. Un contrôle local du seul parseur avec la dépendance déclarée go-ldap v3.4.12 a renvoyé Filter Compile Error ; la requête de recherche ne peut pas être encodée avec ce filtre. Aucune requête LDAP de production n’a été exécutée pour cette revue.

Ce défaut de collecte laisse l’indicateur FRS à false dans le fournisseur examiné. Même après qu’une requête corrigée a renvoyé avec succès un objet d’abonnement, cet objet ne suffirait pas à identifier tous les contrôleurs, à établir quel service dessert actuellement SYSVOL ou à exclure un vestige de migration.

Sur chaque DC, relevez également dans Services l’état et la configuration de démarrage du service File Replication (NTFRS) et du service DFS Replication (DFSR). Corrélez ces observations avec l’état de migration et la correspondance réelle des partages. Un service en cours d’exécution ne suffit pas à établir que la réplication SYSVOL fonctionne correctement.

Utilisez une petite matrice de preuves plutôt qu’un simple indicateur vert :

Distinguez les échecs de collecte des résultats négatifs dans votre dossier opérationnel. Cet article ne fournit ni requête d’attaque ni identifiant d’événement Windows ; la décision repose ici sur les preuves de migration et de réplication.

Remédiation : franchir les jalons documentés (Remediation)

Étape 1 — Inventaire, prérequis et préparation à la récupération

Désignez le responsable du domaine et l’opérateur du changement. Inventoriez tous les DC inscriptibles et les RODC, y compris les sites distants et les systèmes temporairement hors ligne. Consignez l’émulateur PDC, le niveau fonctionnel, la compatibilité des OS et l’emplacement de SYSVOL. Vérifiez les prérequis à partir du guide de migration actuel et des versions réellement installées.

Avant de commencer, la procédure Microsoft pour l’état Prepared demande des contrôles de santé de la réplication, un espace suffisant pour la copie SYSVOL, le service DFS Replication en cours d’exécution avec démarrage automatique et des sauvegardes de l’état du système. Elle recommande également d’éviter les modifications de GPO et de scripts d’ouverture de session jusqu’à ce que tous les contrôleurs atteignent Redirected.

Documentez les emplacements des sauvegardes et les responsabilités de récupération. Convenez de la manière dont un contrôle en échec suspend le changement, de la personne qui le diagnostique et des preuves permettant la reprise. Ne considérez pas l’existence d’une tâche de sauvegarde comme un test de récupération réussi.

La procédure comprend ces exemples distincts de consultation :

net share

repadmin /ReplSum

Exécutez net share sur chaque DC et examinez les correspondances SYSVOL et NETLOGON. Examinez séparément la réplication AD et la réplication SYSVOL. Résolvez les échecs existants avant de commencer la migration ; une transition d’état ne doit pas devenir une tentative de réparation d’un problème de réplication inexpliqué.

Étape 2 — Jalon Prepared

Exemple modifiant l’état : à utiliser uniquement après les contrôles initiaux et l’approbation du changement. Sur l’émulateur PDC :

dfsrmig /setglobalstate 1

Recueillez de nouveaux rapports d’état global et d’état de migration. Ne poursuivez pas avant que chaque contrôleur ait atteint Prepared. Vérifiez la copie DFSR et sa réplication comme le décrit la procédure Prepared.

Conservez une entrée d’acceptation explicite par contrôleur. Consignez les exceptions restantes avec leur responsable, pas dans une remarque informelle en dehors du dossier de changement. Si un nouveau RODC est introduit pendant la migration, consultez la procédure documentée de traitement des RODC avant de poursuivre ; n’ajoutez pas de commandes génériques de création ou de suppression d’objets à une procédure courante.

Étape 3 — Jalon Redirected

Exemple modifiant l’état : à utiliser uniquement après la convergence Prepared et la validation de santé. Sur l’émulateur PDC :

dfsrmig /setglobalstate 2

La procédure pour l’état Redirected exige des états locaux cohérents avant Eliminated. Validez les correspondances SYSVOL et NETLOGON sur chaque DC et la santé DFSR ; conservez les preuves de santé FRS tant que le retour arrière reste pertinent.

Ajoutez un contrôle d’acceptation opérationnelle : des clients représentatifs dans les sites concernés doivent obtenir les stratégies et scripts attendus. Consignez les clients et stratégies choisis, les heures de collecte et les résultats. Il s’agit d’une tâche de validation proposée, et non d’une affirmation selon laquelle le traitement côté client a été testé pour cet article.

Étape 4 — Approuver Eliminated séparément

La procédure pour l’état Eliminated exige une vérification Redirected réussie et des états cohérents sur tous les contrôleurs. Examinez la réplication AD, conservez des sauvegardes aux états stables et confirmez que le responsable du domaine accepte la perte du retour arrière de migration.

Exemple irréversible modifiant l’état : ce n’est pas une recommandation immédiate pour un domaine inconnu. Sur l’émulateur PDC, uniquement après l’approbation de ce jalon :

dfsrmig /setglobalstate 3

Recueillez de nouveaux rapports d’état global et d’états locaux. Vérifiez à nouveau les correspondances des partages SYSVOL et NETLOGON, la réplication DFSR et le traitement des stratégies. Examinez les éventuels usages restants du service FRS avant son retrait : la procédure Microsoft conditionne l’arrêt et la désactivation de FRS à son utilisation éventuelle pour d’autres besoins que SYSVOL.

Consignez la décision finale et ses preuves, y compris les anomalies non résolues. Ne substituez pas le nettoyage d’un objet LDAP à la vérification à l’exécution.

Comment EtcSec détecte cette configuration

Le contrôle DFSR_NOT_CONFIGURED d’EtcSec est implémenté dans ad/network/dfsr.go d’etc-collector. Sa méthode Detect() évalue les informations de domaine collectées :

Le code associe le niveau 3 à Windows Server 2008. Count est un signal à l’échelle du domaine, pas le nombre de DC concernés. Le fournisseur ne positionne l’indicateur FRS que lorsque sa recherche LDAP limitée réussit et renvoie un objet. Une erreur ou un résultat vide laisse cet indicateur à false sans indicateur distinct d’erreur de collecte dans ce signal. Dans la révision examinée, le filtre mal formé décrit plus haut suit ce chemin d’erreur : ce chemin de collecte laisse UsingNTFRSForSYSVOL à false, donc Detect() renvoie Count 0 même si le domaine utilise effectivement FRS.

Un objet d’abonnement résiduel peut subsister après la migration. Un résultat positif justifie donc de rapprocher LDAP de dfsrmig, des observations des services et des preuves relatives aux partages. Il ne prouve ni le service de réplication effectif ni une attaque.

Le détecteur ne lit ni les états globaux ou locaux dfsrmig, ni la santé DFSR, ni la convergence de réplication, ni les résultats des stratégies côté client. Count 0 ne prouve ni une bonne santé DFSR ni une migration achevée. Le texte de recommandation est un conseil ; il ne signifie pas qu’une commande de santé ou une migration a été exécutée.

Clore le changement par l’hygiène du contenu

Répliquer SYSVOL avec DFSR ne supprime pas les secrets de ses fichiers. Gardez la revue des secrets cPassword des GPO dans SYSVOL comme une tâche distincte portant sur le contenu, avec une gestion des identifiants et un nettoyage sous responsabilité indépendante du changement de réplication.

Conservez un dossier final de preuves contenant l’inventaire, les sauvegardes, l’état initial, les contrôles de convergence et de santé de chaque jalon, la décision Eliminated si elle a été prise et la vérification finale des partages et des stratégies. Rapprochez le résultat du collecteur de ce dossier et documentez toute preuve LDAP périmée ou limite de collecte.

La décision d’achèvement doit pouvoir être examinée par une personne qui n’a pas exécuté les commandes. Si un contrôleur, une observation de service ou un contrôle de stratégie reste non résolu, indiquez explicitement cette limite et gardez l’action opérationnelle correspondante ouverte.