Aller au contenu

SYSVOL : réplication et structure

Ce que couvre ce chapitre

  • Structure physique complète du répertoire SYSVOL et rôle de chaque sous-dossier
  • Encodage 32 bits du fichier GPT.INI et son rôle de marqueur de synchronisation GPC/GPT
  • Différences techniques entre FRS (déprécié) et DFS-R, et procédure de migration par états
  • Commandes de diagnostic de santé SYSVOL : backlog, accessibilité, intégrité des GPT
  • Permissions NTFS minimales requises sur le dossier Policies et impact en production
  • Détection des GPT orphelins (dossiers SYSVOL sans objet AD correspondant)
  • IDs d'événements Windows critiques pour la surveillance de la réplication SYSVOL

Si vous ne retenez qu'une chose

Sans SYSVOL cohérent et répliqué, une GPO existe dans l'annuaire mais ne dispose pas du contenu que les clients doivent traiter.


Structure physique de SYSVOL

Le partage SYSVOL

SYSVOL est un dossier partagé répliqué présent sur tous les contrôleurs de domaine.

Il est exposé sous deux partages UNC distincts :

  • \\<domaine>\SYSVOL — accès complet à l'arborescence SYSVOL
  • \\<domaine>\NETLOGON — raccourci vers le sous-dossier scripts\, utilisé pour les scripts d'ouverture de session

Le chemin physique sur le DC est %SystemRoot%\SYSVOL\. Ce chemin est configurable lors de la promotion du DC, mais il est rarement modifié en production.

Junction point

Le dossier %SystemRoot%\SYSVOL\domain\ n'est pas un vrai dossier. C'est un point de jonction NTFS qui pointe vers %SystemRoot%\SYSVOL\sysvol\<domaine>\. Ce mécanisme permet à \\<domaine>\SYSVOL de fonctionner sans connaître le nom de domaine en dur dans le chemin UNC.


Arborescence complète

L'arborescence ci-dessous représente un déploiement standard avec un domaine contoso.local :

%SystemRoot%\SYSVOL\
├── domain\                          ← Junction → sysvol\contoso.local\
├── staging\                         ← Zone de transit DFS-R (fichiers en cours de réplication)
├── staging areas\                   ← Zones de transit par groupe de réplication
└── sysvol\
    └── contoso.local\
        ├── Policies\
        │   ├── {31B2F340-016D-11D2-945F-00C04FB984F9}\   ← Default Domain Policy
        │   │   ├── GPT.INI
        │   │   ├── Machine\
        │   │   │   ├── Registry.pol
        │   │   │   ├── Microsoft\Windows NT\SecEdit\GptTmpl.inf
        │   │   │   └── Scripts\
        │   │   │       ├── Startup\
        │   │   │       └── Shutdown\
        │   │   └── User\
        │   │       ├── Registry.pol
        │   │       └── Scripts\
        │   │           ├── Logon\
        │   │           └── Logoff\
        │   └── {6AC1786C-016F-11D2-945F-00C04fB984F9}\   ← Default Domain Controllers Policy
        │       ├── GPT.INI
        │       ├── Machine\
        │       └── User\
        ├── scripts\                 ← Netlogon scripts (accessible via \\domaine\NETLOGON)
        └── StarterGPOs\             ← Templates de Starter GPO

Chaque GPO possède son propre sous-dossier dans Policies\, nommé par son GUID. Ce GUID est identique à celui du GPC stocké dans Active Directory.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Arborescence complète - l'artefact technique à savoir relire sans chercher : contoso.local - la commande ou l'étape de validation à pouvoir rejouer en labo : %SystemRoot%\SYSVOL\

GUIDs des GPO intégrées

Deux GPO existent dans tout domaine Active Directory depuis la création. Leurs GUIDs sont fixes et identiques dans tous les domaines :

GUID GPO
{31B2F340-016D-11D2-945F-00C04FB984F9} Default Domain Policy
{6AC1786C-016F-11D2-945F-00C04fB984F9} Default Domain Controllers Policy

Ces GUIDs étant connus, des outils d'audit et des scripts peuvent les cibler directement sans interroger AD. C'est aussi une surface d'attaque connue : ces deux GPO sont des cibles prioritaires en cas de compromission d'un DC.

Ne pas modifier les GPO par défaut

La bonne pratique est de ne jamais modifier la Default Domain Policy ni la Default Domain Controllers Policy. Créer des GPO dédiées à la place. En cas de corruption, la restauration d'une GPO par défaut est complexe (utiliser dcgpofix.exe en dernier recours).


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - les repères de lecture du tableau précédent : GUID, GPO - l'artefact technique à savoir relire sans chercher : {31B2F340-016D-11D2-945F-00C04FB984F9} - le second repère technique à retenir avant de continuer : {6AC1786C-016F-11D2-945F-00C04fB984F9}

Rôle du dossier staging

Le dossier staging\ est utilisé par DFS-R comme zone de transit. Les fichiers modifiés y sont copiés avant d'être envoyés aux partenaires de réplication.

La taille par défaut de la zone de staging est de 4 Go. Sur un environnement avec de nombreuses GPO ou des scripts volumineux, cette limite peut être atteinte. Quand c'est le cas, DFS-R ralentit drastiquement.

Zone de staging saturée

Un journal d'événements DFS-R plein de warnings ID 2012 ou 2013 indique que la zone de staging est insuffisante. Augmenter la limite via les propriétés du groupe de réplication dans la console DFS Management ou via PowerShell.


En résumé

SYSVOL est une arborescence physique sur chaque DC, exposée via deux partages UNC. Chaque GPO y occupe un sous-dossier nommé par son GUID. Le dossier domain\ est un point de jonction NTFS, pas un vrai répertoire. Les deux GPO intégrées ont des GUIDs universellement connus.


GPT.INI : le marqueur de synchronisation

Rôle du fichier

GPT.INI est un fichier de configuration INI minimaliste présent à la racine de chaque dossier GPT dans SYSVOL.

Il joue un rôle central : le numéro de version qu'il contient doit être identique à l'attribut versionNumber du GPC correspondant dans Active Directory. Quand les deux valeurs divergent, le client détecte que la GPO a été modifiée et la retraite.

Ce mécanisme est décrit en détail dans le chapitre 02. Ce chapitre se concentre sur l'encodage du numéro de version et les opérations SYSVOL.


Format du fichier

[General]
Version=131073
displayName=New Group Policy Object

Le fichier contient typiquement deux clés. displayName est le nom lisible de la GPO. Version est l'entier critique.

Encodage 32 bits

Version est un entier 32 bits non signé. Il encode deux compteurs indépendants dans un seul entier, via une convention de mots haut et bas.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Format du fichier - l'artefact technique à savoir relire sans chercher : displayName - la commande ou l'étape de validation à pouvoir rejouer en labo : [General]

Encodage du numéro de version

L'entier 32 bits est divisé en deux mots de 16 bits :

Bits Mot Signification
0–15 (mot bas, low word) Machine version Incrémenté à chaque modification de la Configuration ordinateur
16–31 (mot haut, high word) User version Incrémenté à chaque modification de la Configuration utilisateur

Exemple : Version=131073

131073 en hexadécimal = 0x00020001

High word (bits 16-31) = 0x0002 = 2  → User Configuration modifiée 2 fois
Low word  (bits 0-15)  = 0x0001 = 1  → Machine Configuration modifiée 1 fois

Lorsqu'on modifie uniquement la configuration ordinateur d'une GPO, seul le mot bas est incrémenté. Le mot haut reste inchangé. Cette granularité permet au client de ne retraiter que la moitié pertinente de la GPO.

Incréments séparés

Les CSE Machine et User sont traités indépendamment. Un client qui ne traite que la configuration utilisateur (ex. : traitement en arrière-plan utilisateur) peut ignorer un changement de version du mot bas si le mot haut n'a pas changé.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - les repères de lecture du tableau précédent : Bits, Mot, Signification - l'artefact technique à savoir relire sans chercher : Version=131073 - la commande ou l'étape de validation à pouvoir rejouer en labo : 131073 en hexadécimal = 0x00020001

PowerShell : décoder les versions de toutes les GPO

Résultat attendu
# Read and decode GPT.INI version numbers for all GPOs in the domain
# Returns a table with GUID, raw version, and decoded machine/user counters

$sysvolPolicies = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies"

Get-ChildItem $sysvolPolicies -Filter "GPT.INI" -Recurse | ForEach-Object {
    $content   = Get-Content $_.FullName
    $rawLine   = $content | Where-Object { $_ -match "^Version=" }
    $version   = [int]($rawLine -replace "Version=", "")
    $guid      = $_.DirectoryName | Split-Path -Leaf

    [PSCustomObject]@{
        GUID           = $guid
        RawVersion     = $version
        MachineVersion = $version -band 0xFFFF
        UserVersion    = ($version -shr 16) -band 0xFFFF
    }
} | Sort-Object GUID | Format-Table -AutoSize

# Expected output:
# GUID                                   RawVersion  MachineVersion  UserVersion
# ----                                   ----------  --------------  -----------
# {31B2F340-016D-11D2-945F-00C04FB984F9}     196608               0            3
# {6AC1786C-016F-11D2-945F-00C04fB984F9}      65537               1            1
# {A1B2C3D4-...}                              131073               1            2

Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : PowerShell : décoder les versions de toutes les GPO - la valeur, le GUID ou le paramètre qui change réellement le résultat dans PowerShell : décoder les versions de toutes les GPO - la commande ou l'étape de validation à pouvoir rejouer en labo : $sysvolPolicies = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies"

Comparer GPT.INI avec l'attribut AD versionNumber

Une divergence entre GPT.INI et l'attribut versionNumber du GPC dans AD indique une réplication partielle (SYSVOL ou AD en retard).

Résultat attendu
# Cross-check GPT.INI version against AD GPC versionNumber
# Identifies GPOs where SYSVOL and AD are out of sync

Import-Module GroupPolicy
Import-Module ActiveDirectory

$domain       = $env:USERDNSDOMAIN
$sysvolBase   = "\\$domain\SYSVOL\$domain\Policies"
$gpoPoliciesOU = "CN=Policies,CN=System," + (Get-ADDomain).DistinguishedName

Get-ADObject -SearchBase $gpoPoliciesOU -Filter { ObjectClass -eq "groupPolicyContainer" } `
    -Properties DisplayName, versionNumber, Name | ForEach-Object {

    $guid       = $_.Name
    $adVersion  = $_.versionNumber
    $gptPath    = "$sysvolBase\$guid\GPT.INI"

    $gptVersion = $null
    if (Test-Path $gptPath) {
        $line       = Get-Content $gptPath | Where-Object { $_ -match "^Version=" }
        $gptVersion = [int]($line -replace "Version=", "")
    }

    [PSCustomObject]@{
        GPO         = $_.DisplayName
        GUID        = $guid
        AD_Version  = $adVersion
        GPT_Version = $gptVersion
        InSync      = ($adVersion -eq $gptVersion)
    }
} | Where-Object { -not $_.InSync } | Format-Table -AutoSize

# Expected output (if all in sync, no rows):
# GPO                  GUID          AD_Version  GPT_Version  InSync
# ---                  ----          ----------  -----------  ------
# Firewall - Servers   {A1B2C3...}        65538        65537   False

Désynchronisation persistante

Si la même GPO apparaît systématiquement désynchronisée après plusieurs cycles de réplication (>30 min), ce n'est pas un simple retard. Vérifier l'état de réplication DFS-R et l'état de réplication AD entre les DCs concernés.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Comparer GPT.INI avec l'attribut AD versionNumber - l'artefact technique à savoir relire sans chercher : GPT.INI - la commande ou l'étape de validation à pouvoir rejouer en labo : Import-Module GroupPolicy

En résumé

GPT.INI contient un entier 32 bits qui encode deux compteurs de version indépendants : machine (bits 0-15) et utilisateur (bits 16-31). Ce numéro doit être identique à l'attribut versionNumber du GPC dans AD. Une divergence persistante signale une réplication défaillante.


FRS vs DFS-R : comprendre la migration obligatoire

File Replication Service (FRS) — déprécié et supprimé

FRS était le mécanisme de réplication SYSVOL originel, introduit avec Windows 2000.

Il présentait des limitations structurelles importantes :

  • Aucun mécanisme de throttling de bande passante
  • Résolution de conflits par "dernier-écrivant-gagne" — comportement non déterministe sous charge
  • Pas de journalisation des conflits exploitable en production
  • Architecture monolithique difficile à diagnostiquer

FRS a été supprimé dans Windows Server 2022. Un domaine dont la réplication SYSVOL est encore assurée par FRS ne peut pas promouvoir un DC sous Server 2022 ou ultérieur. C'est un bloquant dur.

FRS = dette technique critique

Si votre domaine a été créé sous Windows Server 2003 ou 2008 et n'a jamais été migré, il est possible que FRS soit encore actif. Vérifier immédiatement avec dfsrmig /getmigrationstate.


DFS-R (Distributed File System Replication)

DFS-R remplace FRS à partir de Windows Server 2008 (facultatif) et Server 2008 R2 (recommandé). Il est obligatoire à partir de Server 2022.

Avantages techniques par rapport à FRS :

  • Compression différentielle (RDC) — seuls les blocs modifiés sont transférés
  • Throttling de bande passante configurable par plage horaire
  • Détection de conflits basée sur les USN (Update Sequence Numbers) NTFS
  • Surveillance via dfsrdiag.exe, WMI et le journal d'événements dédié
  • Staging area avec taille configurable
  • Intégration dans la console DFS Management (dfsmgmt.msc)

Groupe de réplication SYSVOL

Sous DFS-R, SYSVOL est géré comme un groupe de réplication nommé "Domain System Volume" avec un dossier répliqué nommé "SYSVOL Share". Ces noms apparaissent dans les commandes dfsrdiag et dans les journaux d'événements.


Les quatre états de migration

La migration de FRS vers DFS-R utilise l'outil dfsrmig.exe et progresse à travers quatre états numérotés. La progression est unidirectionnelle — il n'existe pas de chemin de retour automatisé à partir de l'état REDIRECTED.

État Valeur Description
START 0 FRS réplique SYSVOL. État initial sur les domaines anciens.
PREPARED 1 DFS-R est initialisé. FRS et DFS-R fonctionnent en parallèle.
REDIRECTED 2 DFS-R est autoritaire. FRS continue de tourner mais ne gère plus SYSVOL.
ELIMINATED 3 FRS est arrêté et supprimé. Uniquement DFS-R.

La transition entre états est commandée depuis le PDC Emulator. Elle se propage à tous les DCs via la réplication AD. Chaque DC doit atteindre l'état cible avant que la transition globale soit considérée complète.

Ne pas précipiter la migration

Attendre que tous les DCs aient atteint l'état courant avant de passer à l'état suivant. Avancer trop vite avec un DC hors ligne peut créer une situation où DFS-R est autoritaire mais un DC est encore sur FRS.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - les repères de lecture du tableau précédent : État, Valeur, Description - l'artefact technique à savoir relire sans chercher : dfsrmig.exe - le second repère technique à retenir avant de continuer : START

Procédure de migration

Résultat attendu
# Step 1: Check current global migration state across all DCs
# Run from PDC Emulator or any DC with RSAT

Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    $result = Invoke-Command -ComputerName $dc -ScriptBlock {
        (Get-WmiObject -Namespace "root\MicrosoftDFS" `
            -Class "DfsrMachineConfig" `
            -ErrorAction SilentlyContinue).SysvolReady
    } -ErrorAction SilentlyContinue

    [PSCustomObject]@{
        DC          = $dc
        SysvolReady = $result
        Site        = $_.Site
    }
} | Format-Table -AutoSize

# Expected output:
# DC               SysvolReady  Site
# --               -----------  ----
# dc01.contoso.com        True  Default-First-Site-Name
# dc02.contoso.com        True  Paris
# dc03.contoso.com        True  Lyon
Résultat attendu
# Step 2: Get global migration state (run on PDC Emulator)
dfsrmig /getmigrationstate

# Expected output when all DCs are at ELIMINATED (state 3):
# All Domain Controllers have migrated successfully to Global state
# ('Eliminated'). SYSVOL is now replicated by DFS Replication.
#
# Migration has reached a consistent state on all Domain Controllers.
# Succeeded.
Commandes de transition (PDC Emulator uniquement)
# Advance migration to PREPARED state — both FRS and DFS-R active
dfsrmig /setglobalstate 1

# Advance to REDIRECTED — DFS-R becomes authoritative
dfsrmig /setglobalstate 2

# Advance to ELIMINATED — FRS stopped permanently
dfsrmig /setglobalstate 3

Commande irréversible

dfsrmig /setglobalstate 3 est irréversible. Une fois à l'état ELIMINATED, FRS ne peut pas être réactivé sans une intervention lourde (restauration depuis sauvegarde ou réinitialisation SYSVOL). Vérifier l'état de tous les DCs avec dfsrmig /getmigrationstate avant d'avancer.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Procédure de migration - l'artefact technique à savoir relire sans chercher : dfsrmig /setglobalstate 3 - la commande ou l'étape de validation à pouvoir rejouer en labo : Get-ADDomainController -Filter * | ForEach-Object {

Vérifier que DFS-R est bien actif

Résultat attendu
# Verify DFS-R replication group exists for SYSVOL
# This command should return results on a properly migrated domain

Get-WmiObject -Namespace "root\MicrosoftDFS" -Class "DfsrReplicationGroupConfig" |
    Where-Object { $_.ReplicationGroupName -eq "Domain System Volume" } |
    Select-Object ReplicationGroupName, ReplicationGroupGuid |
    Format-Table -AutoSize

# Expected output:
# ReplicationGroupName  ReplicationGroupGuid
# --------------------  --------------------
# Domain System Volume  {A1B2C3D4-E5F6-...}

Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Vérifier que DFS-R est bien actif - l'artefact technique à savoir relire sans chercher : dfsrmig.exe - la commande ou l'étape de validation à pouvoir rejouer en labo : Get-WmiObject -Namespace "root\MicrosoftDFS" -Class "DfsrReplicationGroupConfig" |

En résumé

FRS est supprimé dans Server 2022. La migration vers DFS-R est obligatoire et se fait en 4 états via dfsrmig.exe. Ne jamais avancer d'un état avant que tous les DCs aient atteint l'état précédent. DFS-R offre la compression différentielle, le throttling et une surveillance exploitable.


Santé SYSVOL : diagnostic de réplication

Flux de réplication DFS-R

Comprendre le flux de réplication permet d'identifier à quelle étape une défaillance se produit.

sequenceDiagram
    participant Admin as Admin (GPMC)
    participant PDC as PDC Emulator (DC1)
    participant DC2 as DC2 (même site)
    participant DC3 as DC3 (autre site)

    Admin->>PDC: Modifie une GPO via GPMC
    Note over PDC: GPMC écrit toujours sur le PDC Emulator
    PDC->>PDC: Met à jour le GPT dans SYSVOL local
    PDC->>PDC: Incrémente versionNumber dans AD (GPC)

    PDC->>DC2: DFS-R réplique les fichiers SYSVOL modifiés
    PDC->>DC3: DFS-R réplique les fichiers SYSVOL modifiés

    PDC->>DC2: Réplication AD — GPC versionNumber propagé
    PDC->>DC3: Réplication AD — GPC versionNumber propagé

    Note over DC2: Délai intra-site : 15 s – 5 min
    Note over DC3: Délai inter-sites : jusqu'à 180 min (selon schedule)

    DC2-->>Admin: Client peut lire GPT depuis DC2
    DC3-->>Admin: Client peut lire GPT depuis DC3

La GPMC écrit toujours sur le PDC Emulator. Si le PDC Emulator est inaccessible, toute tentative de modification d'une GPO échoue avec le message : "The domain specified is not available."


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Flux de réplication DFS-R - la valeur, le GUID ou le paramètre qui change réellement le résultat dans Flux de réplication DFS-R - la commande ou l'étape de validation à pouvoir rejouer en labo : sequenceDiagram

IDs d'événements critiques

Ces événements doivent être surveillés sur tous les DCs, idéalement via un SIEM ou un collecteur d'événements centralisé (WEC).

Event ID Journal Source Signification
1058 System GroupPolicy Impossible d'accéder au SYSVOL d'un DC distant
1030 System GroupPolicy Impossible d'accéder au partage SYSVOL local
4602 DFS Replication DFSR Service DFS-R initialisé sur ce DC
5002 DFS Replication DFSR Réplication SYSVOL complète vers ce DC
5014 DFS Replication DFSR SYSVOL marqué READY — DC prêt à servir les clients
5004 DFS Replication DFSR DC admis dans le groupe de réplication
2213 DFS Replication DFSR Fichier en conflit détecté dans SYSVOL
2012 DFS Replication DFSR Zone de staging proche de la limite configurée
2013 DFS Replication DFSR Zone de staging saturée — réplication ralentie

Événement 1058 vs 1030

1030 : le DC ne peut pas accéder à son propre SYSVOL local — problème local (service DFSR arrêté, NTFS corrompu). 1058 : le DC peut accéder à son propre SYSVOL mais pas à celui d'un autre DC — problème réseau ou de permissions.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - les repères de lecture du tableau précédent : Event ID, Journal, Source - la valeur, le GUID ou le paramètre qui change réellement le résultat dans IDs d'événements critiques - le contrôle terrain à effectuer avant de passer à la suite de IDs d'événements critiques

Vérifier l'accessibilité de SYSVOL sur tous les DCs

Résultat attendu
# Check SYSVOL share accessibility on all domain controllers
# A False result indicates the DC cannot serve GPOs to clients

Get-ADDomainController -Filter * | ForEach-Object {
    $dc        = $_.HostName
    $sysvol    = Test-Path "\\$dc\SYSVOL" -ErrorAction SilentlyContinue
    $netlogon  = Test-Path "\\$dc\NETLOGON" -ErrorAction SilentlyContinue

    [PSCustomObject]@{
        DC              = $dc
        Site            = $_.Site
        SYSVOL          = $sysvol
        NETLOGON        = $netlogon
    }
} | Sort-Object DC | Format-Table -AutoSize

# Expected output (healthy domain):
# DC               Site                    SYSVOL  NETLOGON
# --               ----                    ------  --------
# dc01.contoso.com Default-First-Site-Name   True      True
# dc02.contoso.com Paris                     True      True
# dc03.contoso.com Lyon                      True      True

Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Vérifier l'accessibilité de SYSVOL sur tous les DCs - la valeur, le GUID ou le paramètre qui change réellement le résultat dans Vérifier l'accessibilité de SYSVOL sur tous les DCs - la commande ou l'étape de validation à pouvoir rejouer en labo : Get-ADDomainController -Filter * | ForEach-Object {

Vérifier le backlog DFS-R entre deux DCs

Le backlog DFS-R indique le nombre de fichiers en attente de réplication entre deux membres.

Résultat attendu
# Check DFS-R replication backlog between two DCs
# Replace DC01 and DC02 with actual hostnames

$rgName = "Domain System Volume"
$rfName = "SYSVOL Share"
$sender = "DC01"
$receiver = "DC02"

dfsrdiag backlog /RGName:"$rgName" /RFName:"$rfName" `
    /SendingMember:$sender /ReceivingMember:$receiver

# Expected output (healthy — no backlog):
# No backlog — member is up to date.

# Expected output (backlog present):
# 5 file(s) in backlog from DC01 to DC02.
# <list of pending files>

Un backlog de 0 est la cible. Un backlog persistant supérieur à quelques dizaines de fichiers mérite une investigation.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Vérifier le backlog DFS-R entre deux DCs - la valeur, le GUID ou le paramètre qui change réellement le résultat dans Vérifier le backlog DFS-R entre deux DCs - la commande ou l'étape de validation à pouvoir rejouer en labo : $rgName = "Domain System Volume"

Vérifier l'accessibilité des GPT.INI pour toutes les GPO

Ce script détecte les GPO dont le fichier GPT.INI est inaccessible depuis la machine courante.

Résultat attendu
# Find GPOs with inaccessible GPT.INI in SYSVOL
# A missing GPT.INI means clients cannot process the GPO

Get-GPO -All | ForEach-Object {
    $guid = $_.Id.ToString().ToUpper()
    $path = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies\{$guid}\GPT.INI"

    [PSCustomObject]@{
        GPO           = $_.DisplayName
        GUID          = "{$guid}"
        GPTAccessible = (Test-Path $path -ErrorAction SilentlyContinue)
    }
} | Where-Object { -not $_.GPTAccessible } | Format-Table -AutoSize

# Expected output (healthy — no rows):
# (empty — all GPOs have accessible GPT.INI)

# Expected output (problem detected):
# GPO                   GUID                                   GPTAccessible
# ---                   ----                                   -------------
# Security - Workstations {A1B2C3D4-E5F6-7890-ABCD-EF1234567890}         False

Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Vérifier l'accessibilité des GPT.INI pour toutes les GPO - l'artefact technique à savoir relire sans chercher : GPT.INI - la commande ou l'étape de validation à pouvoir rejouer en labo : Get-GPO -All | ForEach-Object {

Forcer une synchronisation DFS-R

Si un DC est en retard sur la réplication SYSVOL, il est possible de déclencher une synchronisation forcée.

Résultat attendu
# Force DFS-R to poll for changes immediately on a specific DC
# Run locally on the DC that needs to catch up, or via Invoke-Command

Invoke-Command -ComputerName DC02 -ScriptBlock {
    # Restart DFS-R service to force re-initialization (disruptive but effective)
    # Use only if dfsrdiag does not resolve the issue
    # Restart-Service DFSR -Force

    # Preferred: trigger a manual poll without restarting
    $dfsrWmi = Get-WmiObject -Namespace "root\MicrosoftDFS" `
        -Class "DfsrReplicatedFolderConfig" |
        Where-Object { $_.ReplicatedFolderName -eq "SYSVOL Share" }

    if ($dfsrWmi) {
        Write-Output "DFS-R replicated folder found: $($dfsrWmi.ReplicatedFolderName)"
        Write-Output "Current state: check Event ID 5014 after replication completes"
    }
}

Redémarrage du service DFSR

Redémarrer le service DFSR sur un DC le rend temporairement indisponible pour les clients de ce site. Les clients basculent sur d'autres DCs via la découverte de site DNS. Planifier toute intervention en dehors des heures de bureau.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Forcer une synchronisation DFS-R - la valeur, le GUID ou le paramètre qui change réellement le résultat dans Forcer une synchronisation DFS-R - la commande ou l'étape de validation à pouvoir rejouer en labo : Invoke-Command -ComputerName DC02 -ScriptBlock {

En résumé

La GPMC écrit toujours sur le PDC Emulator. Le backlog DFS-R mesure le retard de réplication. Les événements 1058/1030 signalent des problèmes d'accès SYSVOL. L'événement 5014 confirme qu'un DC est opérationnel après réplication. Surveiller ces événements de façon centralisée.


Permissions NTFS sur SYSVOL

Pourquoi les permissions NTFS sont critiques

Les ACL sur le dossier Policies\ de SYSVOL déterminent qui peut lire les GPT (fichiers de configuration des GPO).

Si un compte ordinateur ne peut pas lire GPT.INI au démarrage, la GPO n'est pas appliquée. Les erreurs sont silencieuses du point de vue de l'utilisateur mais visibles dans les journaux d'événements (ID 1058, 1030).

Les permissions NTFS sur SYSVOL doivent être préservées et ne jamais être modifiées manuellement sans comprendre l'impact.


ACL minimales requises sur le dossier Policies

Principal Permissions Portée
SYSTEM Contrôle total Ce dossier, sous-dossiers et fichiers
Domain Admins Contrôle total Ce dossier, sous-dossiers et fichiers
Enterprise Admins Contrôle total Ce dossier, sous-dossiers et fichiers
Authenticated Users Lecture et exécution Ce dossier, sous-dossiers et fichiers
CREATOR OWNER Contrôle total Sous-dossiers et fichiers uniquement

L'entrée Authenticated Users avec Lecture et exécution est absolument critique. Elle couvre les comptes ordinateurs qui lisent les GPT avant l'ouverture de session utilisateur — au démarrage de Windows, c'est le compte machine qui s'authentifie et lit les GPO de configuration ordinateur.

Ne jamais remplacer Authenticated Users par Domain Users

Domain Users n'inclut pas les comptes ordinateurs. Remplacer Authenticated Users par Domain Users empêche tous les ordinateurs de lire les GPO au démarrage. Cette erreur est fréquente lors de durcissements de sécurité mal maîtrisés.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - les repères de lecture du tableau précédent : Principal, Permissions, Portée - l'artefact technique à savoir relire sans chercher : SYSTEM - le second repère technique à retenir avant de continuer : Domain Admins

Vérifier les ACL du dossier Policies

Résultat attendu
# Check NTFS ACL on the SYSVOL Policies folder
# Verify that Authenticated Users has Read & Execute

$sysvolPolicies = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies"

(Get-Acl $sysvolPolicies).Access |
    Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInherited |
    Format-Table -AutoSize

# Expected output (healthy):
# IdentityReference                    FileSystemRights  AccessControlType  IsInherited
# -----------------                    ----------------  -----------------  -----------
# NT AUTHORITY\Authenticated Users     ReadAndExecute...          Allow        False
# BUILTIN\Administrators               FullControl                Allow        False
# NT AUTHORITY\SYSTEM                  FullControl                Allow        False
# CONTOSO\Domain Admins                FullControl                Allow        False
# CONTOSO\Enterprise Admins            FullControl                Allow        False
# CREATOR OWNER                        FullControl                Allow        False

Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Vérifier les ACL du dossier Policies - la valeur, le GUID ou le paramètre qui change réellement le résultat dans Vérifier les ACL du dossier Policies - la commande ou l'étape de validation à pouvoir rejouer en labo : $sysvolPolicies = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies"

Vérifier les ACL sur un dossier GPO spécifique

Résultat attendu
# Check ACL on a specific GPO folder in SYSVOL
# Replace the GUID with the target GPO's GUID

$gpoGuid  = "{31B2F340-016D-11D2-945F-00C04FB984F9}"  # Default Domain Policy
$gpoPath  = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN\Policies\$gpoGuid"

(Get-Acl $gpoPath).Access |
    Select-Object IdentityReference, FileSystemRights, AccessControlType |
    Format-Table -AutoSize

# Expected output:
# IdentityReference                  FileSystemRights  AccessControlType
# -----------------                  ----------------  -----------------
# NT AUTHORITY\Authenticated Users   ReadAndExecute...          Allow
# NT AUTHORITY\SYSTEM                FullControl                Allow
# CONTOSO\Domain Admins              FullControl                Allow

Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Vérifier les ACL sur un dossier GPO spécifique - la valeur, le GUID ou le paramètre qui change réellement le résultat dans Vérifier les ACL sur un dossier GPO spécifique - la commande ou l'étape de validation à pouvoir rejouer en labo : $gpoGuid = "{31B2F340-016D-11D2-945F-00C04FB984F9}" # Default Domain Policy

Restaurer les permissions SYSVOL par défaut

Si les ACL SYSVOL ont été corrompues, secedit.exe et une réinitialisationde la sécurité peuvent les restaurer, mais la méthode la plus sûre est d'utiliser l'autorité du PDC Emulator comme source de vérité.

Résultat attendu
# Reset SYSVOL permissions to defaults on the local DC
# WARNING: This modifies NTFS ACLs — test in a non-production environment first

$sysvolRoot = "$env:SystemRoot\SYSVOL\sysvol\$env:USERDNSDOMAIN"

# Use icacls to reset inheritance and apply default permissions
# This is a simplified example — adapt to your specific ACL requirements
icacls "$sysvolRoot\Policies" /reset /T /C /Q

# Then re-apply base permissions manually or via Group Policy Security templates
Write-Output "ACL reset complete. Verify with (Get-Acl).Access after propagation."

# Expected output:
# processed file: \\...\Policies
# Successfully processed 1 files; Failed processing 0 files
# ACL reset complete. Verify with (Get-Acl).Access after propagation.

Réinitialisation des ACL en production

Réinitialiser les ACL SYSVOL sur un DC actif est une opération à haut risque. La faire en dehors des heures d'utilisation, valider sur un DC de test d'abord, et s'assurer d'avoir une sauvegarde de l'état du système (VSS ou sauvegarde complète DC).


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Restaurer les permissions SYSVOL par défaut - l'artefact technique à savoir relire sans chercher : secedit.exe - la commande ou l'étape de validation à pouvoir rejouer en labo : $sysvolRoot = "$env:SystemRoot\SYSVOL\sysvol\$env:USERDNSDOMAIN"

En résumé

Les permissions NTFS sur SYSVOL sont fonctionnelles, pas seulement sécuritaires. Authenticated Users avec Lecture est obligatoire pour que les ordinateurs lisent les GPT au démarrage. Ne jamais le remplacer par Domain Users. Vérifier régulièrement avec Get-Acl ou un outil d'audit des ACL.


Problèmes courants et résolutions

GPT orphelin : dossier SYSVOL sans GPC dans AD

Un GPT orphelin est un dossier dans SYSVOL\Policies\ dont le GUID ne correspond à aucun objet GPC dans Active Directory.

Cause typique : suppression incorrecte d'une GPO — le GPC dans AD a été supprimé (via ADSIEdit ou ldifde) mais le dossier dans SYSVOL n'a pas été supprimé. Ou inversement : la console GPMC a planté pendant une suppression.

Les GPT orphelins ne posent pas de problème fonctionnel immédiat, mais ils consomment de l'espace dans la zone de staging DFS-R et polluent les audits de sécurité.

Résultat attendu
# Detect orphaned GPTs: SYSVOL folders with no matching AD GPC object
# Safe to run — read-only, no changes made

$domain      = $env:USERDNSDOMAIN
$sysvolBase  = "\\$domain\SYSVOL\$domain\Policies"
$gpoPoliciesOU = "CN=Policies,CN=System," + (Get-ADDomain).DistinguishedName

# Collect all GPT GUIDs from SYSVOL (folders starting with {)
$sysvolGPTs = Get-ChildItem $sysvolBase -Directory |
    Where-Object { $_.Name -match '^\{[0-9A-Fa-f\-]+\}$' } |
    Select-Object -ExpandProperty Name

# Collect all GPC GUIDs from Active Directory
$adGPOGuids = Get-ADObject -SearchBase $gpoPoliciesOU `
    -Filter { ObjectClass -eq "groupPolicyContainer" } |
    Select-Object -ExpandProperty Name

# Find GUIDs in SYSVOL with no AD counterpart
$orphans = $sysvolGPTs | Where-Object { $_ -notin $adGPOGuids }

if ($orphans.Count -eq 0) {
    Write-Output "No orphaned GPTs found."
} else {
    $orphans | ForEach-Object {
        [PSCustomObject]@{
            OrphanedGPT = $_
            Path        = "$sysvolBase\$_"
        }
    } | Format-Table -AutoSize
}

# Expected output (healthy):
# No orphaned GPTs found.

# Expected output (orphans detected):
# OrphanedGPT                            Path
# -----------                            ----
# {A1B2C3D4-E5F6-7890-ABCD-EF1234567890} \\contoso.local\SYSVOL\...\{A1B2C...}

Ne pas supprimer un GPT orphelin sans vérification

Avant de supprimer un dossier GPT orphelin, confirmer qu'il n'est pas référencé par un lien GPO dans une OU (attribut gPLink dans AD). Un dossier SYSVOL peut sembler orphelin si la recherche AD est incomplète (domaines de confiance, partitions de nommage non standard).


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : GPT orphelin : dossier SYSVOL sans GPC dans AD - l'artefact technique à savoir relire sans chercher : SYSVOL\Policies\ - la commande ou l'étape de validation à pouvoir rejouer en labo : $domain = $env:USERDNSDOMAIN

GPC orphelin : objet AD sans GPT dans SYSVOL

L'inverse est également possible : un GPC existe dans AD mais son dossier GPT correspondant est absent de SYSVOL.

Cause typique : problème de réplication SYSVOL, ou suppression manuelle du dossier dans SYSVOL.

Symptôme : les clients qui tentent d'appliquer cette GPO génèrent l'événement 1058 en boucle.

Résultat attendu
# Detect orphaned GPCs: AD objects with no matching SYSVOL folder
# These will cause Event ID 1058 on clients

$domain      = $env:USERDNSDOMAIN
$sysvolBase  = "\\$domain\SYSVOL\$domain\Policies"
$gpoPoliciesOU = "CN=Policies,CN=System," + (Get-ADDomain).DistinguishedName

$sysvolGPTs = Get-ChildItem $sysvolBase -Directory |
    Where-Object { $_.Name -match '^\{' } |
    Select-Object -ExpandProperty Name

Get-ADObject -SearchBase $gpoPoliciesOU `
    -Filter { ObjectClass -eq "groupPolicyContainer" } `
    -Properties DisplayName, Name | ForEach-Object {

    $gptExists = $_.Name -in $sysvolGPTs

    if (-not $gptExists) {
        [PSCustomObject]@{
            GPO          = $_.DisplayName
            GUID         = $_.Name
            MissingInSYSVOL = $true
        }
    }
} | Format-Table -AutoSize

# Expected output (healthy — no rows):
# (empty)

Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : GPC orphelin : objet AD sans GPT dans SYSVOL - la valeur, le GUID ou le paramètre qui change réellement le résultat dans GPC orphelin : objet AD sans GPT dans SYSVOL - la commande ou l'étape de validation à pouvoir rejouer en labo : $domain = $env:USERDNSDOMAIN

PDC Emulator inaccessible : impact sur GPMC

La GPMC se connecte toujours au PDC Emulator pour lire et écrire les GPO. Si le PDC Emulator est inaccessible, toutes les modifications de GPO échouent.

Message d'erreur caractéristique dans GPMC :

"The following error occurred when saving Group Policy Object settings: The domain specified is not available."

Ce message est trompeur. Ce n'est pas le domaine qui est indisponible — c'est le PDC Emulator spécifiquement.

Résultat attendu
# Identify the current PDC Emulator and test connectivity
$pdcEmulator = (Get-ADDomain).PDCEmulator

Write-Output "PDC Emulator: $pdcEmulator"
Test-Connection -ComputerName $pdcEmulator -Count 2 | Select-Object Address, ResponseTime, StatusCode

# Verify SYSVOL share on PDC Emulator specifically
Test-Path "\\$pdcEmulator\SYSVOL"

# Expected output:
# PDC Emulator: dc01.contoso.com
#
# Address          ResponseTime  StatusCode
# -------          ------------  ----------
# dc01.contoso.com           1      Success
# dc01.contoso.com           1      Success
#
# True

Saisir les opérations FSMO en urgence

Si le PDC Emulator est en panne prolongée, il est possible de saisir le rôle FSMO sur un autre DC avec Move-ADDirectoryServerOperationMasterRole. Cette opération doit être documentée et autorisée — elle ne se fait pas à la légère.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : PDC Emulator inaccessible : impact sur GPMC - l'artefact technique à savoir relire sans chercher : Move-ADDirectoryServerOperationMasterRole - la commande ou l'étape de validation à pouvoir rejouer en labo : $pdcEmulator = (Get-ADDomain).PDCEmulator

Réinitialisation d'un SYSVOL non autoritaire

Lors de la restauration d'un DC depuis sauvegarde ou après une corruption DFS-R, il peut être nécessaire de marquer un DC comme autoritaire (authoritative restore de SYSVOL). Cela force les autres DCs à se synchroniser depuis ce DC.

Résultat attendu
# Mark the local DC as authoritative for SYSVOL (DFS-R authoritative restore)
# Run on the DC that will be the authoritative source
# WARNING: All other DCs will overwrite their SYSVOL from this DC

# Step 1: Stop DFS-R service
Stop-Service DFSR

# Step 2: Set the authoritative restore flag in the registry
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Seeding SysVols\<DOMAIN_GUID>"
# Replace <DOMAIN_GUID> with actual domain GUID from:
# (Get-ADDomain).ObjectGUID
Set-ItemProperty -Path $regPath -Name "Enable" -Value 1 -Type DWord

# Step 3: Start DFS-R — it will replicate SYSVOL out to all partners
Start-Service DFSR

Write-Output "DC marked as authoritative. Monitor Event ID 5014 for completion."

# Expected output:
# DC marked as authoritative. Monitor Event ID 5014 for completion.

Restauration autoritaire : opération de production critique

Une restauration autoritaire SYSVOL écrase le SYSVOL de tous les DCs partenaires avec le contenu de la source autoritaire. Si la source autoritaire est elle-même corrompue ou incomplète, les dommages se propagent à tout le domaine. Valider le contenu du SYSVOL source avant de déclencher la réplication autoritaire.


Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Réinitialisation d'un SYSVOL non autoritaire - la valeur, le GUID ou le paramètre qui change réellement le résultat dans Réinitialisation d'un SYSVOL non autoritaire - la commande ou l'étape de validation à pouvoir rejouer en labo : Stop-Service DFSR

En résumé

Les trois problèmes les plus fréquents sont : GPT orphelins (dossiers sans GPC), GPC orphelins (objets AD sans dossier SYSVOL), et PDC Emulator inaccessible bloquant GPMC. Les GPT orphelins sont détectables par comparaison des GUIDs entre SYSVOL et AD. La restauration autoritaire est le dernier recours en cas de corruption totale.


Référence : clés de registre DFS-R

Ces clés de registre contrôlent le comportement du service DFS-R sur chaque DC. Elles sont rarement modifiées directement — préférer la console DFS Management ou les cmdlets WMI.

Chemin Valeur Type Description
HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters MinimumStagingSizeInMb DWORD Taille minimale de la zone de staging (défaut : 4096 Mo)
HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters ConflictSizeInMb DWORD Taille max du dossier ConflictAndDeleted (défaut : 660 Mo)
HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\Replication Groups\<GUID>\Replicated Folders\<RFGUID> Enable DWORD 0 = dossier répliqué désactivé, 1 = actif
HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Seeding SysVols\<DomainGUID> Enable DWORD 1 = DC marqué autoritaire pour SYSVOL
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters SysvolReady DWORD 1 = SYSVOL est prêt à servir les clients (positionné par DFSR)

SysvolReady

La valeur SysvolReady sous la clé Netlogon est positionnée à 1 par le service DFSR une fois que le SYSVOL local est considéré synchronisé. C'est cette valeur qui détermine si le DC annonce le partage SYSVOL via DNS. Un DC avec SysvolReady = 0 ne sera pas utilisé par les clients pour les GPO.


Vérifier SysvolReady sur tous les DCs

Résultat attendu
# Check SysvolReady registry value on all domain controllers
# A value of 0 means the DC is not advertising SYSVOL to clients

Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    $ready = Invoke-Command -ComputerName $dc -ScriptBlock {
        (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" `
            -Name "SysvolReady" -ErrorAction SilentlyContinue).SysvolReady
    } -ErrorAction SilentlyContinue

    [PSCustomObject]@{
        DC          = $dc
        SysvolReady = $ready
        Status      = if ($ready -eq 1) { "OK" } else { "NOT READY" }
    }
} | Format-Table -AutoSize

# Expected output (healthy):
# DC               SysvolReady  Status
# --               -----------  ------
# dc01.contoso.com           1  OK
# dc02.contoso.com           1  OK
# dc03.contoso.com           1  OK

Point de contrôle

Avant de continuer, vérifiez que vous avez bien compris : - le but précis de cette sous-section : Vérifier SysvolReady sur tous les DCs - l'artefact technique à savoir relire sans chercher : SysvolReady - la commande ou l'étape de validation à pouvoir rejouer en labo : Get-ADDomainController -Filter * | ForEach-Object {

En résumé

La clé SysvolReady sous Netlogon est le signal que le DC émet pour indiquer qu'il est prêt à servir les GPO. La taille de la zone de staging DFS-R (défaut 4 Go) est configurable et doit être augmentée sur les domaines avec de nombreuses GPO ou des scripts volumineux.


Rôle de SYSVOL dans le cycle de traitement GPO

SYSVOL est impliqué à chaque étape du cycle de traitement des GPO côté client. Comprendre cette implication aide à diagnostiquer les problèmes à la bonne couche.

flowchart TD
    A[Client démarre ou<br/>utilisateur ouvre session] --> B[Localisation d'un DC<br/>via DNS/NetLogon]
    B --> C{SYSVOL accessible<br/>sur ce DC ?}
    C -- Non --> D[Événement 1058<br/>GPO non appliquées<br/>Fallback: état précédent]
    C -- Oui --> E[Lecture de la liste des GPO<br/>applicables via LDAP/AD]
    E --> F[Pour chaque GPO :<br/>lecture de GPT.INI]
    F --> G{Version GPT.INI ==<br/>version GPC dans AD ?}
    G -- Non, GPO plus récente --> H[Téléchargement du contenu<br/>GPT depuis SYSVOL]
    G -- Oui, déjà à jour --> I[GPO ignorée<br/>version déjà traitée]
    H --> J[Traitement par<br/>les CSE concernés]
    J --> K[Paramètres appliqués]
    I --> K
    K --> L[Cycle terminé<br/>Prochain cycle dans 90-120 min]

Ce diagramme illustre deux points critiques :

  1. Si SYSVOL est inaccessible, toutes les GPO sont ignorées — pas d'erreur bloquante pour l'utilisateur, mais les paramètres ne sont pas mis à jour.
  2. La comparaison de version GPT.INI/GPC est le mécanisme d'optimisation qui évite de retraiter les GPO inchangées.

En résumé

SYSVOL est consulté à chaque cycle GPO pour deux raisons : déterminer si une GPO a changé (lecture GPT.INI) et télécharger les fichiers de configuration si c'est le cas. Un SYSVOL inaccessible ne bloque pas le démarrage mais empêche toute mise à jour des paramètres GPO.


Références croisées

Sujet Chapitre
Architecture GPC/GPT et attribut versionNumber Ch. 02 — Architecture et composants internes
Contenu et format de registry.pol Ch. 06 — Le format registry.pol
Cycle de traitement GPO côté client Ch. 07 — Traitement des stratégies : cycle et modes
Dépannage avec RSoP et événements 1058/1030 Ch. 20 — RSoP et diagnostic
SYSVOL multi-sites et réplication inter-sites Les GPO pour les Admins — Ch. 07 — GPO multi-sites
Sauvegarde et restauration des GPO Les GPO pour les Admins — Ch. 05 — Sauvegarde et restauration
Central Store ADMX dans SYSVOL Ch. 05 — Modèles d'administration (ADMX/ADML)

En résumé

  • À relire : Architecture GPC/GPT et attribut versionNumber → Ch. 02 — Architecture et composants internes.
  • À relire : Contenu et format de registry.pol → Ch. 06 — Le format registry.pol.
  • À relire : Cycle de traitement GPO côté client → Ch. 07 — Traitement des stratégies : cycle et modes.
  • À relire : Dépannage avec RSoP et événements 1058/1030 → Ch. 20 — RSoP et diagnostic.
  • À relire : Ch. 02 — Architecture et composants internes.