Introduction et histoire des stratégies de groupe¶

Contexte historique : de System Policy à Group Policy¶

NT 4.0 — System Policy et l'effet de tatouage¶

La gestion centralisée des postes Windows démarre avec Windows NT 4.0 et l'outil poledit.exe (System Policy Editor). Le mécanisme repose sur un fichier NTConfig.pol déposé dans le partage NETLOGON du contrôleur de domaine.

Au téléchargement du fichier de stratégie, poledit.exe écrit les valeurs directement dans la ruche utilisateur (HKCU) ou machine (HKLM) du poste client. Ce comportement est connu sous le nom d'effet de tatouage (tattooing) : les modifications persistent dans le registre même après la suppression ou la désactivation de la stratégie. Il n'existe aucun mécanisme de nettoyage automatique.

Conséquences opérationnelles directes :

Les fichiers ADM (Administrative Template) sont au format texte proprietaire. Ils sont embarques dans chaque GPO et decrivent les parametres exposes dans l'interface graphique de poledit.exe.

Windows 2000 — Group Policy v1¶

Windows 2000 introduit le modèle Group Policy au sens moderne du terme. Le moteur de traitement est Userenv.dll, chargé dans le processus Winlogon.exe au démarrage de la machine et à la session utilisateur.

L'architecture repose sur deux composants distincts stockés à deux endroits différents (détaillés dans la section suivante) :

• GPC (Group Policy Container) : objet AD de classe groupPolicyContainer dans l'annuaire
• GPT (Group Policy Template) : dossier dans SYSVOL identifié par le GUID de la GPO

La réversibilité est le changement fondamental par rapport à NT 4.0. Les paramètres définis dans un GPO sont stockés dans des sections dédiées du registre (HKLM\SOFTWARE\Policies\ et HKCU\SOFTWARE\Policies\) et sont supprimés automatiquement quand la GPO cesse de s'appliquer. Ce n'est plus du tatouage : c'est une configuration temporaire gérée par le moteur.

L'ordre d'application LSDOU (Local → Site → Domain → OU) est formalisé. Le SYSVOL, répliqué par FRS entre tous les contrôleurs de domaine, sert de point de distribution unique pour les fichiers de stratégie.

Le GPMC n'existe pas encore : la gestion des GPO se fait via Active Directory Users and Computers, la console gpedit.msc, et des manipulations ACL manuelles dans ADSI Edit pour les filtrages avancés.

Windows Server 2003 — GPMC et RSoP¶

Server 2003 apporte Gpmc.msc (Group Policy Management Console), téléchargeable séparément puis intégré au système. C'est le premier outil unifié pour la création, la liaison, la gestion des ACL et la sauvegarde/restauration des GPO.

Fonctionnalités introduites :

• RSoP (Resultant Set of Policy) : snap-in MMC permettant de simuler ou de journaliser les stratégies effectivement appliquées à un utilisateur ou une machine
• GPMC : console d'administration centralisee des GPO, avec sauvegarde XML et vue unifiee
• Software Restriction Policies (SRP) : premier mécanisme de contrôle d'exécution applicatif via GPO
• Copier/coller de GPO et sauvegarde XML depuis la GPMC

Les fichiers ADM restent dans leur format texte proprietaire et sont toujours dupliques dans chaque GPO sous \{GUID}\Adm\.

Windows Vista / Server 2008 — ADMX, GPP et extraction de gpsvc¶

Deux ruptures majeures se produisent simultanément :

1. Remplacement ADM → ADMX

Le format texte proprietaire ADM est remplace par ADMX (XML pur) accompagne de fichiers de langue ADML (XML egalement). Le concept de Central Store est introduit : un repertoire unique \\domain\SYSVOL\domain\Policies\PolicyDefinitions\ heberge l'ensemble des ADMX/ADML du domaine, eliminant la duplication par GPO.

2. Group Policy Preferences (GPP)

25 types d'extensions de préférences sont introduits via le nouveau CSE gpprefcl.dll. Contrairement aux paramètres de stratégie classiques, les préférences peuvent être configurées pour ne pas écraser les modifications locales (comportement Update vs Replace). Les types couvrent : lecteurs réseau, imprimantes, clés de registre, fichiers, raccourcis, variables d'environnement, tâches planifiées, sources de données ODBC, etc.

3. Extraction de gpsvc de Winlogon

Le moteur de traitement est extrait de Winlogon.exe et devient le service Group Policy Client (gpsvc), s'exécutant dans un processus svchost.exe -k netsvcs. Ce découplage permet le traitement asynchrone, une meilleure isolation des erreurs, et la reprise du traitement sans nécessiter de redémarrage ou de fermeture de session.

Windows 7 / Server 2008 R2¶

• Module PowerShell GroupPolicy : disponible via RSAT, expose les cmdlets Get-GPO, Set-GPRegistryValue, Get-GPResultantSetOfPolicy, etc.
• AppLocker : remplace SRP, basé sur des règles par éditeur, chemin ou hash, avec une infrastructure d'audit plus fine
• Amélioration de la détection des liaisons lentes (slow link) : seuil configurable via GPO, permettant de désactiver certains CSE sur les connexions à faible bande passante

Windows 8 / Server 2012¶

• Adoption généralisée du Central Store ADMX dans les nouvelles infrastructures
• AGPM 4.0 (Advanced Group Policy Management) : gestion du cycle de vie des GPO avec workflow d'approbation
• Nouveaux ADMX pour les fonctionnalités Windows 8 (Internet Explorer 10, Store, etc.)
• Fine-Grained Password Policies administrables via PowerShell et ADAC plutot que directement depuis le GPMC

Windows 10 / Server 2016 — Cloud Policy¶

• Cloud Policy pour Microsoft 365 Apps : application de paramètres via le service config.office.com sans nécessiter de GPO AD
• Windows Update for Business : nouveaux ADMX pour le contrôle des déploiements de mises à jour via GPO (HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate)
• MDM enrollment : les postes joints à Azure AD peuvent être gérés par Intune indépendamment des GPO AD — la coexistence commence

Windows 11 / Server 2022 — Coexistence MDM¶

• JSON Start menu layout : le format XML de configuration du menu Démarrer (hérité de Windows 10) est remplacé par un format JSON via le paramètre ConfigureStartPins
• Nouveaux ADMX pour Widgets, Copilot, et fonctionnalités cloud
• Policy CSP : les paramètres GPO classiques sont mis en miroir dans le protocole MDM de Windows, permettant à Intune de gérer des paramètres historiquement réservés aux GPO AD
• cloudpolicysettings ADMX : permet de configurer depuis GPMC le comportement des stratégies cloud Microsoft 365
• Priorité de résolution en cas de conflit GPO/MDM : configurable via HKLM\SOFTWARE\Policies\Microsoft\Windows\CloudManagedSettings

Tableau de référence : évolution par version Windows¶

L'architecture fondamentale : GPC + GPT + Lien¶

Une GPO n'est pas un objet unique. Elle est constituée de deux composants distincts synchronisés, liés à des conteneurs AD via un attribut.

GPC — Group Policy Container¶

Le GPC est un objet AD de classe groupPolicyContainer, stocké dans :

CN={GUID},CN=Policies,CN=System,DC=domain,DC=tld

Il contient les métadonnées de la GPO : nom d'affichage, GUID, état (activé/désactivé pour le volet machine ou utilisateur), et surtout l'attribut versionNumber qui sert à la synchronisation avec le GPT.

Attributs LDAP clés du GPC :

GPT — Group Policy Template¶

Le GPT est un dossier dans SYSVOL :

\\domain\SYSVOL\domain\Policies\{GUID}\

Structure interne du dossier GPT :

{GUID}\
├── GPT.INI              ← version, DisplayName
├── Machine\
│   ├── Registry.pol     ← paramètres registre machine
│   ├── Scripts\         ← scripts Startup/Shutdown
│   └── Preferences\     ← données GPP machine
└── User\
    ├── Registry.pol     ← paramètres registre utilisateur
    ├── Scripts\         ← scripts Logon/Logoff
    └── Preferences\     ← données GPP utilisateur

Le fichier GPT.INI contient le numéro de version et le nom de la GPO :

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

Le numéro de version dans GPT.INI est un entier 32 bits dont les 16 bits de poids fort représentent la version utilisateur et les 16 bits de poids faible la version machine. Il doit correspondre à l'attribut versionNumber du GPC.

Lien — attribut gPLink¶

Le lien n'est pas un objet AD séparé. Il est représenté par l'attribut gPLink sur le conteneur cible (Site, domaine ou OU). Sa valeur est une chaîne qui liste les GPO liées avec leur statut :

[LDAP://cn={GUID1},cn=Policies,cn=System,DC=...;0][LDAP://cn={GUID2},...;2]

Valeurs du flag de lien :

L'attribut gPLinkOptions sur l'OU/domaine/site contrôle le Block Inheritance (1 = héritage bloqué).

Désynchronisation GPC/GPT : Event 1058¶

Quand le versionNumber du GPC ne correspond pas au champ Version de GPT.INI, le client considère la GPO comme corrompue ou inaccessible. Cela génère les événements suivants dans le journal System ou Applications and Services Logs\Microsoft\Windows\GroupPolicy\Operational :

Diagramme : évolution chronologique¶

timeline
    title Évolution des stratégies de groupe Windows
    section Ère System Policy
        1996 : NT 4.0 — poledit.exe, tatouage ADM
    section Ère Group Policy
        2000 : Windows 2000 — GPC/GPT, LSDOU, SYSVOL, Userenv.dll
        2003 : Server 2003 — GPMC, RSoP, SRP
    section Ère ADMX
        2007 : Vista/2008 — ADMX/ADML, Central Store, GPP (gpprefcl.dll), Starter GPOs, gpsvc séparé
        2009 : Windows 7 — Module PowerShell RSAT, AppLocker
        2012 : Server 2012 — AGPM 4.0, Central Store généralisé
    section Ère Cloud
        2015 : Windows 10 — Cloud Policy M365, WUfB, MDM partiel
        2021 : Windows 11 — JSON Start, Policy CSP, MDM coexistence

De ADM à ADMX : la rupture de format¶

Le format ADM et ses limites¶

Les fichiers ADM (Administrative Template) utilisés jusqu'à Windows Server 2003 sont en format texte proprietaire. Chaque GPO embarque ses propres copies dans \\domain\SYSVOL\domain\Policies\{GUID}\Adm\. Cette architecture impose :

• Duplication : les fichiers ADM standards de Windows (environ 3 Mo par GPO pour les templates Microsoft) sont copiés dans chaque GPO, entraînant une consommation SYSVOL significative sur les domaines avec de nombreuses GPO
• Absence d'Unicode complet : certaines locales posent des problèmes d'encodage
• Pas de séparation structure/langue : un fichier ADM unique contient à la fois la définition des paramètres et les textes de l'interface dans une seule langue
• Pas de namespacing : risque de collision entre templates tiers

Le format ADMX/ADML¶

ADMX (Administrative Template XML) est un fichier XML pur qui décrit les paramètres, leurs chemins de registre, leurs valeurs possibles et leurs métadonnées. Il est accompagné de fichiers ADML (Administrative Template Language), également XML, qui contiennent les chaînes de texte de l'interface dans une langue donnée.

Structure d'un ADMX :

<!-- Extrait type d'un ADMX Microsoft -->
<policy name="AllowTelemetry"
        class="Machine"
        displayName="$(string.AllowTelemetry)"
        explainText="$(string.AllowTelemetry_Help)"
        key="SOFTWARE\Policies\Microsoft\Windows\DataCollection"
        valueName="AllowTelemetry">
  <parentCategory ref="DataCollection" />
  <supportedOn ref="windows:SUPPORTED_Windows10" />
  <elements>
    <enum id="AllowTelemetry_Enum" valueName="AllowTelemetry">
      <item displayName="$(string.AllowTelemetry_0)">
        <value><decimal value="0" /></value>
      </item>
    </enum>
  </elements>
</policy>

Le Central Store¶

Le Central Store est un répertoire SYSVOL créé manuellement (il n'existe pas par défaut) :

\\domain\SYSVOL\domain\Policies\PolicyDefinitions\
├── *.admx                     ← fichiers de définition (langage-neutre)
└── fr-FR\
│   └── *.adml                 ← fichiers de langue français
└── en-US\
    └── *.adml                 ← fichiers de langue anglais

Quand ce dossier existe, la GPMC l'utilise automatiquement à la place du répertoire local %SystemRoot%\PolicyDefinitions\ de l'éditeur. Si le Central Store est absent, la GPMC utilise le répertoire local de la machine sur laquelle elle est exécutée — comportement source d'incohérences entre admins.

Impact sur les GPO existantes basées sur ADM¶

La migration vers ADMX ne nécessite aucune action sur les GPO existantes. Le moteur de traitement côté client (CSE) lit uniquement le fichier registry.pol — il ne consulte jamais les fichiers ADMX ou ADM. Les paramètres configurés avec d'anciens templates ADM continuent de s'appliquer.

En revanche, dans la GPMC, les paramètres configurés depuis des templates ADM dont l'ADMX équivalent est absent apparaissent sous la section "Extra Registry Settings". C'est un indicateur visuel, pas un dysfonctionnement.

Les templates ADM tiers (anciens templates Office, templates de navigateurs obsolètes) restent visibles dans cette section jusqu'à :

1. La suppression des valeurs de registry.pol correspondantes
2. Ou l'ajout des ADMX équivalents dans le Central Store

Détection des GPO avec paramètres ADM résiduels¶

# Find GPOs with legacy ADM settings (Extra Registry Settings)
Get-GPO -All | ForEach-Object {
    $report = Get-GPOReport -Guid $_.Id -ReportType Xml
    if ($report -match "ExtraRegistrySettings") {
        [PSCustomObject]@{
            Name     = $_.DisplayName
            Guid     = $_.Id
            Created  = $_.CreationTime
            Modified = $_.ModificationTime
        }
    }
} | Format-Table -AutoSize

Name                          Guid                                 Created              Modified
----                          ----                                 -------              --------
Legacy IE Settings GPO        {4A2F3B1C-...}                       15/03/2018 14:22:00  02/01/2023 09:11:00
Old Office 2010 Templates     {7C9E2D4F-...}                       20/06/2016 10:05:00  14/09/2021 16:44:00

Gouvernance des GPO¶

Une GPO est un objet de production. Elle mérite donc les mêmes réflexes qu'un changement système : nommage, propriétaire, sauvegarde, revue, historique et procédure de retour arrière.

Sans gouvernance, le domaine finit par accumuler des GPO sans lien, sans propriétaire, avec des paramètres contradictoires ou hérités d'une migration ancienne. Le problème n'est pas seulement esthétique : chaque GPO inutile augmente le temps de traitement, le bruit d'audit et le risque de conflit silencieux.

Sauvegarde, restauration et copie¶

$backupRoot = "\\fileserver\gpo-backup\$(Get-Date -Format yyyyMMdd-HHmm)"
New-Item -ItemType Directory -Path $backupRoot -Force | Out-Null
Backup-GPO -All -Path $backupRoot

Restore-GPO -Name "SEC-WKS-Defender-Baseline" -Path "\\fileserver\gpo-backup\20260407-0900"

Copy-GPO -SourceName "SEC-WKS-Defender-Baseline" `
    -TargetName "SEC-WKS-Defender-Baseline-Pilot" `
    -CopyAcl

AGPM et workflow de changement¶

Advanced Group Policy Management ajoute une logique de coffre, check-in/check-out, approbation et déploiement. Il reste pertinent dans les environnements où plusieurs équipes modifient les GPO.

Même sans AGPM, imposez un workflow minimal :

• un propriétaire par GPO ;
• une raison métier ;
• un ticket de changement ;
• une phase pilote ;
• une date de revue ;
• une sauvegarde avant modification.

Export Git des rapports GPO¶

Le contenu binaire et les ACL d'une GPO ne se versionnent pas parfaitement dans Git. En revanche, les rapports XML ou HTML sont excellents pour relire les changements.

$exportRoot = "C:\GPO-Reports"
New-Item -ItemType Directory -Path $exportRoot -Force | Out-Null

Get-GPO -All | ForEach-Object {
    $safeName = $_.DisplayName -replace '[\\/:*?"<>|]', '_'
    Get-GPOReport -Guid $_.Id -ReportType Xml `
        -Path (Join-Path $exportRoot "$safeName.xml")
}

Ce dépôt ne doit pas contenir de secret. Relisez les scripts, les préférences avec mots de passe hérités et les chemins internes avant publication hors zone admin.

Convention de nommage¶

Le nom doit indiquer la cible et l'intention. Une GPO appelée New Group Policy Object en production est un incident de gouvernance.

Nettoyage des GPO orphelines¶

Get-GPO -All | Where-Object { $_.GpoStatus -ne "AllSettingsDisabled" } |
    ForEach-Object {
        $report = [xml](Get-GPOReport -Guid $_.Id -ReportType Xml)
        if (-not $report.GPO.LinksTo) {
            [PSCustomObject]@{
                Name         = $_.DisplayName
                Id           = $_.Id
                ModifiedTime = $_.ModificationTime
            }
        }
    } | Sort-Object ModifiedTime

$cutoff = (Get-Date).AddMonths(-18)
Get-GPO -All |
    Where-Object { $_.ModificationTime -lt $cutoff } |
    Select-Object DisplayName, GpoStatus, CreationTime, ModificationTime |
    Sort-Object ModificationTime

Le moteur de traitement : de Userenv.dll à gpsvc¶

NT 4.0 — XP / Server 2003 : Userenv.dll dans Winlogon¶

De Windows NT 4.0 à Windows XP / Server 2003, le moteur de traitement des stratégies est Userenv.dll, chargé directement dans le processus Winlogon.exe. Ce couplage fort avec Winlogon implique :

• Le traitement de stratégie est synchrone par défaut : la session ne s'ouvre qu'après la fin du traitement (sauf configuration explicite du traitement asynchrone via GPO)
• Un CSE défaillant peut bloquer ou ralentir l'ouverture de session
• Pas de reprise possible sans redémarrage ou fermeture/ouverture de session
• Les journaux d'événements liés aux GPO sont dans le journal System (sources Userenv, SceCli)

Clés de registre associées (configuration du comportement de traitement) :

Vista+ : le service gpsvc¶

À partir de Windows Vista, Userenv.dll est remplacé par le service Group Policy Client (gpsvc). Ce service s'exécute dans un processus svchost.exe -k netsvcs partagé avec d'autres services système.

Configuration du service dans le registre :

Responsabilités du service gpsvc :

1. Récupération de la liste des GPO : requête LDAP vers le DC le plus proche pour lire les attributs gPLink et gPOptions sur le site, le domaine et les OU parentes
2. Accès SYSVOL : connexion SMB vers \\domain\SYSVOL pour lire les GPT
3. Invocation des CSE : appel de chaque CSE (DLL enregistrée dans HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions) en passant la liste des GPO ajoutées, supprimées et modifiées
4. Cache des résultats : écriture dans %SystemRoot%\System32\GroupPolicy\ et %SystemRoot%\System32\GroupPolicyUsers\
5. Journalisation opérationnelle : écriture dans Microsoft-Windows-GroupPolicy/Operational

Cache du traitement GPO :

%SystemRoot%\System32\GroupPolicy\
├── Adm\           ← templates ADM locaux (si pas de Central Store)
├── DataStore\     ← cache XML des GPO traitées
└── Machine\
    ├── Registry.pol
    └── Scripts\

%SystemRoot%\System32\GroupPolicyUsers\{UserSID}\
└── User\
    ├── Registry.pol
    └── Scripts\

Traçabilité : journal Operational¶

Le journal Microsoft-Windows-GroupPolicy/Operational (disponible depuis Vista) est la source principale pour le diagnostic. Il trace l'intégralité d'un cycle de traitement :

FRS vers DFS-R : la migration SYSVOL¶

FRS — origines et obsolescence¶

Le service FRS (File Replication Service) assure la réplication SYSVOL depuis Windows 2000. Il repose sur le protocole NtFrs (service NtFrs.exe) et utilise une base de données Jet pour le suivi des modifications.

FRS est déprécié depuis Windows Server 2008 et supprimé dans Windows Server 2022. Les domaines dont le niveau fonctionnel est inférieur à Windows Server 2008, ou ceux dont le SYSVOL n'a jamais été migré, fonctionnent toujours sur FRS si les contrôleurs de domaine sont encore présents.

Limites de FRS connues :

DFS-R — remplacement et migration¶

DFS-R (Distributed File System Replication) utilise le protocole MS-FRS2, avec compression différentielle (RDC, Remote Differential Compression), throttling de bande passante configurable, et une résolution de conflits par horodatage et taille de fichier.

La migration est gérée par dfsrmig.exe et s'effectue en 4 états séquentiels :

Vérification de l'état de migration¶

# Check global SYSVOL migration state
dfsrmig /getglobalstate

# Check SYSVOL migration state on each domain controller
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    try {
        $state = Invoke-Command -ComputerName $dc -ScriptBlock {
            dfsrmig /getglobalstate 2>&1
        } -ErrorAction Stop
        [PSCustomObject]@{
            DC    = $dc
            Site  = $_.Site
            State = ($state | Out-String).Trim()
        }
    }
    catch {
        [PSCustomObject]@{
            DC    = $dc
            Site  = $_.Site
            State = "UNREACHABLE: $_"
        }
    }
} | Format-Table -AutoSize

DC                          Site         State
--                          ----         -----
dc01.corp.contoso.com       Paris        Current DFSR global state: 'Eliminated (3)'.
dc02.corp.contoso.com       Lyon         Current DFSR global state: 'Eliminated (3)'.
dc03.corp.contoso.com       Remote-VPN   Current DFSR global state: 'Eliminated (3)'.

Event IDs SYSVOL et DFS-R¶

Group Policy Preferences : les 25 types d'extensions¶

Introduites avec Windows Vista / Server 2008 et rétrocompatibles jusqu'à Windows XP SP3 via l'installation manuelle du client GPP, les Group Policy Preferences sont orchestrees par gpprefcl.dll et ses sous-extensions. Elles ne reposent pas sur un GUID nul unique faisant office de CSE.

Différence structurelle entre Paramètres et Préférences¶

Les 25 types de préférences GPP¶

Volet Machine :

Volet Utilisateur : Drive Maps, Environment, Files, Folders, INI Files, Registry, Shortcuts, Data Sources, Applications (Microsoft Office), Internet Settings, Local Users and Groups, Network Options, Power Options, Printers, Regional Options, Scheduled Tasks, Start Menu.

Débogage des GPP¶

Les erreurs de traitement GPP sont journalisées dans le journal Applications and Services Logs\Microsoft-Windows-GroupPolicy\Operational avec les Event IDs 4016 (début) et 4017 (fin) par extension. Les erreurs spécifiques aux préférences apparaissent également dans :

%SYSTEMROOT%\debug\usermode\gppref*.log

Ces fichiers de log verbeux (activés par la clé HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics\GPSvcDebugLevel) permettent de tracer précisément quel item XML a échoué et pourquoi.

Décodage du numéro de version GPO¶

Le versionNumber d'une GPO est un entier 32 bits composite. Sa structure :

• Bits 0-15 (poids faible) : version du volet machine
• Bits 16-31 (poids fort) : version du volet utilisateur

Chaque modification du volet machine incrémente les bits de poids faible. Chaque modification du volet utilisateur incrémente les bits de poids fort. Ainsi, un versionNumber de 65537 (hex 0x00010001) signifie :

• Version machine : 1
• Version utilisateur : 1

Un versionNumber de 131073 (hex 0x00020001) signifie :

• Version machine : 1
• Version utilisateur : 2

# Decode GPO version number into machine and user components
function Get-GPOVersionComponents {
    param(
        [Parameter(Mandatory)]
        [string]$GPOName
    )

    $gpo = Get-GPO -Name $GPOName
    $versionNumber = $gpo.Computer.DSVersion  # LDAP versionNumber

    # Read GPT.INI version for cross-check
    $domain = (Get-ADDomain).DNSRoot
    $sysvol = "\\$domain\SYSVOL\$domain\Policies\{$($gpo.Id)}\GPT.INI"
    $gptContent = Get-Content $sysvol -ErrorAction SilentlyContinue
    $gptVersion = ($gptContent | Where-Object { $_ -match '^Version=' }) -replace 'Version=',''

    # Decode version number
    $machineVersion = $versionNumber -band 0xFFFF
    $userVersion    = ($versionNumber -shr 16) -band 0xFFFF

    [PSCustomObject]@{
        GPOName       = $GPOName
        LDAPVersion   = $versionNumber
        GPTVersion    = [int]$gptVersion
        MachineVer    = $machineVersion
        UserVer       = $userVersion
        InSync        = ($versionNumber -eq [int]$gptVersion)
    }
}

Get-GPOVersionComponents -GPOName "Default Domain Policy"

GPOName               LDAPVersion GPTVersion MachineVer UserVer InSync
-------               ----------- ---------- ---------- ------- ------
Default Domain Policy 3           3          3          0       True

Central Store : création et maintenance¶

Création du Central Store¶

Le Central Store n'est pas créé automatiquement. Sa création est une action manuelle, à effectuer une seule fois par domaine :

# Create the Central Store for ADMX/ADML templates
$domain    = (Get-ADDomain).DNSRoot
$sysvol    = "\\$domain\SYSVOL\$domain\Policies"
$csPath    = "$sysvol\PolicyDefinitions"
$localADMX = "$env:SystemRoot\PolicyDefinitions"

# Create the PolicyDefinitions folder if it does not exist
if (-not (Test-Path $csPath)) {
    New-Item -ItemType Directory -Path $csPath | Out-Null
    Write-Host "Central Store created at: $csPath"
}

# Copy all ADMX files from local PolicyDefinitions
Get-ChildItem -Path $localADMX -Filter "*.admx" | ForEach-Object {
    Copy-Item -Path $_.FullName -Destination $csPath -Force
}

# Copy all ADML language folders
Get-ChildItem -Path $localADMX -Directory | ForEach-Object {
    $langDest = Join-Path $csPath $_.Name
    if (-not (Test-Path $langDest)) {
        New-Item -ItemType Directory -Path $langDest | Out-Null
    }
    Get-ChildItem -Path $_.FullName -Filter "*.adml" | ForEach-Object {
        Copy-Item -Path $_.FullName -Destination $langDest -Force
    }
}

Write-Host "ADMX/ADML files copied to Central Store."

Audit du Central Store vs version OS¶

Quand les ADMX du Central Store sont en retard par rapport aux ADMX embarqués dans la version Windows des postes clients, des paramètres récents n'apparaissent pas dans la GPMC. Vérifier la cohérence de version :

# Compare ADMX file count and modification dates between Central Store and local PolicyDefinitions
$domain   = (Get-ADDomain).DNSRoot
$csPath   = "\\$domain\SYSVOL\$domain\Policies\PolicyDefinitions"
$localDir = "$env:SystemRoot\PolicyDefinitions"

$csFiles    = Get-ChildItem -Path $csPath    -Filter "*.admx" -ErrorAction SilentlyContinue
$localFiles = Get-ChildItem -Path $localDir  -Filter "*.admx"

[PSCustomObject]@{
    CentralStoreCount = $csFiles.Count
    LocalCount        = $localFiles.Count
    CSLastModified    = ($csFiles | Sort-Object LastWriteTime -Descending | Select-Object -First 1).LastWriteTime
    LocalLastModified = ($localFiles | Sort-Object LastWriteTime -Descending | Select-Object -First 1).LastWriteTime
}

CentralStoreCount LocalCount CSLastModified        LocalLastModified
----------------- ---------- --------------        -----------------
             387        412  14/10/2022 09:44:00   08/03/2024 14:22:00

Un écart entre CentralStoreCount et LocalCount indique que le Central Store n'a pas été mis à jour depuis la dernière mise à niveau du système d'exploitation de la machine d'administration.

Référence de version par OS¶

Clés de registre de référence¶

Clés impliquées dans le traitement des stratégies de groupe, tous systèmes confondus :

Lecture du cache de traitement GPO depuis le registre¶

Le moteur gpsvc écrit l'état du dernier traitement dans le registre. Ces clés sont lisibles sans privilèges élevés sur la machine locale :

# Read Group Policy processing cache from registry
$gpStatePath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine"

if (Test-Path $gpStatePath) {
    # List applied GPOs with their version
    Get-ChildItem "$gpStatePath\GPO-List" -ErrorAction SilentlyContinue | ForEach-Object {
        $props = Get-ItemProperty $_.PSPath
        [PSCustomObject]@{
            DisplayName   = $props.DisplayName
            GUID          = $props.GUID
            Version       = $props.Version
            Link          = $props.Link
            Options       = $props.Options
        }
    } | Format-Table -AutoSize
}

DisplayName                    GUID                                   Version Link                                     Options
-----------                    ----                                   ------- ----                                     -------
Default Domain Policy          {31B2F340-016D-11D2-945F-00C04FB984F9}       3 LDAP://DC=corp,DC=contoso,DC=com              0
Security Baseline - Workstations {A4B2C1D3-...}                            17 LDAP://OU=Workstations,DC=corp,DC=contoso,DC=com  0

CSE enregistrés : lecture depuis GPExtensions¶

Les CSE disponibles sur un poste sont enregistrés sous HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. Chaque sous-clé est nommée par le GUID du CSE :

# List all registered Client-Side Extensions (CSEs)
$csePath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions"
Get-ChildItem $csePath | ForEach-Object {
    $props = Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        GUID          = $_.PSChildName
        Name          = $props.'(default)'
        DLLName       = $props.DllName
        ProcessGPOs   = $props.ProcessGroupPolicy
        NoMachinePolicy = $props.NoMachinePolicy
        NoUserPolicy    = $props.NoUserPolicy
    }
} | Where-Object { $_.Name } | Sort-Object Name | Format-Table -AutoSize

Les CSE clés présents sur tout poste Windows Vista+ :

Références croisées¶