GPO et MDM : convergence et coexistence¶

Architecture MDM : CSP, OMA-URI et PolicyManager¶

Les Configuration Service Providers¶

Un Configuration Service Provider (CSP) est un composant Windows qui expose une interface de configuration standardisée au moteur MDM. Chaque CSP gère un domaine fonctionnel : politiques de sécurité, certificats, Wi-Fi, pare-feu, etc.

Le CSP le plus important pour la convergence GPO/MDM est Policy CSP. Il expose la quasi-totalité des paramètres de stratégie de groupe sous forme d'URI adressables.

L'adressage OMA-URI suit une structure stricte :

./Device/Vendor/MSFT/Policy/Config/<Area>/<PolicyName>
./User/Vendor/MSFT/Policy/Config/<Area>/<PolicyName>

Le préfixe ./Device/ cible la configuration machine. Le préfixe ./User/ cible la configuration utilisateur, analogue à la hive HKCU des GPO.

La ruche PolicyManager¶

Quand le client MDM (service dmwappushservice + DeviceEnrollmentService) reçoit une politique, il écrit le résultat dans la ruche HKLM\SOFTWARE\Microsoft\PolicyManager\.

Cette ruche contient quatre sous-clés structurantes :

La sous-clé current\ est recalculée à chaque synchronisation MDM. C'est elle qui représente l'état appliqué.

# Read all effective MDM policy values from PolicyManager\current
# Requires elevation

$basePath = 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device'

Get-ChildItem -Path $basePath -Recurse -ErrorAction SilentlyContinue |
    Get-ItemProperty -ErrorAction SilentlyContinue |
    Select-Object PSChildName, * -ExcludeProperty PS* |
    Where-Object { $_.PSObject.Properties.Count -gt 1 } |
    Format-Table -AutoSize

PSChildName                     value  providerName
-----------                     -----  ------------
AllowCamera                     0      MDM_DeviceLock
DisableAntiSpyware              0      MDM_Security
AllowIndexingEncryptedStoresOrI 0      MDM_Search

Règle de précédence MDM vs GPO¶

La précédence dépend du chemin de registre lu par le composant Windows concerné.

Mapping GPO → CSP : les ADMX-backed policies¶

Le pont entre les deux mondes¶

Une ADMX-backed policy est une politique Intune qui configure un paramètre ADMX via OMA-URI plutôt que via la GPMC. Du côté Windows, le mécanisme de réception est identique à une GPO : le CSP ingeste la valeur et écrit dans la clé de registre cible identique à celle qu'aurait écrite la GPO.

Le chemin OMA-URI d'une ADMX-backed policy suit le format :

./Device/Vendor/MSFT/Policy/Config/<ADMX_AreaName>~Policy~<CategoryPath>/<PolicyName>

Exemple pour le paramètre Turn off Windows Defender (zone WindowsDefender) :

./Device/Vendor/MSFT/Policy/Config/WindowsDefender~Policy~WindowsDefender/DisableAntiSpyware

Identifier le mapping d'un paramètre GPO¶

Pour trouver l'équivalent OMA-URI d'une GPO existante, trois sources sont exploitables :

1. La documentation MDM de Microsoft — chaque paramètre Policy CSP est documenté avec son mapping ADMX sur docs.microsoft.com
2. Le fichier ADMX lui-même — l'attribut key du nœud <policy> donne la clé de registre cible ; si le même chemin existe dans la doc Policy CSP, le mapping est confirmé
3. L'Intune Settings Catalog — la console Intune expose les ADMX-backed policies sous Devices → Configuration → Settings Catalog avec un champ de recherche textuel

# Extract registry key and value name from an ADMX file for a named policy
# Usage: point $admxPath to a local ADMX file, set $policyName to search

param(
    [string]$admxPath = 'C:\Windows\PolicyDefinitions\WindowsDefender.admx',
    [string]$policyName = 'DisableAntiSpyware'
)

[xml]$admx = Get-Content -Path $admxPath -Encoding UTF8

$policy = $admx.policyDefinitions.policies.policy |
    Where-Object { $_.name -eq $policyName }

if ($policy) {
    [PSCustomObject]@{
        PolicyName   = $policy.name
        RegistryKey  = $policy.key
        RegistryValue = $policy.valueName
        Class        = $policy.class   # Machine or User
        SupportedOn  = $policy.supportedOn.ref
    }
} else {
    Write-Warning "Policy '$policyName' not found in $admxPath"
}

PolicyName    : DisableAntiSpyware
RegistryKey   : SOFTWARE\Policies\Microsoft\Windows Defender
RegistryValue : DisableAntiSpyware
Class         : Machine
SupportedOn   : SUPPORTED_WindowsVista

Exemple concret : règle de pare-feu¶

Le paramètre Windows Firewall — Domain Profile — Firewall State illustre parfaitement le double chemin.

Group Policy Analytics¶

Group Policy Analytics dans Intune importe des rapports GPO au format XML et indique quels paramètres disposent d'un équivalent MDM. Il sert à préparer une migration, pas à convertir automatiquement toute l'architecture GPO.

Flux recommandé :

1. Exporter le rapport XML depuis gpmc.msc ou Get-GPOReport.
2. Importer le fichier dans Devices → Manage devices → Group Policy analytics.
3. Lire le pourcentage de support MDM, les paramètres inconnus, obsolètes ou non supportés.
4. Créer une politique Settings Catalog uniquement pour les paramètres supportés et validés.
5. Piloter sur un groupe restreint avant de délier la GPO historique.

Get-GPOReport -Name "SEC-WKS-Defender-Baseline" `
    -ReportType Xml `
    -Path "C:\Temp\SEC-WKS-Defender-Baseline.xml"

Zones sans recouvrement : GPO-only et MDM-only¶

Ce que GPO peut faire et MDM ne peut pas¶

Certains domaines restent exclusifs aux GPO en 2026. La raison principale est architecturale : MDM gère des machines, pas des services d'annuaire.

Les paramètres GPO sans équivalent CSP documenté incluent :

Ce que MDM peut faire et GPO ne peut pas¶

Les fonctionnalités MDM-only sont liées à l'identité cloud et au cycle de vie de l'appareil :

Détecter les gaps programmatiquement¶

# Identify GPO registry settings that have no known PolicyManager equivalent
# Compares SOFTWARE\Policies\ values with PolicyManager\current\ keys

# Step 1: collect all values written by GPO under Software\Policies
$gpoPolicies = Get-ChildItem -Path 'HKLM:\SOFTWARE\Policies\Microsoft' `
    -Recurse -ErrorAction SilentlyContinue |
    Get-ItemProperty -ErrorAction SilentlyContinue

# Step 2: collect all area names present in PolicyManager\current\device
$mdmAreas = Get-ChildItem -Path `
    'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device' `
    -ErrorAction SilentlyContinue |
    Select-Object -ExpandProperty PSChildName

# Step 3: flag GPO subkeys with no PolicyManager counterpart
$results = foreach ($policy in $gpoPolicies) {
    $keyFragment = ($policy.PSPath -split 'Microsoft\\')[1]
    $hasMdmEquivalent = $mdmAreas | Where-Object {
        $keyFragment -like "*$_*"
    }
    if (-not $hasMdmEquivalent) {
        [PSCustomObject]@{
            RegistryPath = $policy.PSChildName
            GPOSubKey    = $keyFragment
            MDMEquivalent = 'NOT FOUND'
        }
    }
}

$results | Format-Table -AutoSize

Stratégies de coexistence¶

Les trois architectures¶

Il n'existe pas de stratégie universelle. Le choix dépend de la maturité cloud, du parc existant et des délais de migration.

Stratégie 1 — MDM First, GPO by Exception

MDM gère l'intégralité de la configuration. Les GPO ne subsistent que pour les paramètres sans équivalent CSP documenté (DCs, Kerberos, Drive Maps legacy).

Prérequis : Azure AD Join ou Hybrid Join activé, Intune déployé, parc Windows 10 1903+ minimum.

Risque principal : Les GPO résiduelles sont difficiles à gouverner sur le long terme — absence d'outillage de reporting unifié entre GPMC et Intune.

Stratégie 2 — GPO par défaut, MDM pour le cloud-only

L'AD on-prem reste le canal primaire. MDM est ajouté uniquement pour les fonctionnalités requérant Azure AD (Autopilot, WHfB Cloud Trust, Conditional Access).

Prérequis : Hybrid Join fonctionnel, synchronisation AAD Connect stable.

Risque principal : Conflits silencieux sur les paramètres qui existent dans les deux couches. Un audit de superposition est obligatoire.

Stratégie 3 — Configuration gelée, migration progressive

La configuration GPO existante est maintenue sans évolution. Les nouveaux paramètres sont systématiquement posés en MDM. L'objectif est de migrer les GPO existantes vers MDM sur 18-36 mois en utilisant le Settings Catalog comme guide de migration.

Prérequis : Gel de production accepté, roadmap de migration documentée.

Risque principal : Dérive progressive vers la stratégie 1 sans gouvernance claire.

Tableau comparatif des stratégies¶

Decision tree : quelle stratégie choisir¶

flowchart TD
    A[Évaluation du parc] --> B{Majorité du parc\nen Azure AD Join ?}
    B -- Oui --> C{Intune déployé\net opérationnel ?}
    B -- Non --> D{Hybrid Join\nactivé et stable ?}

    C -- Oui --> E[Stratégie 1\nMDM First]
    C -- Non --> F[Déployer Intune d'abord\npuis réévaluer]

    D -- Oui --> G{Nouveaux appareils\nvia Autopilot ?}
    D -- Non --> H[Stratégie 2\nGPO par défaut\nMDM limité au cloud-only]

    G -- Oui --> I[Stratégie 3\nMigration progressive\nGPO gelées + MDM pour nouveau]
    G -- Non --> H

    E --> J{Paramètres GPO-only\nidentifiés ?}
    J -- Oui --> K[Maintenir GPO résiduelle\nauditée et bornée]
    J -- Non --> L[GPO complètement\néliminables à terme]

Windows Autopilot et les GPO¶

Timing d'application des GPO¶

Windows Autopilot et les GPO répondent à des cycles de vie différents. Comprendre leur séquençage évite les erreurs de déploiement.

Azure AD Join pur (Autopilot standard)

Les GPO ne s'appliquent jamais. L'appareil n'est pas membre d'un domaine AD DS. Toute la configuration passe par MDM. L'ESP (Enrollment Status Page) bloque le bureau jusqu'à la fin de l'application des politiques Intune.

Hybrid Azure AD Join (Autopilot Hybrid)

Les GPO s'appliquent après la jonction au domaine. Cette jonction nécessite une première connexion réseau au DC, ce qui intervient après le redémarrage post-OOBE.

La séquence complète est :

OOBE → Autopilot Profile download → AAD Join → MDM Enrollment
→ ESP phase Device Setup (MDM policies)
→ Reboot → Domain Join (Hybrid) → First foreground GPO processing
→ ESP phase Account Setup → User logon

Ce qui s'applique à chaque phase¶

ADMX-backed via Intune sur appareils Autopilot¶

Sur les appareils Autopilot AAD Join purs, il est possible de pousser des paramètres ADMX via le Settings Catalog Intune. Le mécanisme est identique aux ADMX-backed policies décrites plus haut.

# Check which MDM policies are active on an Autopilot-enrolled device
# Run on the enrolled device — no domain membership required

$mdmDiagPath = "$env:TEMP\MDMDiag_$(Get-Date -Format 'yyyyMMdd_HHmmss')"
New-Item -ItemType Directory -Path $mdmDiagPath -Force | Out-Null

# Generate MDM diagnostic report
MdmDiagnosticsTool.exe -area DeviceEnrollment+DeviceProvisioning -zip "$mdmDiagPath\diag.zip"

# Read PolicyManager current values directly
$policyPath = 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device'
$policies = Get-ChildItem -Path $policyPath -Recurse -ErrorAction SilentlyContinue |
    Get-ItemProperty -ErrorAction SilentlyContinue |
    Select-Object PSChildName, * -ExcludeProperty PS*

Write-Host "Active MDM policy areas on this device:" -ForegroundColor Cyan
$policies | Where-Object { $_.PSObject.Properties.Count -gt 2 } |
    Group-Object -Property PSChildName |
    Select-Object Name, Count |
    Sort-Object Count -Descending |
    Format-Table -AutoSize

La pile de configuration complète¶

Le diagramme suivant représente l'intégralité de la pile de configuration Windows, de la couche matérielle aux applications, avec les annotations de précédence à chaque niveau.

flowchart TD
    subgraph HW["Couche 0 — Matériel"]
        BIOS["BIOS / UEFI\nSecure Boot, TPM, BIOS password\nPrécédence : absolue — software ne peut pas contourner"]
    end

    subgraph PROV["Couche 1 — Provisionnement"]
        AP["Windows Autopilot\nProfil de déploiement, ESP, OOBE\nPrécédence : configure le tenant MDM avant toute session"]
        WCD["Windows Configuration Designer\nProvisioning Packages (.ppkg)\nPrécédence : appliqué avant MDM enrollment si on-device"]
    end

    subgraph MDM["Couche 2 — MDM (Configuration Service Providers)"]
        CSP["Policy CSP / autres CSPs\nPolicyManager\\current\\\nPrécédence : gagne sur GPO pour composants modernes"]
        COMP["Compliance Policy\nEvaluation de conformité → Conditional Access\nBloque l'accès si non conforme, indépendamment des GPO"]
    end

    subgraph GPO["Couche 3 — Group Policy (GPO)"]
        MACHINE["Computer Configuration\nSOFTWARE\\Policies\\\nPrécédence : gagne sur GPP et Local Policy"]
        USER["User Configuration\nHKCU\\Software\\Policies\\\nPrécédence : soumise à LSDOU, loopback"]
        GPP["Group Policy Preferences\nPrécédence : la plus basse — peut être remplacée par l'utilisateur"]
    end

    subgraph LOCAL["Couche 4 — Configuration locale"]
        LGPO["Local GPO (MLGPO)\nPrécédence : la plus basse des GPO, dominée par AD GPO"]
        REG["Paramètres utilisateur\nHKCU sans Policies\\\nPrécédence : dominée par GPO et MDM"]
    end

    subgraph APP["Couche 5 — Applications"]
        APPCONF["Configuration applicative\nHKCU\\Software\\<vendor>\\\nPrécédence : aucune sur les couches système"]
    end

    BIOS --> AP
    AP --> WCD
    WCD --> CSP
    CSP --> COMP
    COMP --> MACHINE
    MACHINE --> USER
    USER --> GPP
    GPP --> LGPO
    LGPO --> REG
    REG --> APPCONF

    style HW fill:#1a1a2e,color:#e0e0e0,stroke:#4a4a6a
    style PROV fill:#16213e,color:#e0e0e0,stroke:#4a4a6a
    style MDM fill:#0f3460,color:#e0e0e0,stroke:#4a6a9a
    style GPO fill:#1a3a5c,color:#e0e0e0,stroke:#4a6a9a
    style LOCAL fill:#162447,color:#e0e0e0,stroke:#4a6a9a
    style APP fill:#1f1f1f,color:#c0c0c0,stroke:#4a4a4a

Annotations de précédence¶

BIOS/UEFI est la seule couche incontournable. Un Secure Boot activé et un TPM 2.0 requis imposent des contraintes que ni MDM ni GPO ne peuvent modifier depuis Windows.

Autopilot configure l'identité et l'enrollment avant toute politique. L'ESP peut bloquer l'accès au bureau jusqu'à ce que les politiques MDM soient appliquées.

Policy CSP domine sur les composants modernes. La ruche PolicyManager\current\ est la source de vérité pour Defender, Edge Chromium, les restrictions AAD.

GPO Machine domine sur tous les paramètres legacy et les composants qui lisent SOFTWARE\Policies\. La jonction domaine est requise.

GPP et Local GPO sont les couches les plus basses et les plus facilement écrasées. Elles ne doivent pas porter de paramètres de sécurité critiques.

Vision 2026+ : convergence réaliste¶

La feuille de route Microsoft¶

Microsoft n'a pas annoncé la fin des GPO. Le signal le plus clair de la feuille de route est l'Intune Settings Catalog : une interface qui expose des milliers de paramètres issus à la fois de Policy CSP et d'ADMX, dans une surface unifiée, sans nécessiter la GPMC.

En 2026, trois trajectoires sont confirmées :

1. Le Settings Catalog comme interface de convergence

Le Settings Catalog Intune dépasse désormais 5 000 paramètres configurables. Microsoft y intègre systématiquement les nouveaux paramètres Windows avant de les exposer dans les ADMX. Pour les appareils AAD Join, c'est déjà la surface primaire recommandée.

2. La documentation des gaps GPO/CSP

Microsoft publie et maintient une liste officielle des paramètres Policy CSP avec leur équivalent ADMX. Cette liste s'allonge à chaque version de Windows. Le nombre de paramètres GPO sans équivalent CSP diminue — mais ne disparaît pas.

3. La pérennité des GPO pour les environnements AD DS

Les GPO ne sont pas dépréciées. Les DCs, les politiques Kerberos, les PSO, et la configuration du domaine AD resteront gérés par GPO pour la durée prévisible. Microsoft ne propose aucun mécanisme MDM pour configurer un contrôleur de domaine.

Ce que GPO fera toujours mieux que MDM¶

Ce que MDM fera toujours mieux que GPO¶

L'Intune Settings Catalog comme convergence pratique¶

Pour un architecte en 2026, l'approche pragmatique est la suivante :

1. Paramètre nouveau → chercher d'abord dans le Settings Catalog Intune
2. Paramètre existant en GPO → vérifier si le Settings Catalog expose l'équivalent avant de migrer
3. Paramètre GPO sans équivalent CSP → maintenir en GPO, documenter dans le registre de la dette technique
4. Paramètre AD DS / DC → GPO uniquement, définitivement

# Compare active GPO registry settings with known PolicyManager areas
# to identify candidates for Settings Catalog migration

# Enumerate all Computer Configuration GPO registry values
$gpoKeys = Get-ChildItem -Path 'HKLM:\SOFTWARE\Policies' -Recurse `
    -ErrorAction SilentlyContinue

# Enumerate PolicyManager areas (MDM-managed settings)
$mdmKeys = Get-ChildItem -Path `
    'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device' `
    -ErrorAction SilentlyContinue |
    Select-Object -ExpandProperty PSChildName

$report = foreach ($key in $gpoKeys) {
    $relPath = $key.PSPath -replace '.*SOFTWARE\\Policies\\', ''
    $mdmCoverage = if ($mdmKeys | Where-Object { $relPath -like "*$_*" }) {
        'MDM equivalent found'
    } else {
        'GPO-only — no MDM equivalent detected'
    }
    [PSCustomObject]@{
        GPOPath      = $relPath
        MDMCoverage  = $mdmCoverage
    }
}

$report | Sort-Object MDMCoverage | Format-Table -AutoSize -Wrap

GPOPath                                          MDMCoverage
-------                                          -----------
Microsoft\Windows Defender\DisableAntiSpyware    MDM equivalent found
Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate  MDM equivalent found
Microsoft\Windows NT\CurrentVersion\Winlogon\... GPO-only — no MDM equivalent detected
Microsoft\Windows\Kerberos\...                   GPO-only — no MDM equivalent detected

Références croisées¶

Ce chapitre est le dernier de la Bible GPO. Les sujets traités s'articulent avec les chapitres suivants du livre GPO pour les Admins :

• Chapitre 18 — Azure AD Hybrid Join — configuration de la jonction hybride, prérequis AAD Connect, coexistence des identités
• Chapitre 19 — Migration vers Intune — méthodologie de migration GPO → Settings Catalog, outils d'analyse, déploiement progressif
• Chapitre 25 — Zero Trust et GPO — architecture Zero Trust, rôle des GPO dans le modèle de confiance moderne, Conditional Access