Traitement des stratégies : cycle et modes¶

Vue d'ensemble du cycle de traitement¶

Le service gpsvc (Group Policy Client Service) est le chef d'orchestre de tout le traitement des GPO. Il ne dort jamais completement : il gere deux cycles distincts, chacun avec ses propres regles de declenchement.

Le cycle foreground se produit a des moments precisement definis du cycle de vie Windows — demarrage de la machine et ouverture de session utilisateur. Il est synchrone par defaut : le systeme attend que toutes les CSE aient fini avant de continuer.

Le cycle background se produit periodiquement, en tache de fond, pendant que l'utilisateur travaille. Il est leger par conception : de nombreuses CSE le sautent intentionnellement.

Ces deux cycles ne sont pas symetriques. Confondre leurs comportements est la source numero un des bugs de "la GPO ne s'applique pas".

Le traitement foreground¶

Quand se declenche-t-il ?¶

Le foreground machine se declenche au demarrage de la machine, avant que l'ecran de connexion n'apparaisse.

Le foreground utilisateur se declenche a l'ouverture de session, apres l'authentification mais avant que le bureau ne soit rendu visible.

Ces deux declencheurs sont discrets et invisibles a l'utilisateur final, mais ils constituent la fenetre d'application la plus importante pour les parametres critiques.

Mode synchrone vs mode asynchrone¶

Par defaut sur Windows 10 et 11, le foreground s'execute en mode asynchrone. Le bureau apparait pendant que les CSE continuent leur travail en arriere-plan. Le demarrage parait plus rapide, mais certains parametres ne sont pas encore appliques quand l'utilisateur commence a travailler.

En mode synchrone, Windows attend que toutes les CSE foreground aient termine avant d'afficher le bureau ou l'ecran de connexion. Le demarrage est plus long, mais les parametres sont garantis au moment ou l'utilisateur prend la main.

La cle de registre qui controle ce comportement est :

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
  SyncForegroundPolicy  REG_DWORD
    0 = asynchrone (defaut Windows 10/11)
    1 = synchrone

CSE qui exigent le mode synchrone¶

Certaines CSE ne peuvent pas fonctionner en mode asynchrone. Elles ont besoin que le systeme soit dans un etat stable avant de s'executer.

Folder Redirection (fdeploy.dll) doit absolument s'executer avant que le profil utilisateur ne soit charge. Si le bureau apparait avant que la redirection ne soit appliquee, le profil s'est charge depuis le mauvais emplacement. Le resultat : les documents de l'utilisateur pointent vers C:\Users\... au lieu du partage reseau.

Software Installation (appmgmts.dll) doit appliquer les installations et suppressions avant que l'utilisateur puisse lancer des applications. Un bureau asynchrone signifie qu'un utilisateur peut tenter de lancer une application qui est en cours d'installation.

Ces deux CSE positionnent le flag ERROR_SYNC_FOREGROUND_REFRESH_REQUIRED lors de leur premiere application, ce qui force Windows a passer en mode synchrone pour les cycles suivants jusqu'a ce que la situation soit stable.

Forcer le mode synchrone via GPO¶

La methode officielle pour activer le mode synchrone est via une GPO, pas via une modification directe du registre :

Computer Configuration
  → Administrative Templates
    → System
      → Logon
        → Always wait for the network at computer startup and logon

Cette GPO ecrit la valeur GpNetworkStartTimeoutPolicyValue et positionne SyncForegroundPolicy a 1.

$winlogon = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
$sync = (Get-ItemProperty $winlogon -ErrorAction SilentlyContinue).SyncForegroundPolicy
if ($null -eq $sync) {
    Write-Host "SyncForegroundPolicy: absent (asynchronous by default)"
} else {
    Write-Host "SyncForegroundPolicy: $sync ($(if ($sync -eq 1) {'synchronous'} else {'asynchronous'}))"
}

SyncForegroundPolicy: 1 (synchronous)

Le traitement background¶

L'intervalle de 90 minutes¶

Le traitement background se produit toutes les 90 minutes, avec une variation aleatoire de 0 a 30 minutes ajoutee a cet intervalle.

Cette randomisation n'est pas anodine. Sur un parc de 5 000 machines, si toutes interrogeaient les controleurs de domaine exactement au meme instant, la charge serait insoutenable. La variation aleatoire etale les requetes dans le temps.

L'intervalle effectif est donc compris entre 90 et 120 minutes pour la plupart des machines.

Configurer l'intervalle background¶

La GPO de configuration se trouve a :

Computer Configuration
  → Administrative Templates
    → System
      → Group Policy
        → Set Group Policy refresh interval for computers
        → Set Group Policy refresh interval for users

Les deux parametres sont distincts : l'un controle le refresh de la strategie machine, l'autre controle le refresh de la strategie utilisateur.

Les cles de registre correspondantes :

HKLM\SOFTWARE\Policies\Microsoft\Windows\System
  GroupPolicyRefreshTime        REG_DWORD  (minutes — intervalle de base)
  GroupPolicyRefreshTimeOffset  REG_DWORD  (minutes — variation aleatoire maximale)

Ce que le background ne fait pas¶

Le traitement background est deliberement allege. La plupart des CSE "lourdes" positionnent NoBackgroundPolicy = 1 et sont donc completement ignorees lors des refreshes periodiques.

Les CSE qui s'executent en background :

• Registry (ADMX) — NoBackgroundPolicy = 0 : applique les parametres de registre a chaque refresh
• Group Policy Preferences — NoBackgroundPolicy = 0 : applique les preferences a chaque refresh

Les CSE qui ignorent le background :

• Scripts, Folder Redirection, Software Installation et Audit Policy — toutes avec NoBackgroundPolicy = 1

$cseKey = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions"
Get-ChildItem $cseKey | ForEach-Object {
    $props = Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue
    $noBg  = $props.NoBackgroundPolicy
    [PSCustomObject]@{
        GUID         = $_.PSChildName
        Name         = $props.'(default)'
        BackgroundOK = if ($null -eq $noBg -or $noBg -eq 0) { "Oui" } else { "Non" }
    }
} | Where-Object { $_.BackgroundOK -eq "Oui" } | Format-Table -AutoSize

GUID                                   Name                     BackgroundOK
----                                   ----                     ------------
{35378EAC-683F-11D2-A89A-00C04FBBCFA2} Registry                 Oui
{0E28E245-9368-4853-AD84-6DA3BA35BB75} Group Policy Preferences  Oui

Detection de lien lent¶

Le seuil de 500 Kbps¶

Avant d'appliquer les GPO, gpsvc mesure la vitesse de la connexion vers le controleur de domaine. Si cette vitesse est inferieure au seuil configure, la connexion est qualifiee de lien lent (slow link).

Le seuil par defaut est de 500 Kbps (kilobits par seconde, pas kilooctets).

La GPO de configuration :

Computer Configuration
  → Administrative Templates
    → System
      → Group Policy
        → Configure Group Policy slow link detection

La cle de registre correspondante :

HKLM\SOFTWARE\Policies\Microsoft\Windows\System
  GroupPolicyMinTransferRate  REG_DWORD  (Kbps)
    0 = toujours considerer comme lien rapide
    500 = seuil par defaut

Comportement des CSE sur lien lent¶

Chaque CSE declare son comportement sur lien lent via le flag NoSlowLink dans sa cle de registre GPExtensions.

Les CSE qui s'executent sur lien lent sont celles dont les donnees a transferer sont legeres (fichiers registry.pol, fichiers de preferences XML). Les CSE qui sont ignorees sont celles qui necessitent le telechargement de fichiers volumineux depuis SYSVOL (packages MSI, scripts).

Journalisation de la detection de lien lent¶

La detection de lien lent est journalisee dans le journal operationnel Group Policy :

• Event ID 5314 : lien lent detecte (avec la vitesse mesuree en Kbps)
• Event ID 5315 : lien rapide detecte

Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 1000 |
    Where-Object { $_.Id -in @(5314, 5315) } |
    Select-Object TimeCreated, Id,
        @{N="Type"; E={ if ($_.Id -eq 5314) {"Lien lent"} else {"Lien rapide"} }},
        @{N="Detail"; E={ $_.Message -replace "`n"," " }} |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 20 |
    Format-Table -AutoSize -Wrap

TimeCreated             Id   Type       Detail
-----------             --   ----       ------
2026-04-05 08:32:11     5315 Lien rapide The network bandwidth is 125000 Kbps...
2026-04-04 08:30:44     5315 Lien rapide The network bandwidth is 125000 Kbps...

gpupdate : syntaxe complete et variantes¶

Reference des parametres¶

gpupdate est la commande qui declenche manuellement un cycle de traitement Group Policy. Elle accepte plusieurs parametres qui modifient finement son comportement.

Exemples pratiques¶

gpupdate /force /wait:-1

# Does not disturb the current user session
gpupdate /target:computer /force

# Useful for Software Installation policies that require a restart
gpupdate /force /boot

# The user will be logged off after GPO processing
gpupdate /force /logoff

Refresh a distance via PowerShell¶

Invoke-GPUpdate est l'equivalent PowerShell de gpupdate, mais il peut cibler des machines distantes. Il s'appuie sur WMI pour creer une tache planifiee temporaire sur la machine cible.

Invoke-GPUpdate -Computer "PC-DUPONT" -Force -RandomDelayInMinutes 0

$ou = "OU=Postes-Standard,DC=contoso,DC=local"
Get-ADComputer -Filter * -SearchBase $ou |
ForEach-Object {
    try {
        Invoke-GPUpdate -Computer $_.Name -Force -RandomDelayInMinutes 0 -ErrorAction Stop
        Write-Host "Updated: $($_.Name)" -ForegroundColor Green
    } catch {
        Write-Warning "Failed: $($_.Name) — $_"
    }
}

Updated: PC-ALICE
Updated: PC-BOB
WARNING: Failed: PC-CHARLIE — The computer 'PC-CHARLIE' cannot be reached...
Updated: PC-DENIS

Refresh via la GPMC¶

La GPMC (Group Policy Management Console) integre depuis Windows Server 2012 une fonctionnalite de refresh de masse.

1. Dans la GPMC, faire un clic droit sur une OU
2. Selectionner "Group Policy Update..."
3. La GPMC envoie via WMI une tache planifiee temporaire a chaque ordinateur de l'OU
4. Chaque machine execute gpupdate /force avec un delai aleatoire de 0 a 10 minutes

Cette interface est un alias graphique de Invoke-GPUpdate applique a tous les membres de l'OU. Elle n'est pas recursive : elle ne descend pas dans les sous-OU sauf si vous la lancez depuis chaque OU individuellement.

Le journal d'evenements Group Policy Operational¶

Acces au journal¶

Le journal operationnel Group Policy se trouve sous :

Observateur d'evenements
  → Journaux des applications et des services
    → Microsoft
      → Windows
        → GroupPolicy
          → Operational

Ce journal enregistre chaque etape du cycle de traitement, de la liste des GPO applicables jusqu'a l'execution de chaque CSE individuelle.

Reference des Event IDs essentiels¶

Extraire les durees de traitement¶

$events = Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 500 |
    Where-Object { $_.Id -in @(4001, 4002, 4003, 4004) }

$events | Select-Object TimeCreated, Id,
    @{N="Contexte"; E={ if ($_.Id -in @(4001, 4004)) {"Machine"} else {"Utilisateur"} }},
    @{N="Phase";    E={ if ($_.Id -in @(4001, 4002)) {"Debut"} else {"Fin"} }} |
    Sort-Object TimeCreated |
    Format-Table -AutoSize

TimeCreated             Id   Contexte     Phase
-----------             --   --------     -----
2026-04-05 08:30:01     4001 Machine      Debut
2026-04-05 08:30:04     4004 Machine      Fin
2026-04-05 08:30:22     4002 Utilisateur  Debut
2026-04-05 08:30:31     4003 Utilisateur  Fin

Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 200 |
    Where-Object { $_.Id -eq 4017 } |
    ForEach-Object {
        $xml = [xml]$_.ToXml()
        $ns  = @{ e = "http://schemas.microsoft.com/win/2004/08/events/event" }
        $cse = (Select-Xml -Xml $xml -Namespace $ns -XPath "//e:Data[@Name='CSEExtensionName']").Node.'#text'
        $ms  = (Select-Xml -Xml $xml -Namespace $ns -XPath "//e:Data[@Name='ElapsedTimeInMilliseconds']").Node.'#text'
        [PSCustomObject]@{
            Time         = $_.TimeCreated
            CSE          = $cse
            DurationMs   = [int]$ms
            DurationSec  = [math]::Round([int]$ms / 1000, 2)
        }
    } |
    Sort-Object DurationMs -Descending |
    Format-Table -AutoSize

Time                    CSE                              DurationMs DurationSec
----                    ---                              ---------- -----------
2026-04-05 08:30:22     Group Policy Preferences         4823       4.82
2026-04-05 08:30:22     Security                         1201       1.20
2026-04-05 08:30:22     Registry                         312        0.31
2026-04-05 08:30:22     Scripts                          89         0.09

Lire la liste des GPO applicables¶

L'Event ID 5312 contient la liste complete des GPO qui ont ete appliquees lors du cycle. L'Event ID 5313 liste celles qui ont ete ecartees, avec la raison.

$cycleEvents = Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 500 |
    Where-Object { $_.Id -in @(5312, 5313) } |
    Select-Object -First 20

$cycleEvents | Select-Object TimeCreated, Id,
    @{N="Statut"; E={ if ($_.Id -eq 5312) {"Appliquee"} else {"Ignoree"} }},
    @{N="Detail"; E={ ($_.Message -split "`n")[1..3] -join " " }} |
    Format-Table -AutoSize -Wrap

# Check and configure the operational log
$log = Get-WinEvent -ListLog "Microsoft-Windows-GroupPolicy/Operational"
$log.IsEnabled
$log.MaximumSizeInBytes  # default: 4 MB — consider increasing to 20 MB

Traitement sans reseau et WaitForNetwork¶

Quand le reseau n'est pas disponible¶

Au demarrage, si gpsvc ne peut pas joindre un controleur de domaine, il ne reste pas bloque indefiniment. Apres un delai configurable, il bascule sur le cache local et applique la derniere configuration connue.

La cle qui controle ce delai d'attente :

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
  GpNetworkStartTimeoutPolicyValue  REG_DWORD  (secondes)

La valeur par defaut est de 30 secondes sur les machines recentes.

Comportement apres basculement sur cache¶

Quand gpsvc applique les politiques depuis le cache local, il ecrit dans le journal operationnel un evenement specifique. Le cycle est considere comme "partiellement reussi" : les parametres de la derniere session sont preserves, mais les eventuels changements de GPO depuis le dernier cycle ne sont pas visibles.

Point critique : une fois que gpsvc a traite le foreground depuis le cache (avec ou sans reseau), il ne retraite pas automatiquement les GPO quand le reseau devient disponible en cours de session. Le prochain cycle foreground aura lieu au prochain demarrage ou a la prochaine ouverture de session.

Fast Startup (Hiberboot) et impact sur les GPO¶

Fast Startup, ou Hiberboot, est un arrêt hybride. Au lieu de repartir d'un démarrage entièrement froid, Windows conserve une partie de l'état noyau dans le fichier d'hibernation pour accélérer le prochain allumage.

Ce comportement est utile côté expérience utilisateur, mais il perturbe souvent le diagnostic GPO. Un administrateur pense avoir testé un "redémarrage" après modification de GPO, alors que l'utilisateur a seulement effectué un arrêt puis rallumage avec démarrage rapide.

La clé de contrôle principale :

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power
  HiberbootEnabled  REG_DWORD
    0 = Fast Startup désactivé
    1 = Fast Startup activé

Effet opérationnel¶

Les traitements foreground sensibles au démarrage doivent être testés avec un vrai Restart, pas avec Shutdown puis bouton d'alimentation. Cela concerne notamment :

• les GPO machine appliquées au démarrage ;
• certaines CSE qui nécessitent un cycle foreground ;
• les scripts de démarrage ;
• les scénarios Always wait for the network at computer startup and logon ;
• les changements attendus sur VPN, Wi-Fi ou stations portables.

Pilotage GPO¶

La stratégie ADMX Require use of fast startup se trouve sous :

Computer Configuration → Administrative Templates → System → Shutdown

Elle sert surtout à imposer l'usage du démarrage rapide quand il est compatible. Pour le désactiver de manière explicite sur un parc administré, une approche courante consiste à pousser la valeur registre via GPP Registry ou baseline de configuration :

New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power" -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power" `
    -Name "HiberbootEnabled" -PropertyType DWord -Value 0 -Force

Le cache local des GPO¶

Emplacement des caches¶

Windows maintient deux caches GPO distincts sur chaque machine.

Le cache machine (Computer Policy) :

%SystemRoot%\System32\GroupPolicy\

Le cache utilisateur (User Policy, un repertoire par SID utilisateur) :

%SystemRoot%\System32\GroupPolicyUsers\{SID-de-l-utilisateur}\

Ces repertoires contiennent une copie locale du Group Policy Template (GPT) telecharge depuis SYSVOL lors du dernier cycle.

Mecanisme d'invalidation du cache¶

gpsvc compare la version de la GPO en cache avec la version en cours dans Active Directory. Chaque GPO possede un attribut versionNumber dans son objet GPC (Group Policy Container). Ce numero est incremente a chaque modification dans la GPMC.

Si le versionNumber dans AD est superieur a celui dans le cache local, gpsvc re-telecharge le GPT complet depuis SYSVOL avant d'appeler la CSE correspondante.

Si le versionNumber est identique, gpsvc utilise les fichiers caches locaux et n'effectue aucun transfert reseau pour cette GPO.

Ce mecanisme est la raison pour laquelle les GPO non modifiees n'impliquent pas de trafic reseau lors des refreshes periodiques.

Vider le cache pour forcer un re-telechargement¶

Il est parfois necessaire de vider le cache local pour forcer un telechargement complet depuis SYSVOL. Cela est utile quand on suspecte une corruption du cache ou apres une restauration de GPO.

# Stop Group Policy Client Service before clearing cache
Stop-Service gpsvc -Force

# Clear machine policy cache
Remove-Item "$env:SystemRoot\System32\GroupPolicy\*" -Recurse -Force -ErrorAction SilentlyContinue

# Clear all user policy caches
Remove-Item "$env:SystemRoot\System32\GroupPolicyUsers\*" -Recurse -Force -ErrorAction SilentlyContinue

# Restart the service
Start-Service gpsvc

# Trigger a full refresh (all CSEs will re-download from SYSVOL)
gpupdate /force /wait:-1
Write-Host "Cache cleared and full GPO refresh triggered." -ForegroundColor Green

Updating Policy...
User Policy update has completed successfully.
Computer Policy update has completed successfully.
Cache cleared and full GPO refresh triggered.

Flowchart du cycle complet¶

Le diagramme suivant represente le flux de decisions complet d'un cycle foreground, depuis le declenchement jusqu'a la journalisation du resultat.

flowchart TD
    A([Demarrage / Ouverture de session]) --> B{Reseau disponible ?}
    B -->|Non — timeout echu| C[Traitement depuis cache local]
    B -->|Oui| D[gpsvc interroge AD\nListe des GPO applicables]
    C --> O
    D --> E{Vitesse de lien\nmesurée ?}
    E -->|Inferieure a 500 Kbps| F[Lien lent — Event 5314\nExclure CSE avec NoSlowLink=1]
    E -->|Superieure a 500 Kbps| G[Lien rapide — Event 5315\nToutes les CSE applicables]
    F --> H[Pour chaque CSE applicable]
    G --> H
    H --> I{versionNumber GPO\nchange depuis cache ?}
    I -->|Non + NoGPOListChanges=1| J([CSE ignoree — aucun log])
    I -->|Oui ou NoGPOListChanges=0| K[Telechargement GPT\ndepuis SYSVOL]
    K --> L[Appel ProcessGroupPolicyEx\navec jeton + flags]
    L --> M{Resultat ?}
    M -->|Succes| N[Event 5016 — CSE appliquee]
    M -->|Avertissement| P[Event 5017 — Application partielle]
    M -->|Echec| Q[Event 5018 — Echec CSE]
    N --> R{Autres CSE\na traiter ?}
    P --> R
    Q --> R
    R -->|Oui| H
    R -->|Non| O([Cycle termine\nEvents 4003 / 4004])

Interactions entre les mecanismes¶

Comment les mecanismes s'influencent¶

Les differents mecanismes decrits dans ce chapitre ne sont pas independants. Ils interagissent a chaque cycle de traitement.

Un exemple concret : machine portable, utilisateur itinerant, VPN.

1. La machine demarre hors reseau → basculement sur le cache local apres 30 secondes
2. L'utilisateur ouvre une session → policies appliquees depuis le cache, versions en retard
3. L'utilisateur se connecte au VPN → le reseau est desormais disponible
4. Le prochain background refresh (dans 90 a 120 minutes) s'execute
5. gpsvc detecte le lien VPN → mesure de bande passante
6. Si la bande passante est inferieure a 500 Kbps → lien lent, Folder Redirection ignoree
7. Les parametres de registre et les preferences sont mis a jour via le cache invalide
8. La securite peut se reappliquer, mais Folder Redirection et les autres CSE foreground-only attendent toujours un vrai foreground

Ce scenario illustre pourquoi un utilisateur portable peut avoir des parametres incoherents en journee — et pourquoi la solution n'est pas seulement gpupdate /force : pour Folder Redirection et les autres CSE foreground-only, il faut un redemarrage ou une reconnexion avec reseau disponible.

Recapitulatif des intervalles et seuils¶

Cross-references¶