GPO multi-sites et multi-forêts¶

Contexte de production¶

Les environnements multi-sites sont la norme dans les organisations de taille moyenne et grande : un siège social, plusieurs agences régionales, parfois des pays distincts. Chaque site a des contraintes réseau, des DNS suffixes, des proxies, parfois des fuseaux horaires différents.

Les problèmes arrivent quand on essaie d'appliquer une configuration centralisée sans tenir compte de l'architecture AD Sites & Services. Ou, à l'inverse, quand on crée des GPO site-spécifiques sans comprendre comment le GPC et le GPT se répliquent — et ce que ça implique pour les utilisateurs qui ouvrent une session pendant une fenêtre de latence WAN.

Ce chapitre couvre les quatre situations que vous rencontrerez en production : GPO liées à un Site, GPO cross-domaine dans une même forêt, GPO cross-forêt (spoiler : ça n'existe pas), et la gestion de la convergence SYSVOL sur liens étendus.

GPO liées à un Site AD¶

Pourquoi lier une GPO à un Site¶

Les GPO sont le plus souvent liées à des OU — c'est le cas standard. Mais Active Directory permet aussi de lier une GPO à un Site AD, c'est-à-dire à un objet de la partition CN=Sites,CN=Configuration.

L'intérêt est de cibler des postes par leur emplacement réseau plutôt que par leur position dans l'arborescence OU.

Les cas d'usage courants :

Lier une GPO à un Site dans GPMC¶

La liaison à un Site se fait dans GPMC via le nœud Sites, pas via le nœud Domains. Ce nœud est masqué par défaut.

Chemin GPMC pour afficher les Sites :

Group Policy Management
└── Forest: corp.example.com
    └── Sites          ← clic droit → "Show Sites..." pour l'afficher
        ├── Paris
        ├── Lyon
        └── Bordeaux

Étapes dans GPMC :

1. Dans GPMC, clic droit sur Sites → Show Sites...
2. Cochez le ou les sites à afficher, cliquez OK.
3. Sélectionnez le site cible (ex: Paris).
4. Onglet Linked Group Policy Objects → Link an Existing GPO...
5. Sélectionnez la GPO à lier.

Lier une GPO à un Site en PowerShell¶

Le DN d'un Site est dans la partition de Configuration, pas dans la partition du domaine. La syntaxe exacte de -Target est critique.

# Link a GPO to an AD Site
# The target DN is always in CN=Sites,CN=Configuration,DC=...
New-GPLink -Name "SITE-Paris-Proxy" `
           -Target "CN=Paris,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com" `
           -LinkEnabled Yes `
           -Enforced No

GpoId       : {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
DisplayName : SITE-Paris-Proxy
Enabled     : True
Enforced    : False
Target      : CN=Paris,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
Order       : 1

Pour retrouver le DN exact d'un site sans l'avoir mémorisé :

# List all AD Sites with their distinguished names
Get-ADReplicationSite -Filter * | Select-Object Name, DistinguishedName

Name        DistinguishedName
----        -----------------
Paris       CN=Paris,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
Lyon        CN=Lyon,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
Bordeaux    CN=Bordeaux,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com

Implications sur la réplication WAN¶

C'est le point critique que les admins sous-estiment systématiquement.

Une GPO se compose de deux parties distinctes qui ne se répliquent pas de la même façon :

La partition de Configuration (qui contient les objets Sites) se réplique entre tous les DC de la forêt, pas seulement ceux du domaine. Elle est globale.

Le GPT dans SYSVOL est téléchargé depuis le DC le plus proche au moment de l'application de la GPO. Si ce DC local n'a pas encore reçu le GPT (latence DFS-R sur lien WAN), le client obtient l'ancienne version.

GPO multi-domaines dans la même forêt¶

Comportement natif : une GPO reste dans son domaine¶

Une GPO est créée dans un domaine précis. Elle est stockée dans la partition du domaine (CN=Policies,CN=System,DC=...) et son GPT vit dans le SYSVOL de ce domaine.

Une GPO ne s'applique qu'aux objets du domaine dans lequel elle a été créée. C'est un comportement natif, sans exception.

Si vous avez une forêt corp.example.com avec deux domaines — emea.corp.example.com et apac.corp.example.com — une GPO créée dans emea ne peut pas s'appliquer aux postes d'apac, même si les deux domaines sont dans la même forêt.

:material-copy: Stratégie : Copy-GPO entre domaines de la même forêt¶

La solution officielle est de dupliquer la GPO dans chaque domaine cible. Copy-GPO fait exactement ça pour les domaines d'une même forêt.

# Copy a GPO from one domain to another within the same forest
Copy-GPO -SourceGpoName "SEC-Baseline-Postes" `
         -SourceDomain "emea.corp.example.com" `
         -TargetName "SEC-Baseline-Postes" `
         -TargetDomain "apac.corp.example.com" `
         -CopyAcls:$false

Le paramètre -CopyAcls:$false est obligatoire quand les domaines source et cible ont des groupes différents. Les SID ne sont pas portables entre domaines.

Après la copie, configurez manuellement le filtrage de sécurité dans GPMC pour apac.corp.example.com avec les groupes du domaine cible.

Table de migration pour les références cross-domaine¶

Si la GPO contient des références spécifiques au domaine source — chemins UNC, noms de groupes, suffixes de domaine dans des paramètres — une table de migration est nécessaire.

La table mappe les références source vers leurs équivalents dans le domaine cible.

# Import GPO settings into the target domain using a migration table
Import-GPO -BackupGpoName "SEC-Baseline-Postes" `
           -Path "\\serveur\GPO-Backups\2026-04-05" `
           -TargetName "SEC-Baseline-Postes" `
           -TargetDomain "apac.corp.example.com" `
           -MigrationTable "C:\Temp\emea-to-apac.migtable" `
           -CreateIfNeeded

DisplayName : SEC-Baseline-Postes
DomainName  : apac.corp.example.com
Id          : {yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy}
GpoStatus   : AllSettingsEnabled

Exemples de mappings dans la table de migration :

Filtrage de sécurité cross-domaine¶

Les groupes utilisés dans le filtrage de sécurité doivent exister dans le domaine où la GPO est liée. Un groupe EMEA\GRP-Postes-Travail n'est pas visible dans apac.corp.example.com pour le filtrage.

Deux options :

1. Groupes universels — Un groupe universel est visible dans toute la forêt. Créez un groupe universel dans la forêt et utilisez-le dans le filtrage de sécurité des deux domaines. C'est la solution la plus propre pour un déploiement uniforme.

2. Groupes locaux de domaine — Créez un groupe équivalent dans chaque domaine cible et appliquez le même filtrage localement. Plus de maintenance, mais utile si les périmètres sont différents.

GPO multi-forêts : la limitation fondamentale¶

Une GPO ne peut pas traverser une forêt¶

C'est la limite architecturale la plus importante de ce chapitre — et la plus souvent mal comprise.

Une GPO ne peut jamais s'appliquer à des objets d'une autre forêt. Pas avec Copy-GPO, pas avec un trust, pas avec une configuration avancée. Il n'existe aucune exception à cette règle.

Pourquoi — Le fonctionnement du GP Client Service¶

Quand un poste Windows applique des GPO, le service GP Client Service (gpsvc) suit ce processus :

1. Contacte le DC de son propre domaine pour obtenir la liste des GPO applicables.
2. Télécharge les GPT depuis le SYSVOL de son propre domaine.
3. Applique les paramètres localement.

Le service ne consulte jamais l'AD d'une autre forêt. Il ne connaît pas l'existence d'un trust inter-forêts au moment du traitement des GPO. Cette contrainte est dans le design du protocole, pas dans une configuration Active Directory.

Le modèle Forest de ressources¶

Un cas qui revient régulièrement : le Resource Forest (forêt de ressources + forêt de comptes).

Dans ce modèle :

• La forêt de comptes contient les utilisateurs et groupes.
• La forêt de ressources contient les serveurs, applications, et postes de travail.
• Un trust inter-forêts (généralement bidirectionnel) permet aux utilisateurs de la forêt de comptes de s'authentifier sur les ressources de la forêt de ressources.

La question revient toujours : "Peut-on appliquer une GPO de la forêt de comptes aux postes de la forêt de ressources ?"

Non. Les postes appartiennent à la forêt de ressources. Le GP Client Service de ces postes consulte uniquement le DC de la forêt de ressources. Les GPO de la forêt de comptes sont totalement invisibles pour eux.

Alternatives opérationnelles¶

Puisqu'on ne peut pas croiser les forêts, les alternatives sont :

Option 1 — Duplication manuelle avec Copy-GPO + table de migration. Exportez la GPO depuis la forêt source, importez-la dans la forêt cible avec une table de migration adaptée. Maintenez les deux GPO en parallèle. C'est le travail supplémentaire à absorber dans votre gouvernance.

Option 2 — Console GPMC multi-forêts. GPMC peut se connecter à plusieurs forêts simultanément (clic droit sur Forest → Add Forest). Cela permet de gérer les GPO des deux forêts depuis une seule console — mais les GPO restent dans leur forêt d'origine.

Option 3 — Outils tiers. Des outils comme AGPM (Advanced Group Policy Management) de Microsoft ou des solutions tierces permettent de gérer le cycle de vie des GPO à l'échelle multi-forêts, mais chaque GPO reste dans sa forêt. Ils automatisent la synchronisation, pas le franchissement de frontière.

Trusts inter-forêts et GPO¶

Ce qu'un trust fait — et ce qu'il ne fait pas¶

Un trust inter-forêts est un accord d'authentification entre deux forêts. Il dit : "Les utilisateurs de la forêt A peuvent prouver leur identité auprès des ressources de la forêt B."

Ce que le trust permet :

• Authentification Kerberos cross-forêt (via le SID History ou les noms UPN)
• Accès aux partages réseau, applications, services
• Utilisation de groupes universels cross-forêt dans les ACL

Ce que le trust ne fait pas — jamais, sans exception :

• Permettre à une GPO de s'appliquer dans l'autre forêt
• Exposer l'AD de la forêt source au GP Client de la forêt cible
• Rendre les SYSVOL des deux forêts accessibles l'un à l'autre pour le traitement des GPO

L'idée reçue et l'incident qui suit¶

L'idée reçue la plus répandue : "Avec un trust bidirectionnel complet entre deux forêts, les GPO peuvent circuler."

Ce raisonnement vient d'une confusion entre authentification et application des stratégies. Le trust résout l'authentification. L'application des GPO est un mécanisme distinct qui ne connaît pas le trust.

En pratique, l'incident qui suit ce raisonnement ressemble à ceci :

1. Fusion d'entreprise. Deux forêts AD coexistent.
2. Un trust bidirectionnel est mis en place pour que les utilisateurs des deux entités puissent accéder aux ressources partagées.
3. L'équipe infra décide de ne pas dupliquer les GPO de sécurité dans la forêt B "parce que le trust va les propager".
4. Six semaines plus tard, l'audit de sécurité révèle que les postes de la forêt B n'ont aucune configuration de sécurité appliquée.
5. La reconstruction prend deux jours.

# Validate applied GPOs on a remote machine in the other forest
# Run this from a machine that has access cross-forest
Invoke-Command -ComputerName "PC-ForetB-01.corp-b.example.com" `
               -Credential (Get-Credential) `
               -ScriptBlock { gpresult /r }

Applied Group Policy Objects
-----------------------------
    SEC-Baseline-Postes-B
    Default Domain Policy

The following GPOs were not applied because they were filtered out
--------------------------------------------------------------------
    (none)

DFS-R multi-sites et convergence SYSVOL¶

Le problème de la latence SYSVOL sur WAN¶

Quand vous modifiez une GPO, les changements sont écrits sur le PDC Emulator du domaine. DFS-R réplique ensuite le contenu du SYSVOL vers tous les autres DC du domaine.

Sur un réseau local, cette réplication est quasi-instantanée. Sur un lien WAN à 10 Mbps entre Paris et un site distant en province, la réplication peut prendre plusieurs minutes — voire plusieurs dizaines de minutes si le lien est saturé.

Le scénario problématique :

1. Un admin modifie une GPO urgente à Paris (PDC Emulator).
2. Il demande à un utilisateur de Lyon de faire gpupdate /force.
3. Le DC local de Lyon n'a pas encore reçu le GPT mis à jour.
4. L'utilisateur applique l'ancienne version de la GPO.
5. L'admin pense que la GPO est défectueuse. Elle ne l'est pas — elle n'est simplement pas encore arrivée.

Event IDs DFS-R à surveiller¶

Ces Event IDs dans le journal DFS Replication (Applications and Services Logs) signalent des problèmes de réplication SYSVOL.

Diagnostiquer l'état DFS-R avec dfsrdiag¶

dfsrdiag est l'outil en ligne de commande pour diagnostiquer l'état de DFS-R sur un DC.

Vérifier l'état du partenariat DFS-R entre deux DC :

# Check DFS-R replication health from the local DC's perspective
dfsrdiag ReplicationState /rgname:"Domain System Volume"

Replication group name: Domain System Volume
State               : Active
Replication members : 3

Vérifier le backlog entre deux DC (nombre de fichiers en attente de réplication) :

# Check the replication backlog between two domain controllers
# A high backlog means SYSVOL updates are queued and not yet delivered
dfsrdiag Backlog `
    /rgname:"Domain System Volume" `
    /rfname:"SYSVOL Share" `
    /sendingmember:DC-Paris01 `
    /receivingmember:DC-Lyon01

Backlog File Count: 0

Backlog File Count: 14
The following files are waiting for replication:
  registry.pol
  GPT.ini
  ...

Un backlog non nul signifie que des mises à jour GPO sont en attente. Ne forcez pas gpupdate sur les postes distants avant que le backlog soit à 0.

Forcer une synchronisation DFS-R :

# Trigger a DFS-R synchronization poll on a remote DC
# Use this after confirming backlog, not as a first response
Invoke-Command -ComputerName DC-Lyon01 -ScriptBlock {
    dfsrdiag PollAD /member:DC-Lyon01
}

DFS Replication Service successfully polled Active Directory.

Surveiller l'état DFS-R de tous les DC en PowerShell¶

Pour une vue d'ensemble rapide avant un déploiement urgent :

# Check DFS-R replication state on all domain controllers
# Run before forcing gpupdate on remote sites after a critical GPO change
$domainControllers = (Get-ADDomainController -Filter *).HostName

foreach ($dc in $domainControllers) {
    Write-Host "`n=== $dc ===" -ForegroundColor Cyan
    try {
        Invoke-Command -ComputerName $dc -ScriptBlock {
            dfsrdiag ReplicationState /rgname:"Domain System Volume"
        } -ErrorAction Stop
    } catch {
        Write-Warning "Cannot reach $dc : $_"
    }
}

=== DC-Paris01.corp.example.com ===
State : Active
...
=== DC-Lyon01.corp.example.com ===
State : Active
...
=== DC-Bordeaux01.corp.example.com ===
State : Active
...

Impact sur l'application des GPO¶

Le scénario le plus dangereux en multi-sites :

1. Un utilisateur ouvre sa session sur un poste du site de Bordeaux.
2. Le DC local de Bordeaux n'a pas encore reçu la dernière version du GPT (DFS-R en cours).
3. Le poste télécharge le GPT depuis le DC de Bordeaux — version N-1.
4. La GPO s'applique, mais avec les anciens paramètres.
5. L'utilisateur se retrouve avec une configuration incorrecte (proxy manquant, restriction logicielle absente, etc.).

Ce problème est transitoire mais peut avoir des conséquences de sécurité si la GPO manquante est une baseline de sécurité.

# Compare GPT.ini version on two DCs to detect replication lag
$gpoGuid = "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}"

$versionParis = Invoke-Command -ComputerName DC-Paris01 -ScriptBlock {
    Get-Content "\\DC-Paris01\SYSVOL\corp.example.com\Policies\$using:gpoGuid\GPT.ini"
}

$versionLyon = Invoke-Command -ComputerName DC-Lyon01 -ScriptBlock {
    Get-Content "\\DC-Lyon01\SYSVOL\corp.example.com\Policies\$using:gpoGuid\GPT.ini"
}

Write-Host "Paris GPT.ini: $versionParis"
Write-Host "Lyon GPT.ini:  $versionLyon"

Paris GPT.ini: [General]
               Version=65537
Lyon GPT.ini:  [General]
               Version=65537

Paris GPT.ini: [General]
               Version=65538
Lyon GPT.ini:  [General]
               Version=65537

Piège de production : créer une GPO depuis le mauvais DC¶

Le scénario¶

Vous êtes en déplacement à Lyon. Vous ouvrez GPMC depuis un poste local et vous vous connectez au DC local de Lyon. Vous créez une nouvelle GPO urgente et vous la liez à une OU.

La GPO est créée — mais elle a été écrite sur le DC de Lyon, pas sur le PDC Emulator (qui est à Paris).

Ce qui se passe ensuite¶

Active Directory réplique les nouvelles GPO depuis le DC où elles ont été créées vers les autres DC, y compris le PDC Emulator. Dans un réseau local, c'est transparent. Sur un lien WAN, cela peut prendre plusieurs minutes.

Mais le vrai problème est plus subtil : GPMC, par défaut, affiche l'état des GPO tel que vu par le DC auquel il est connecté. Si ce DC est en avance sur la réplication, vous voyez une GPO que les autres DC ne connaissent pas encore.

Les postes du site de Lyon vont appliquer la GPO rapidement (leur DC local l'a). Les postes des autres sites attendent la réplication AD + DFS-R.

# Identify the PDC Emulator for the domain before creating GPOs
(Get-ADDomain).PDCEmulator

DC-Paris01.corp.example.com

# Create a GPO and explicitly target the PDC Emulator
# This ensures immediate visibility across the domain
New-GPO -Name "SITE-Lyon-Config-Proxy" `
        -Server "DC-Paris01.corp.example.com"

New-GPLink -Name "SITE-Lyon-Config-Proxy" `
           -Target "OU=Postes-Lyon,DC=corp,DC=example,DC=com" `
           -Server "DC-Paris01.corp.example.com"

DisplayName      : SITE-Lyon-Config-Proxy
DomainName       : corp.example.com
Owner            : CORP\Domain Admins
Id               : {zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz}
GpoStatus        : AllSettingsEnabled

Le paramètre -Server sur New-GPO et New-GPLink force l'écriture sur un DC précis. Utilisez toujours le PDC Emulator.

Délai constaté en production¶

En environnement multi-sites réel, sur un lien WAN standard :

Vérification post-déploiement¶

Validation d'un déploiement multi-sites¶

Après tout déploiement de GPO en environnement multi-sites, exécutez cette séquence de vérification.

Étape 1 — Confirmer la convergence DFS-R sur tous les DC distants.

# Verify DFS-R backlog is zero on all remote DCs after GPO change
$gpoGuid = "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}"
$remoteDCs = @("DC-Lyon01", "DC-Bordeaux01", "DC-Toulouse01")

foreach ($dc in $remoteDCs) {
    $result = dfsrdiag Backlog `
        /rgname:"Domain System Volume" `
        /rfname:"SYSVOL Share" `
        /sendingmember:DC-Paris01 `
        /receivingmember:$dc

    $backlogCount = ($result | Select-String "Backlog File Count").ToString() -replace ".*: ",""
    Write-Host "$dc — Backlog: $backlogCount"
}

DC-Lyon01 — Backlog: 0
DC-Bordeaux01 — Backlog: 0
DC-Toulouse01 — Backlog: 0

Étape 2 — Valider l'application sur un poste pilote de chaque site.

# Validate GPO application on a pilot workstation per site
$pilotMachines = @{
    "Lyon"     = "PC-PILOTE-LYON-01"
    "Bordeaux" = "PC-PILOTE-BDX-01"
    "Toulouse" = "PC-PILOTE-TLS-01"
}

foreach ($site in $pilotMachines.Keys) {
    $machine = $pilotMachines[$site]
    Write-Host "`n=== Pilote $site : $machine ===" -ForegroundColor Cyan

    Invoke-Command -ComputerName $machine -ScriptBlock {
        gpupdate /force | Out-Null
        $result = gpresult /r 2>&1
        $appliedGPOs = $result | Select-String "Applied Group Policy Objects" -A 10
        Write-Output $appliedGPOs
    }
}

=== Pilote Lyon : PC-PILOTE-LYON-01 ===
Applied Group Policy Objects
-----------------------------
    SITE-Lyon-Config-Proxy
    SEC-Baseline-Postes
    Default Domain Policy

=== Pilote Bordeaux : PC-PILOTE-BDX-01 ===
Applied Group Policy Objects
-----------------------------
    SEC-Baseline-Postes
    Default Domain Policy

Étape 3 — Vérifier les Event IDs DFS-R sur les DC distants.

# Check for DFS-R error events on remote DCs in the last 2 hours
$remoteDCs = @("DC-Lyon01", "DC-Bordeaux01")
$criticalEventIDs = @(2213, 4012, 5002)
$since = (Get-Date).AddHours(-2)

foreach ($dc in $remoteDCs) {
    $events = Get-WinEvent -ComputerName $dc -FilterHashtable @{
        LogName   = "DFS Replication"
        Id        = $criticalEventIDs
        StartTime = $since
    } -ErrorAction SilentlyContinue

    if ($events) {
        Write-Warning "$dc — $($events.Count) DFS-R critical event(s) detected!"
        $events | Select-Object TimeCreated, Id, Message | Format-Table -AutoSize
    } else {
        Write-Host "$dc — No DFS-R critical events in the last 2 hours." -ForegroundColor Green
    }
}

DC-Lyon01 — No DFS-R critical events in the last 2 hours.
DC-Bordeaux01 — No DFS-R critical events in the last 2 hours.

Cross-références¶