Sysvol et netlogon partagent l’importance dans Active Directory
> Qu’est-ce que sysvol et son contenu.
Sysvol est un composant important d’Active Directory. Le dossier Sysvol est partagé sur un volume NTFS sur tous les contrôleurs de domaine d’un domaine particulier. Sysvol est utilisé pour fournir les scripts de stratégie et d’ouverture de session aux membres du domaine.
Par défaut, sysvol comprend 2 dossiers
1.Stratégies – (Emplacement par défaut – %SystemRoot%\Sysvol\Sysvol\nom_domaine\Stratégies)
2.Scripts – (lcation par défaut -%SystemRoot%\Sysvol\Sysvol\nom_domaine\Scripts)
Remarque – Nous pouvons continuer et modifier ces emplacements par défaut.
> Imprtance du partage Sysvol.
Sysvol contient 2 dossiers, à savoir les stratégies et les scripts.
Stratégies – Sous le dossier Stratégies, toutes les stratégies de groupe définies dans un domaine particulier existent. Reportez-vous à la capture d’écran
Notez que vous pouvez voir que 3 GPT sont disponibles dans la capture d’écran ci-dessus. Lorsque vous créez une nouvelle stratégie de groupe dans votre Active directory, un ensemble de dossiers est créé sous dossier Stratégies.
Par exemple – Je crée une stratégie appelée désactiver l’économiseur d’écran dans mon domaine et je lie cette stratégie à mon unité d’organisation. Lorsque j’appuie sur le bouton Créer une nouvelle stratégie dans GPMC, Il créera un dossier de nom de GUID sous le dossier de stratégies qui sera associé pour désactiver le GPO de l’économiseur d’écran.
Pour simplifier, la capture d’écran ci-dessus a 3 GPT, ce qui signifie que 3 stratégies de groupe sont présentes dans le test.domaine tld.
Ainsi, lorsque vous apportez des modifications à des objets de stratégie de groupe particuliers, les modifications seront validées dans le dossier de nom de GUID associé sous Sysvol.
Conclusion
L’importance du dossier Sysvol est qu’il contient le GPT, et chaque fois qu’un administrateur apporte des modifications à l’une des stratégies, ces modifications seront validées dans le dossier de nom de GUID associé, puis elles seront répliquées sur tous les contrôleurs de domaine.
> Méthodes de réplication Sysvol.
Sysvol peut être répliqué sur tous les contrôleurs de domaine à l’aide de la réplication du système de fichiers distribué (DFS-R) si le niveau fonctionnel du domaine de ce lien est externe au Wiki TechNet. Il s’ouvrira dans une nouvelle fenêtre. est Windows Server 2008 ou supérieur, ou il est répliqué à l’aide du système de réplication de fichiers (FRS).
Pour FRS, la planification SYSVOL est un attribut associé à chaque objet de jeu de répliques NTFRS et à chaque objet de connexion NTDS. FRS réplique SYSVOL en utilisant les mêmes objets de connexion intrasite et la même planification construits par le KCC pour la réplication Active Directory. FRS utilise deux protocoles de réplication pour SYSVOL :
Connexion SYSVOL au sein d’un site. La connexion est toujours considérée comme activée ; toute planification est ignorée et les fichiers modifiés sont répliqués immédiatement.
Connexion SYSVOL entre les sites. La réplication SYSVOL est initiée entre deux membres intersite au début de l’intervalle de 15 minutes, en supposant que la planification est ouverte. La connexion est traitée comme un calendrier de déclenchement. Le partenaire amont ignore son calendrier et répond à toute demande du partenaire aval. Lorsque la planification se ferme, le partenaire amont ne libère la connexion qu’après que le contenu actuel du journal sortant, au moment de la jointure, a été envoyé et accusé de réception.
> Erreur et problèmes sysvol courants.
A. Les actions Sysvol et Netlogon sont manquantes.
Prenez un senario, lorsque vous ajoutez un nouveau contrôleur de domaine à votre domaine et que vous voyez qu’il n’y a pas de dossier sysvol et netlogon disponible sur le contrôleur de domaine
Remarque – Le partage Netlogon n’est pas un dossier nommé Netlogon sur le contrôleur de domaine. En fait, il s’agit d’un dossier où sont stockés tous les scripts d’ouverture de session. Ainsi, comme mentionné ci-dessus, le dossier Script sous le dossier sysvol agira comme partage Netlogon (Location-%SystemRoot%\sysvol\sysvol\< nom DNS du domaine > \scripts)
Cela se produit principalement si la réplication sysvol borken. Dans certains cas, après l’ajout d’un nouveau contrôleur de domaine, la réplication sysvol peut prendre un certain temps.(Environ vous devez attendre quelques heures).
B. Erreur d’enveloppe de journal
FRS est un système de réplication multi-maîtres qui se charge de répliquer le contenu de Sysvol entre tous les DC du domaine (il peut également répliquer des données normales, mais nous sommes principalement intéressés par la réplication Sysvol dans l’entrée de blog).
Avec des soins et une maintenance appropriés, les FRS Post-SP2 sur W2k3 sont assez stables et bourdonnent joyeusement tant qu’il n’y a pas de condition externe telle qu’une panne de réseau ou des problèmes de disque qui le font tomber en panne (en supposant que les données que vous répliquez ne sont pas complètement impropres à la réplication comme.Fichiers PST, données de profil ou contenu qui change fréquemment).
Le problème FRS le plus fréquent est l’endroit où se produit un Enveloppement de journal; examinons de plus près ce qui se passe lors d’un enveloppement de journal sous le capot.
Le fonctionnement de FRS est qu’il dispose d’une base de données interne contenant tous les fichiers et dossiers qu’il réplique et chacun d’eux a un identifiant global unique (GUID). La dababase contient également un pointeur vers la dernière opération de disque NTFS (dans le Journal USN / Journal NTFS) que le service FRS a traitée.
Si un utilisateur modifie un fichier ou un dossier sur un disque, ce qui suit se produit :
1) l’opération est captée par NTFS et une entrée est effectuée dans le journal NTFS.
2) FRS surveille le journal NTFS pour les modifications et note qu’une modification a été apportée à ce fichier.
3) FRS conserve un enregistrement du dernier événement de journal NTFS qu’il a traité et vérifie s’il l’a déjà traité.
4) S’il ne l’a pas déjà traité, il regarde s’il s’agit d’un fichier qu’il doit répliquer.
5) S’il doit être répliqué, le fichier entre dans le processus normal de mise en scène, de réplication, etc.
6) FRS incrémente l’entrée dans sa base de données sur l’événement de journal NTFS qu’il a traité afin qu’il ne le considère plus.
Maintenant simplify simplifions un peu les choses.
– Notre disque contient un fichier et un dossier (e:\Test et testez.txt).
– Notre journal NTFS a une taille de 10 entrées (la taille de journal NTFS par défaut dans RL est de ~ 512 Mo selon votre niveau OS / SP).
– Notre base de données FRS contient trois entrées
– > un GUID pour E:\test
– > un GUID pour E:\test\test .txt
– > Une référence à la dernière entrée de journal NTFS que nous avons traitée (disons #4)
Opérations normales:
– > Quelqu’un fait une modification pour tester.txt.
– > Le journal NTFS est mis à jour à #5.
– > FRS note que le journal NTFS indique qu’une modification a été apportée au test.txt et il voit qu’il n’a pas traité ce changement.
– > Étape / Répliquez et mettez à jour la base de données FRS pour refléter le fait que nous avons traité cette entrée de journal NTFS.
Maintenant, un administrateur arrête le service FRS pendant 30 minutes.
– Quelqu’un apporte 10 modifications à tester.txt
o Le journal NTFS est mis à jour 20 fois et est maintenant à #24 (rappelez-vous que nous avons une limite de taille de journal des 10 dernières entrées, il faut donc l’enrouler).
o FRS est arrêté afin qu’il ne surveille pas le journal de journal NTFS.
À ce stade, nous avons des modifications sur le disque dont FRS n’est pas au courant. FRS connaît toujours la dernière entrée de journal NTFS qu’il a traitée et il la comparera avec le journal NTFS actuel lors du prochain redémarrage.
La prochaine fois que le service FRS démarre, il voit qu’il a manqué des opérations NTFS sur le disque (il a traité la dernière opération NTFS #4 mais le journal NTFS est maintenant à #24 et nous n’avons qu’un journal qui remonte à 10 entrées, nous manquons donc les opérations #5-#14 de la base de données.
C’est à ce moment que FRS se plaint d’avoir atteint un état d’enveloppe de journal, que le journal de journal NTFS s’est enroulé et qu’il ne connaît pas l’état actuel des choses sur le disque.
L’impact de ceci sur un DC affecté est que FRS ne définira pas la clé de registre IsSysvolReady pour indiquer au service Netlogon que tout va bien, Sysvol ne sera donc pas partagé et le DC ne pourra pas authentifier complètement les utilisateurs tant que la condition d’enveloppe de journal n’aura pas été résolue.
Le partage manuel de Sysvol ou la définition de la clé de registre IsSysvolReady à 1 ne sont pas des méthodes valides pour résoudre ce problème et ne résolvent pas le vrai problème.
Pour que FRS récupère d’une enveloppe de journal, vous devrez essentiellement recommencer à zéro et réinitialiser la base de données FRS et commencer à compter le journal NTFS à partir des valeurs actuelles dont il dispose.
Cela signifie soit :
– Réplication dans les données d’un partenaire entrant existant (approche de restauration d2 ou FRS non autorisée).
– Faire autorité sur vos propres données et laisser tout le monde répliquer à partir de vous (l’approche de restauration d4 ou FRS faisant autorité).
L’approche d2 est assez simple à réaliser, les exigences sont cependant que vous ayez une bonne connexion réseau avec le partenaire de réplication entrant et le temps que cela prendra dépend de la quantité de données à répliquer par rapport à la capacité du lien
En revanche, cela peut ne pas toujours être suffisant et vous pouvez vous retrouver obligé d’opter pour l’option d4.
Ci-dessus sont les erreurs les plus courantes lorsque vous considérez sysvol dans Active Directory.
Enfin quelles sont les étapes que nous pouvons suivre lorsque ces erreurs ci-dessus sont entachées.
> Dépannage des messages d’erreur Sysvol
A. Les actions Sysvol et Netlogon sont manquantes.
Comme je l’ai mentionné précédemment, il peut s’agir d’un problème de réplication sysvol interrompue entre les contrôleurs de domaine.
Comment puis-je forcer la réplication Sysvol dans un active directory
Vous pouvez redémarrer le service FRS pour forcer la réplication FRS
Pour redémarrer le service FRS, lancez des services.msc de l’option Exécuter dans le menu Démarrer
Et redémarrez le service FRS et vous obtiendrez l’ID d’événement 13516 sur le journal des événements FRS cela garantira que l’état FRS est correct.
Réplication Sysvol via NTFRSUTL
Si vous souhaitez forcer la réplication sysvol entre deux contrôleurs de domaine dans un active directory, utilisez la procédure ci-dessous
Option de ligne de commande NTFRSUTL FORCEREPL pour forcer la réplication
Vous pouvez utiliser la nouvelle commande ntfrsutl forcerepl pour appliquer la réplication quel que soit le calendrier de réplication prédéfini. Ceci n’est implémenté que pour le jeu de réplicas Sysvol du contrôleur de domaine.
ntfrsutl forcerepl/r/p
Cette commande force FRS à démarrer un cycle de réplication. Vous devez spécifier l’ordinateur, SetName et DnsName.
Remarque Dans cette commande, les espaces réservés suivants sont utilisés :
= Connectez-vous au service NtFrs sur cette machine.
= Le nom du jeu de répliques.
= Nom DNS du partenaire entrant à partir duquel la réplication est forcée.
Par exemple :
ntfrsutl.exe forcerepl DestinationDC/r « Volume du système de domaine (partage SYSVOL) » /p SourceDC.domain.com
Les guillemets dans cet exemple sont requis lorsque vous utilisez l’option /r. Si les guillemets ne sont pas présents, la commande ne fonctionnera pas.
Si ci-dessus n’aide pas alors,
La méthode la plus populaire pour résoudre ce problème se trouve en dessous de MS KB.
SYMPTÔMES :
Après l’installation des services de domaine Active Directory sur un nouveau contrôleur de domaine complet ou en lecture seule basé sur Windows Server 2008 dans un domaine existant, le partage SYSVOL est présent. Cependant, le partage NETLOGON n’est pas présent sur le nouveau contrôleur de domaine.
Remarque Cet article ne s’applique pas si les partages NETLOGON et SYSVOL sont manquants.
CAUSE:
Ce problème se produit lorsque le service Netlogon lit très rapidement l’indicateur SysvolReady dans le registre. Ensuite, le service Netlogon essaie de partager le dossier \Windows\SYSVOL\domain\scripts avant que le Service de réplication de fichiers NT (NTFRS) ne crée ce dossier.
SOLUTION :
Avertissement De graves problèmes peuvent survenir si vous modifiez le registre de manière incorrecte à l’aide de l’Éditeur de registre ou d’une autre méthode. Ces problèmes peuvent nécessiter la réinstallation du système d’exploitation. Microsoft ne peut pas garantir que ces problèmes peuvent être résolus. Modifiez le registre à vos propres risques.
Pour contourner ce problème, définissez la valeur de registre de l’indicateur SysvolReady sur « 0 », puis sur « 1 » dans le registre. Pour ce faire, procédez comme suit :
– > Cliquez sur Démarrer, cliquez sur Exécuter, tapez regedit, puis cliquez sur OK.
– > Localisez la sous-clé suivante dans l’éditeur de registre :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
– > Dans le volet détails, cliquez avec le bouton droit sur l’indicateur SysvolReady, puis cliquez sur Modifier.
– > Dans la zone Données de valeur, tapez 0, puis cliquez sur OK.
– > Encore une fois dans le volet détails, cliquez avec le bouton droit sur l’indicateur SysvolReady, puis cliquez sur Modifier.
– > Dans la zone Données de valeur, tapez 1, puis cliquez sur OK.
Remarque Cela entraînera le partage de SYSVOL par Netlogon et le dossier scripts sera présent.
PLUS D’INFORMATIONS:
Le problème décrit dans la section « Symptômes » se produit dans le scénario suivant:
NTFRS place d’abord les modifications à l’emplacement suivant:
\Windows\SYSVOL\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory
Ensuite, NTFRS avertit Netlogon de partager SYSVOL en définissant l’entrée de registre SysvolReady Flag sur « 1. »
NTFRS déplace et renomme ensuite les fichiers de l’emplacement mentionné à l’étape 1 vers le dossier suivant :
\Windows\SYSVOL\domain
Cependant, si le service Netlogon lit très rapidement l’entrée d’indicateur SysvolReady dans le registre, le service Netlogon essaie de partager le dossier \Windows\SYSVOL\domain\scripts avant que NTFRS ne crée ce dossier. Par conséquent, le partage NETLOGON n’est pas créé.
D. Erreur d’enveloppe de journal
Si une erreur d’enveloppe de journal se produit, nous pouvons définir une valeur blurflag sur D2 dans le registre d’un contrôleur de domaine où des événements d’erreur d’enveloppe de journal sont générés. Ce faisant, le contrôleur de domaine videra les dossiers préexistants et commencera à répliquer le nouveau contenu de l’un de ses partenaires de réplication FRS.
Ou
Nous pouvons définir blurflag sur D4, ce qui est exactement le contraire de ci-dessus. Autrement dit, lorsque vous définissez D4 sur un contrôleur de domaine spécifique, ses données agiront en tant qu’auteur, Résultat, tous les contrôleurs de domaine de votre domaine se répliqueront à partir du contrôleur de domaine où ce blurflag est défini sur D4
Remarque – Définir BlurFlag sur D4 est la dernière option, 90% des cas seront résolus en configurant blurflag sur D2.
| Articles d’annonces | FAQ Windows |
|---|