Migration GPO vers Intune¶
Ce que vous allez apprendre
- Utiliser Group Policy Analytics dans le portail Intune pour analyser automatiquement vos GPO existantes et obtenir un rapport de couverture CSP avec pourcentage de prise en charge
- Exporter toutes vos GPO en XML via PowerShell pour une analyse en lot, identifier les paramètres sans équivalent MDM et classer les gaps par catégorie
- Suivre un workflow en 7 étapes de migration par workload : de l'analyse initiale jusqu'à la suppression sécurisée de la GPO, avec une fenêtre d'observation obligatoire de deux semaines
- Gérer la coexistence GPO/Intune sur les machines Hybrid Join et comprendre le mécanisme de workload switching pour éviter les conflits silencieux
- Importer des ADMX tierces (Chrome, Firefox, Office) dans Intune et recréer les profils équivalents à vos GPO existantes
Si vous ne retenez qu'une chose
Ne supprimez jamais une GPO le jour même où vous activez la politique Intune correspondante. Un appareil hors ligne peut ne pas recevoir la politique MDM pendant plusieurs heures. La fenêtre de conformité vide entre la suppression de la GPO et l'application réelle de la politique Intune est le piège numéro un des migrations. Deux semaines d'observation minimum, point non négociable.
Contexte de production¶
La migration des GPO vers Intune n'est pas un événement ponctuel. C'est un processus progressif, workload par workload, sur plusieurs mois.
La réalité terrain : la majorité des organisations qui commencent cette migration ont entre 200 et 800 GPO actives, dont 30 à 40 % ont été créées pour résoudre un problème précis et jamais documentées. Avant de migrer quoi que ce soit, vous devez savoir ce que vous avez.
Ce chapitre part du principe que vos machines sont en Hybrid Join (jointes au domaine AD et enregistrées dans Azure AD) et que vous avez un tenant Intune actif. Le co-management MECM est traité dans le chapitre suivant.
En résumé
- La migration des GPO vers Intune n'est pas un événement ponctuel.
- C'est un processus progressif, workload par workload, sur plusieurs mois.
- Avant de migrer quoi que ce soit, vous devez savoir ce que vous avez.
- Le contexte de production fixe les contraintes réelles de réseau, de portée et d’exploitation qui gouvernent tout le chapitre.
- Retenez les hypothèses opérationnelles avant de choisir un modèle de liaison ou de déploiement.
Group Policy Analytics : analyser avant de migrer¶
Ce qu'est Group Policy Analytics¶
Group Policy Analytics (GPA) est un outil intégré au portail Intune (Devices > Group Policy Analytics). Il prend en entrée un fichier XML d'export de GPO et produit un rapport indiquant, pour chaque paramètre, s'il est :
- Supported : un équivalent CSP (Configuration Service Provider) existe dans Intune
- Not supported : aucun équivalent MDM connu
- Deprecated : le paramètre GPO existe mais Microsoft recommande de ne plus l'utiliser
Le rapport affiche également un pourcentage de couverture global pour chaque GPO importée.
Exporter une GPO en XML¶
L'export s'effectue avec Get-GPOReport, cmdlet native du module RSAT GroupPolicy.
# Export a single GPO to XML for Group Policy Analytics import
Import-Module GroupPolicy
$gpoName = "Baseline-Securite-Postes"
$outputPath = "C:\GPO_Export\$gpoName.xml"
Get-GPOReport -Name $gpoName -ReportType XML -Path $outputPath
Write-Host "Exported: $outputPath"
Exporter toutes les GPO en lot¶
En production, vous n'allez pas exporter 200 GPO à la main. Ce script parcourt le domaine et exporte chaque GPO dans un dossier dédié.
# Batch export all GPOs to XML for Group Policy Analytics bulk import
Import-Module GroupPolicy
$exportRoot = "C:\GPO_Export\$(Get-Date -Format 'yyyy-MM-dd')"
New-Item -ItemType Directory -Path $exportRoot -Force | Out-Null
$allGPOs = Get-GPO -All
$total = $allGPOs.Count
$current = 0
foreach ($gpo in $allGPOs) {
$current++
# Sanitize GPO display name for use as filename
$safeName = $gpo.DisplayName -replace '[\\/:*?"<>|]', '_'
$outputFile = Join-Path $exportRoot "$safeName.xml"
try {
Get-GPOReport -Guid $gpo.Id -ReportType XML -Path $outputFile
Write-Host "[$current/$total] OK : $($gpo.DisplayName)"
}
catch {
Write-Warning "[$current/$total] FAILED : $($gpo.DisplayName) — $($_.Exception.Message)"
}
}
Write-Host "`nExport complete. Files saved to: $exportRoot"
[1/247] OK : Baseline-Securite-Postes
[2/247] OK : Config-Chrome-Entreprise
[3/247] OK : Redirect-Dossiers-Utilisateurs
...
[247/247] OK : Legacy-IE-Compat-Intranet
Export complete. Files saved to: C:\GPO_Export\2025-06-12
Importer dans Group Policy Analytics¶
Dans le portail Intune (Devices > Group Policy Analytics), cliquez sur Import et sélectionnez les fichiers XML exportés. L'analyse prend quelques secondes par fichier.
Une fois l'analyse terminée, chaque GPO affiche :
| Colonne rapport GPA | Signification |
|---|---|
| MDM Support | Pourcentage de paramètres avec équivalent CSP |
| Supported count | Nombre de paramètres migrables |
| Not supported count | Nombre de paramètres sans équivalent MDM |
| Deprecated count | Paramètres GPO obsolètes |
| Unknown count | Paramètres que GPA ne reconnaît pas (modèles ADMX tiers non analysés) |
Une GPO avec 85 % de couverture ou plus est une bonne candidate pour une migration directe. En dessous de 60 %, anticipez des workarounds.
À surveiller — Les paramètres 'Unknown'
Les paramètres classés Unknown dans GPA sont souvent des ADMX tierces (Chrome, Firefox, applications métier). GPA ne les analyse pas automatiquement. Ce n'est pas qu'ils n'ont pas d'équivalent Intune — c'est que GPA ne sait pas. Analysez-les manuellement avant de conclure à un gap réel.
En résumé
- GPA s'alimente de fichiers XML produits par
Get-GPOReport -ReportType XML - Le rapport classe chaque paramètre : Supported / Not supported / Deprecated / Unknown
- Un pourcentage de couverture >= 85 % = GPO candidate à migration directe
- Les ADMX tierces génèrent des "Unknown" — ce n'est pas forcément un gap MDM
Processus de migration en 7 étapes¶
Vue d'ensemble du workflow¶
La migration d'une GPO vers Intune ne se fait pas en un clic. Chaque workload doit passer par sept étapes distinctes, avec validation formelle avant de passer à la suivante.
| Étape | Action | Responsable | Outil | Validation |
|---|---|---|---|---|
| 1. Analyse | Importer la GPO dans GPA, identifier les paramètres sans CSP | Admin IT | Portail Intune — GPA | Rapport GPA exporté |
| 2. Priorisation | Classer les paramètres : sécurité d'abord, confort ensuite | Architecte / Admin | Excel / CSV | Backlog priorisé validé |
| 3. Création du profil Intune | Créer le profil de configuration Intune équivalent | Admin IT | Portail Intune | Profil créé, assigné au groupe test |
| 4. Test pilote | Déployer sur un groupe test (10–20 machines), observer pendant 48 h | Admin IT | Portail Intune + Get-MDMDeviceDetail | 0 erreur dans le rapport de conformité |
| 5. Désactivation de la GPO | Désactiver (pas supprimer) la GPO sur le groupe pilote | Admin AD | GPMC | gpresult /H ne montre plus la GPO |
| 6. Observation | Surveiller les tickets, les événements et la conformité pendant 2 semaines | Admin IT + Support | Intune Compliance + helpdesk | Aucun incident lié au paramètre |
| 7. Suppression de la GPO | Supprimer la GPO après la fenêtre d'observation | Admin AD | GPMC | GPO absente de Get-GPO -All |
Inventaire et cartographie des GPO avant migration Intune¶
Avant de créer un seul profil Intune, exportez le rapport GPA en CSV depuis le portail.
# Parse exported GPA CSV to identify not-supported settings by GPO
$gpaCsvPath = "C:\GPO_Export\GPA_Report_Export.csv"
$report = Import-Csv -Path $gpaCsvPath
# Group by GPO name and count supported vs not-supported
$summary = $report | Group-Object -Property 'GPO Name' | ForEach-Object {
$settings = $_.Group
$supported = ($settings | Where-Object { $_.MDMSupport -eq 'Supported' }).Count
$notSupported = ($settings | Where-Object { $_.MDMSupport -eq 'Not supported' }).Count
$deprecated = ($settings | Where-Object { $_.MDMSupport -eq 'Deprecated' }).Count
$total = $settings.Count
$coveragePct = if ($total -gt 0) { [math]::Round(($supported / $total) * 100, 1) } else { 0 }
[PSCustomObject]@{
GPOName = $_.Name
Total = $total
Supported = $supported
NotSupported = $notSupported
Deprecated = $deprecated
Coverage_Pct = $coveragePct
}
}
$summary | Sort-Object Coverage_Pct -Descending | Format-Table -AutoSize
Étape 4 — Valider l'application MDM sur les machines pilotes¶
# Verify that an MDM policy has been applied on a list of pilot machines
# Requires WinRM access and the MDM Diagnostics module
$pilotMachines = @("PC-PILOT-001", "PC-PILOT-002", "PC-PILOT-003")
# CSP path to check — adapt to the policy being migrated
$cspPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
$valueName = "WUServer"
foreach ($computer in $pilotMachines) {
try {
$result = Invoke-Command -ComputerName $computer -ScriptBlock {
param($path, $val)
$reg = Get-ItemProperty -Path $path -Name $val -ErrorAction SilentlyContinue
[PSCustomObject]@{
Computer = $env:COMPUTERNAME
ValueFound = ($null -ne $reg)
Value = $reg.$val
# Check if value was set by MDM (written under SOFTWARE\Policies by MDM bridge)
Source = if (Test-Path "HKLM:\SOFTWARE\Microsoft\Enrollments") { "MDM-enrolled" } else { "Not enrolled" }
}
} -ArgumentList $cspPath, $valueName
$result
}
catch {
Write-Warning "Cannot reach $computer : $($_.Exception.Message)"
}
}
Computer ValueFound Value Source
-------- ---------- ----- ------
PC-PILOT-001 True https://wsus.corp.local:8530 MDM-enrolled
PC-PILOT-002 True https://wsus.corp.local:8530 MDM-enrolled
PC-PILOT-003 True https://wsus.corp.local:8530 MDM-enrolled
Production — Ne désactivez la GPO qu'après validation des 3 machines
L'étape 5 (désactivation de la GPO) ne doit intervenir que si 100 % des machines pilotes affichent ValueFound = True via MDM. Une machine qui n'a pas encore reçu la politique Intune est en état non conforme dès la désactivation de la GPO. Sur un réseau avec des appareils nomades, ce délai peut atteindre 8 heures.
En résumé
- 7 étapes séquentielles : Analytics → Priorisation → Profil → Pilote → Désactivation GPO → Observation → Suppression
- La sécurité passe en premier dans la priorisation
- La fenêtre d'observation de 2 semaines n'est pas optionnelle
Get-MDMDeviceDetailet l'inspection du registre valident l'application réelle de la politique MDM
Paramètres sans équivalent MDM¶
Les catégories à risque¶
Certains paramètres GPO n'ont tout simplement pas d'équivalent CSP dans Intune. Ce n'est pas un oubli de Microsoft — c'est souvent parce que la fonctionnalité sous-jacente n'existe pas dans le monde Modern Management.
Les catégories les plus fréquentes en production :
| Catégorie GPO | Pourquoi pas de CSP | Workaround recommandé |
|---|---|---|
| Scripts Startup/Shutdown complexes | Les scripts MDM sont exécutés en contexte différent (pas SYSTEM au boot) | Intune Remediations (PowerShell) en contexte SYSTEM |
| Folder Redirection (chemins UNC complexes) | Known Folders Move dans Intune ne supporte pas les conditions avancées | Maintenir la GPO pour ce paramètre spécifique |
| Restrictions Internet Explorer avancées | IE n'existe plus en tant que browser manageable par CSP | Supprimer si IE est désinstallé ; migrer vers Edge |
| Logon scripts utilisateur complexes (>5 min) | Timeout MDM plus court que les scripts GPO | Intune Custom Scripts (attention aux limites de durée) |
| Préférences GPO — Raccourcis bureau par utilisateur | GPP User Preferences n'ont pas d'équivalent MDM direct | Intune Win32 App ou script de remédiation |
| Préférences GPO — Sources de données ODBC | Très spécifique à l'infrastructure legacy | Script PowerShell déployé via Remediations |
| Mappage lecteurs réseau conditionnel | GPP Drive Maps avec filtrage WMI | Logon script via Intune Custom Scripts |
| Stratégies locales avancées (User Rights) | Partiellement supporté selon la version d'Intune | CSP Policy/Config/UserRights — vérifier la liste |
| AppLocker (règles héritées complexes) | WDAC (Windows Defender Application Control) remplace AppLocker | Migration WDAC via Intune ou maintien GPO transitoire |
| Configuration imprimantes via GPP (Port 9100 custom) | Printer CSP limité aux imprimantes partagées standard | Intune Win32 App avec pilote + script port |
Stratégies de workaround détaillées¶
Option A — Intune Remediations
Les Remediations (anciennement Proactive Remediations) permettent d'exécuter un script PowerShell de détection et un script de correction. C'est le remplacement naturel des scripts Startup/Shutdown.
# Detection script: check if the registry value expected from the legacy startup script is present
$expectedKey = "HKLM:\SOFTWARE\Corp\StartupConfig"
$expectedValue = "Configured"
$expectedData = "v2.1"
try {
$actual = Get-ItemPropertyValue -Path $expectedKey -Name $expectedValue -ErrorAction Stop
if ($actual -eq $expectedData) {
# Compliant — no remediation needed
exit 0
}
else {
# Value exists but wrong data
exit 1
}
}
catch {
# Key or value missing
exit 1
}
# Remediation script: apply what the legacy GPO startup script used to do
$targetKey = "HKLM:\SOFTWARE\Corp\StartupConfig"
$targetValue = "Configured"
$targetData = "v2.1"
try {
if (-not (Test-Path $targetKey)) {
New-Item -Path $targetKey -Force | Out-Null
}
Set-ItemProperty -Path $targetKey -Name $targetValue -Value $targetData -Type String
Write-Host "Remediation applied successfully."
exit 0
}
catch {
Write-Error "Remediation failed: $($_.Exception.Message)"
exit 1
}
Option B — Maintenir la GPO pour les paramètres orphelins
La migration n'est pas tout-ou-rien. Il est parfaitement valide de migrer 95 % d'une GPO vers Intune et de conserver une GPO légère pour les 5 % sans équivalent.
Créez une GPO nommée LEGACY-NoMDM-[nom-original] qui ne contient que les paramètres sans CSP. Cette GPO reste sur les machines Hybrid Join. Elle n'interfère pas avec Intune tant que les paramètres ne se chevauchent pas.
À surveiller — Conflits entre GPO résiduelle et profil Intune
Si un paramètre est à la fois dans la GPO résiduelle et dans le profil Intune, le comportement dépend du paramètre. Pour les valeurs de registre sous SOFTWARE\Policies, la dernière écriture gagne. GPO écrit lors du prochain cycle (90 min). MDM écrit lors de la prochaine synchronisation (8 h max). Résultat : flipping de configuration. Éliminez tout chevauchement avant la mise en production.
En résumé
- Les scripts Startup/Shutdown complexes migrent vers les Intune Remediations
- Folder Redirection avancé, ODBC, et lecteurs réseau conditionnels restent sur GPO résiduelle
- AppLocker legacy migre vers WDAC (projet distinct, pas une migration directe)
- Une GPO
LEGACY-NoMDM-*dédiée aux orphelins est préférable à une GPO mixte
Hybrid Join pendant la migration¶
Pourquoi les GPO continuent de s'appliquer¶
Sur une machine Hybrid Joined, gpsvc (Group Policy Client Service) est toujours actif. La machine est membre du domaine AD — elle applique les GPO normalement, toutes les 90 minutes, exactement comme avant l'enrôlement Intune.
L'enrôlement Intune ajoute un canal de gestion supplémentaire. Il ne remplace pas les GPO automatiquement. Les deux canaux coexistent.
Le risque réel n'est pas le conflit évident — c'est le conflit silencieux. Quand GPO et MDM définissent la même valeur de registre à des valeurs différentes, le comportement observé dépend de l'ordre d'écriture et du type de paramètre.
Le workload switching¶
Dans le portail Intune, sous Tenant administration > Cloud attach > Co-management, vous pouvez basculer des workloads de MECM/GPO vers Intune, un par un.
Un workload basculé vers Intune signifie que c'est Intune qui a l'autorité pour ce domaine fonctionnel. La GPO correspondante doit être désactivée sur les machines concernées, sinon les deux canaux écrivent en parallèle.
| Workload | Géré par défaut | Après basculement vers Intune | Ce que "basculer" implique |
|---|---|---|---|
| Compliance policies | MECM / GPO | Intune | Les règles de conformité (BitLocker, version OS) viennent d'Intune |
| Device configuration | GPO | Intune | Les profils de configuration remplacent les GPO de config poste |
| Endpoint Protection | GPO / MECM Endpoint | Intune + Defender | Les politiques Defender, ASR, Firewall viennent d'Intune |
| Resource access policies | GPO | Intune | Certificats, Wi-Fi, VPN — profils Intune actifs |
| Client apps | MECM Software Center | Intune Company Portal | Déploiements applicatifs pilotés par Intune |
| Office Click-to-Run apps | GPO ou MECM | Intune (ODT via Intune) | Configuration M365 Apps gérée par Intune |
| Windows Update policies | GPO / WSUS | Windows Update for Business via Intune | Les anneaux WUfB remplacent les GPO WSUS |
Production — Ne basculez jamais deux workloads majeurs le même jour
Basculer Device Configuration et Endpoint Protection simultanément en production, c'est deux sources de changement silencieux en parallèle. Si un incident survient, vous ne savez pas lequel des deux workloads en est responsable. Espacez les bascules d'au moins une semaine, avec une fenêtre d'observation entre les deux.
Détecter les conflits GPO / MDM sur les machines Hybrid¶
# Compare GPO-managed vs MDM-managed registry values on a set of machines
# to detect potential write conflicts during co-management
$machines = @("PC-001", "PC-002", "PC-003", "PC-004", "PC-005",
"PC-006", "PC-007", "PC-008", "PC-009", "PC-010")
# Define key paths to check — adapt to your workload
$checks = @(
@{ Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"; Value = "WUServer" },
@{ Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows Defender"; Value = "DisableAntiSpyware" },
@{ Path = "HKLM:\SOFTWARE\Policies\Microsoft\Edge"; Value = "HomepageLocation" }
)
$results = foreach ($machine in $machines) {
foreach ($check in $checks) {
try {
$data = Invoke-Command -ComputerName $machine -ScriptBlock {
param($p, $v)
$val = Get-ItemProperty -Path $p -Name $v -ErrorAction SilentlyContinue
# Check MDM bridge enrollment
$mdmEnrolled = (Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Enrollments" -ErrorAction SilentlyContinue).Count -gt 0
# GPO last write time from RSOP (approx — check GPO policy source)
$gpResult = (& gpresult /scope computer /fo csv 2>$null) -join "`n"
[PSCustomObject]@{
Machine = $env:COMPUTERNAME
RegPath = $p
RegValue = $v
Data = $val.$v
MDMActive = $mdmEnrolled
}
} -ArgumentList $check.Path, $check.Value
$data
}
catch {
[PSCustomObject]@{
Machine = $machine
RegPath = $check.Path
RegValue = $check.Value
Data = "UNREACHABLE"
MDMActive = $false
}
}
}
}
$results | Format-Table -AutoSize
$results | Export-Csv -Path "C:\GPO_Export\ConflictCheck_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
Matrice de décision : GPP vs Intune CSP vs GPO¶
Le choix entre GPP, GPO et Intune CSP dépend du contexte de jonction et de l'objectif de gestion.
| Critère | GPO classique | GPP (Group Policy Preferences) | Intune / CSP |
|---|---|---|---|
| Jonction requise | AD on-prem | AD on-prem | Azure AD / Hybrid |
| Révocation au désalignement | Oui (tattoo = Non) | Non (tattoo = Oui) | Oui |
| Scope | Ordi ou User | Ordi ou User | User ou Device |
| Ciblage granulaire | WMI Filter | Item-Level Targeting | Assignments + Filters |
| Settings complexes (XML, JSON) | Limité | Limité | Oui (OMA-URI) |
| Reporting centralisé | Non (gpresult local) | Non | Oui (Intune portal) |
| Hors réseau AD | Non | Non | Oui |
| Coexistence possible | — | Oui avec GPO | Oui avec GPO (ADMX-backed) |
Règle de priorité en cas de conflit
En Hybrid Join, si un paramètre est défini à la fois par GPO et par Intune CSP, c'est le dernier écrit qui gagne — il n'y a pas de hiérarchie formelle entre les deux systèmes. La solution : ne pas dupliquer les paramètres entre GPO et Intune. Définir une frontière claire : GPO pour l'on-prem, Intune pour le cloud-native.
Migrer GPP → Intune
Pour migrer des GPP vers Intune, utiliser Group Policy Analytics dans le portail Intune (Devices > Group Policy Analytics) : il analyse les GPO existantes et indique quels paramètres ont un équivalent CSP direct.
En résumé
- Sur Hybrid Join,
gpsvccontinue d'appliquer les GPO normalement — l'enrôlement MDM ne les désactive pas - Le workload switching bascule l'autorité domaine par domaine — ce n'est pas tout ou rien
- Ne basculez jamais deux workloads majeurs le même jour en production
- Détectez les conflits de registre avant de basculer, pas après
ADMX-backed policies dans Intune¶
Ce que sont les ADMX-backed policies¶
Dans Intune, les Administrative Templates natifs couvrent les paramètres Microsoft (Edge, Office, Windows). Pour les ADMX tierces — Chrome, Firefox, Zoom, applications métier — vous devez importer les fichiers ADMX manuellement.
La fonctionnalité s'appelle Imported Administrative Templates dans Intune. Elle est disponible depuis Devices > Configuration profiles > Create > Windows 10 and later > Imported Administrative Templates.
Une fois importée, une ADMX apparaît comme n'importe quel Administrative Template natif. Vous créez un profil, vous configurez les paramètres, vous l'assignez à des groupes.
Importer une ADMX tierce dans Intune¶
Voici la procédure complète pour Chrome, applicable à n'importe quelle ADMX tierce.
Étape 1 — Télécharger les fichiers ADMX
# Download the latest Chrome ADMX bundle from Google
# Adapt the URL to the version you need — check https://chromeenterprise.google/browser/download/
$chromeAdmxUrl = "https://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip"
$destZip = "C:\ADMX_Import\chrome_policy_templates.zip"
$destExtract = "C:\ADMX_Import\chrome"
New-Item -ItemType Directory -Path "C:\ADMX_Import" -Force | Out-Null
Invoke-WebRequest -Uri $chromeAdmxUrl -OutFile $destZip
Expand-Archive -Path $destZip -DestinationPath $destExtract -Force
# ADMX files are in the windows\admx subfolder
$admxFiles = Get-ChildItem -Path "$destExtract\windows\admx" -Filter "*.admx"
Write-Host "Found ADMX files:"
$admxFiles | Select-Object Name
Étape 2 — Importer dans Intune via le portail
- Ouvrez
Devices > Configuration profiles - Cliquez sur Import ADMX (bouton en haut de la liste)
- Uploadez le fichier
.admx(ex :chrome.admx) - Uploadez le fichier
.admlcorrespondant (ex :chrome.admldepuis le dossieren-US) - Attendez le statut Available (quelques secondes à quelques minutes)
Étape 3 — Créer un profil basé sur l'ADMX importée
Devices > Configuration profiles > Create profile- Platform : Windows 10 and later
- Profile type : Imported Administrative Templates
- Sélectionnez l'ADMX importée (ex :
Google Chrome) - Configurez les paramètres comme dans GPMC
Limitations connues des ADMX-backed policies Intune¶
| Limitation | Détail | Impact |
|---|---|---|
| User scope partiel | Certains paramètres ADMX sont marqués "User scope only" — Intune les déploie uniquement si l'appareil est configuré en User Enrollment | Les paramètres User ne s'appliquent pas en Device Enrollment standard |
| Pas de filtrage WMI | Les ADMX Intune ne supportent pas les filtres WMI (contrairement aux GPO) | Les conditions complexes doivent être gérées par groupes Azure AD |
| Pas de GPP | Les Group Policy Preferences (raccourcis, sources ODBC, etc.) n'ont pas d'équivalent ADMX Intune | Voir section "Paramètres sans équivalent MDM" |
| Conflits de namespace | Deux ADMX avec le même namespace provoquent une erreur d'import | Vérifier les namespaces ADMX avant import (categories dans le XML) |
| Taille max | Limite de 1 Mo par fichier ADMX | Les ADMX volumineuses (Office, certaines suites) doivent être divisées |
Vérifier qu'une ADMX-backed policy Intune est appliquée¶
# Verify that an ADMX-backed Intune policy has written the expected registry value
# Run locally on the target machine or via Invoke-Command
$checks = @(
@{
Description = "Chrome Homepage via Intune ADMX"
Path = "HKLM:\SOFTWARE\Policies\Google\Chrome"
Value = "HomepageLocation"
Expected = "https://intranet.corp.local"
},
@{
Description = "Firefox default browser check disabled"
Path = "HKLM:\SOFTWARE\Policies\Mozilla\Firefox"
Value = "DontCheckDefaultBrowser"
Expected = 1
}
)
foreach ($check in $checks) {
$actual = Get-ItemProperty -Path $check.Path -Name $check.Value -ErrorAction SilentlyContinue
$status = if ($actual -and ($actual.($check.Value) -eq $check.Expected)) { "OK" } else { "MISSING/WRONG" }
Write-Host "[$status] $($check.Description) — Expected: $($check.Expected) / Got: $($actual.($check.Value))"
}
[OK] Chrome Homepage via Intune ADMX — Expected: https://intranet.corp.local / Got: https://intranet.corp.local
[OK] Firefox default browser check disabled — Expected: 1 / Got: 1
En résumé
- Les ADMX tierces s'importent dans Intune via Imported Administrative Templates
- Chrome, Firefox, Zoom, Office ADMX suivent tous la même procédure d'import
- Les paramètres User scope ne s'appliquent pas en Device Enrollment standard
- Pas de filtrage WMI dans Intune — remplacez les filtres par des groupes Azure AD dynamiques
Le piège de la fenêtre de conformité vide¶
Ce qui se passe quand vous supprimez la GPO trop tôt¶
Voici le scénario exact qui se produit en production plusieurs fois par an :
- L'admin crée le profil Intune, l'assigne au groupe. La politique s'applique sur les machines en ligne.
- L'admin supprime la GPO. À ce moment, toutes les machines qui ont reçu la politique Intune sont conformes.
- Deux heures plus tard, cinq laptops se reconnectent depuis l'extérieur. Ils n'ont pas encore reçu la politique Intune (cycle MDM toutes les 8 h maximum).
- Ces cinq machines n'ont ni la GPO (supprimée), ni la politique Intune (pas encore reçue). Elles sont dans un état non conforme non détecté.
La fenêtre de conformité vide dure jusqu'à ce que chaque machine ait effectué au moins un cycle MDM complet depuis l'enrôlement du profil. En pratique : entre 20 minutes (machine en ligne constante) et 8 heures (machine nomade qui se connecte une fois par jour).
La règle des deux semaines¶
Deux semaines représentent suffisamment de cycles pour que :
- Tous les appareils nomades aient eu au moins un cycle MDM
- Les éventuels incidents utilisateurs aient remonté au support
- Les machines en maintenance ou en stock aient été reconnectées
Ne pas confondre "la politique est verte dans Intune" (= assignée) avec "la politique est appliquée sur tous les appareils" (= vérifiée par inspection).
Script de détection avant suppression de GPO¶
Ce script compare l'état du registre sur un échantillon de machines et confirme que la politique MDM a bien écrit les valeurs attendues avant que vous supprimiez la GPO.
# Validate MDM policy application on N machines before deleting the source GPO
# Run this script 24h after enabling the Intune profile, then again after 2 weeks
param(
[string[]] $Computers = @("PC-001","PC-002","PC-003","PC-004","PC-005",
"PC-006","PC-007","PC-008","PC-009","PC-010"),
[string] $RegPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate",
[string] $RegValue = "WUServer",
[string] $ExpectedVal = "https://wsus.corp.local:8530",
[string] $GPOName = "Config-WSUS-Postes"
)
$results = foreach ($computer in $Computers) {
try {
Invoke-Command -ComputerName $computer -ScriptBlock {
param($path, $val, $expected, $gpoName)
# Read current registry value
$current = (Get-ItemProperty -Path $path -Name $val -ErrorAction SilentlyContinue).$val
# Check MDM enrollment status
$enrollments = Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Enrollments" -ErrorAction SilentlyContinue
$mdmEnrolled = $enrollments.Count -gt 0
# Check last MDM sync time
$syncLog = Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" `
-MaxEvents 1 -ErrorAction SilentlyContinue
$lastSync = if ($syncLog) { $syncLog.TimeCreated } else { "Unknown" }
[PSCustomObject]@{
Computer = $env:COMPUTERNAME
RegValue = $current
ValueMatch = ($current -eq $expected)
MDMEnrolled = $mdmEnrolled
LastMDMSync = $lastSync
ReadyForGPODelete = ($current -eq $expected) -and $mdmEnrolled
}
} -ArgumentList $RegPath, $RegValue, $ExpectedVal, $GPOName
}
catch {
[PSCustomObject]@{
Computer = $computer
RegValue = "UNREACHABLE"
ValueMatch = $false
MDMEnrolled = $false
LastMDMSync = "N/A"
ReadyForGPODelete = $false
}
}
}
$results | Format-Table -AutoSize
$notReady = $results | Where-Object { -not $_.ReadyForGPODelete }
if ($notReady.Count -gt 0) {
Write-Warning "$($notReady.Count) machine(s) NOT ready. Do NOT delete GPO '$GPOName' yet."
$notReady | Select-Object Computer, RegValue, MDMEnrolled, LastMDMSync | Format-Table -AutoSize
}
else {
Write-Host "All $($results.Count) machines validated. Safe to proceed with GPO deletion." -ForegroundColor Green
}
Computer RegValue ValueMatch MDMEnrolled LastMDMSync ReadyForGPODelete
-------- -------- ---------- ----------- ----------- -----------------
PC-001 https://wsus.corp.local:8530 True True 04/06/2025 08:32:11 True
PC-002 https://wsus.corp.local:8530 True True 04/06/2025 09:14:55 True
...
PC-010 https://wsus.corp.local:8530 True True 04/06/2025 07:58:02 True
All 10 machines validated. Safe to proceed with GPO deletion.
PC-007 UNREACHABLE False False N/A False
PC-009 https://old-wsus:8530 False True 03/06/2025 22:11:40 False
WARNING: 2 machine(s) NOT ready. Do NOT delete GPO 'Config-WSUS-Postes' yet.
Production — Supprimer une GPO est irréversible sans backup
Avant toute suppression de GPO, exécutez Backup-GPO -Name "NomGPO" -Path "C:\GPO_Backups\". La restauration via Restore-GPO depuis un backup prend moins de 2 minutes. La recréation manuelle d'une GPO complexe peut prendre des heures.
Voir le chapitre 05 — Backup et migration pour la stratégie de backup GPO complète.
En résumé
- La fenêtre de conformité vide = temps entre suppression de la GPO et réception de la politique MDM par tous les appareils
- Cette fenêtre peut atteindre 8 heures pour les appareils nomades
- Deux semaines d'observation minimum avant toute suppression
- Le script
Pre-GPODelete-Validation.ps1doit retournerReadyForGPODelete = Truesur 100 % des machines échantillonnées avant d'agir
Vérification post-migration¶
Valider l'état global d'une migration¶
Une fois la migration d'un workload terminée (GPO supprimée, politique Intune active), ces commandes confirment l'état final.
# Post-migration audit: verify Intune policy is active and no GPO remnants remain
# Run from a management machine with WinRM access to targets
param(
[string[]] $Computers = @("PC-001","PC-002","PC-003"),
[string] $DeletedGPOName = "Config-WSUS-Postes"
)
foreach ($computer in $Computers) {
Write-Host "`n=== $computer ===" -ForegroundColor Cyan
try {
Invoke-Command -ComputerName $computer -ScriptBlock {
param($gpoName)
# 1. Check GPO is no longer in applied policies
$rsopApplied = & gpresult /scope computer /fo csv 2>$null |
ConvertFrom-Csv |
Where-Object { $_.'Applied GPOs' -like "*$gpoName*" }
if ($rsopApplied) {
Write-Warning " GPO '$gpoName' still appears in gpresult output!"
}
else {
Write-Host " [OK] GPO not found in applied policies"
}
# 2. Check MDM enrollment
$mdmEnrolled = (Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Enrollments" -ErrorAction SilentlyContinue).Count -gt 0
Write-Host " [$(if ($mdmEnrolled) { 'OK' } else { 'FAIL' })] MDM enrollment: $mdmEnrolled"
# 3. Check last MDM sync
$lastSync = (Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" `
-MaxEvents 1 -ErrorAction SilentlyContinue)?.TimeCreated
Write-Host " [INFO] Last MDM sync: $lastSync"
# 4. Check compliance status via MDM bridge
$complianceKey = "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device"
$complianceExists = Test-Path $complianceKey
Write-Host " [$(if ($complianceExists) { 'OK' } else { 'WARN' })] MDM PolicyManager active: $complianceExists"
} -ArgumentList $DeletedGPOName
}
catch {
Write-Warning " Cannot reach $computer"
}
}
Checklist de validation finale¶
| Vérification | Commande / Action | Résultat attendu |
|---|---|---|
| GPO absente du domaine | Get-GPO -Name "NomGPO" → doit retourner une erreur | GpoWithNameNotFound |
GPO absente de gpresult | gpresult /scope computer /fo csv sur 5 machines | Nom de la GPO absent |
| Politique Intune = "Succeeded" | Portail Intune > Devices > [device] > Device configuration | Status: Succeeded |
| Valeur registre correcte | Get-ItemProperty -Path ... -Name ... | Valeur attendue présente |
| Aucun ticket support lié | Helpdesk — filtrer les tickets des 2 dernières semaines | 0 incident lié au workload migré |
| MDM enrolled | dsregcmd /status → MDMEnrolled : YES | YES sur toutes les machines |
En résumé
- Une fois la migration d'un workload terminée (GPO supprimée, politique Intune active), ces commandes confirment l'état final.
- Validez toujours le résultat sur un poste ou un utilisateur réellement dans le périmètre avant d’élargir.
- Conservez les commandes et résultats de contrôle comme preuve de conformité post-déploiement.
Références croisées¶
- Chapitre 18 — Azure AD Hybrid Join : prérequis et configuration du Hybrid Join, co-management initial
- Chapitre 20 — SCCM/MECM : co-management MECM/Intune et workload switching depuis MECM
- Bible GPO — Chapitre 25 : Convergence GPO/MDM : théorie de la convergence, architecture CSP, comparaison des modèles de gestion
En résumé
- À relire : Chapitre 18 — Azure AD Hybrid Join.
- À relire : Chapitre 20 — SCCM/MECM.
- À relire : Bible GPO — Chapitre 25 : Convergence GPO/MDM.
- Ces renvois prolongent le chapitre avec des mécanismes complémentaires ou des cas d’usage voisins.
- Gardez ces chapitres sous la main pour le diagnostic ou la conception d’une GPO liée à ce thème.