Topic Hub
Group Policy diagnosis and Intune coexistence
Prove why a Group Policy setting is not applying, then decide whether Active Directory or Intune Settings Catalog owns it. Use the three published paths: diagnosis, dual-channel conflict, and Settings Catalog migration.
3 published articles in this reading list
Name the computer and user first
Most “the GPO did not apply” tickets start at the wrong object. Capture the affected computer, the affected user, the setting name, and whether the expected result is computer or user configuration. A link that looks correct in GPMC is not evidence that the target object is in scope.
Collect RSoP before another gpupdate
Run gpresult or an RSoP report on the failing object before forcing a refresh. Use that output to separate security filtering, WMI filters, blocked inheritance, loopback, slow-link behaviour, and a competing cloud policy. Repeating gpupdate /force does not invent missing scope.
One owner before an Intune move
Do not migrate a setting you cannot prove is in effect. Inventory the current Administrative Template or GPO value, decide whether Active Directory or Intune Settings Catalog owns it, then move only that setting. Dual-source the same control and you will spend the next incident arguing about which policy won.
How to use the published paths
Use the diagnosis guide when RSoP is empty or the GPO is filtered. Use the conflict guide when both a GPO and an Intune profile are assigned. Use the Settings Catalog migration guide only after the current winner is proven and you have picked one owner.
Troubleshooting Guides
A Group Policy setting is not applying
Includes a redacted computer RSoP excerpt with an applied GPO and a security-filter denial. Use that observation alongside the scope, replication and processing checks.
Includes captured RSoP evidence
Group Policy and Intune both apply
When a GPO and an Intune profile target the same Windows setting, prove the winning channel before anyone enables MDMWinsOverGP.
Published guidance