I have a user GPO linked to a Users OU, but I want its settings to stop applying when those users sign in on selected computers as the equivalent Intune device configuration rolls out. What are the practical options?
Can I exclude computers from a user-scoped GPO during an Intune rollout?
Answers
For user settings that need to vary by computer, look at Group Policy loopback processing. Link the relevant user settings to the computer OU and enable loopback there. Merge adds those computer-scoped user settings alongside the user's normal policies. Replace uses the user settings from policies linked to the computer's location instead, which can change a lot more than one setting, so test it carefully.
This changes how user policies are selected on those computers. It is not just a simple exclusion switch, and the existing GPO layout matters.
Reply to this answer
If you need a small, temporary rollout control, a security group can be used to change the GPO's permissions for selected computer accounts. Denying a computer account Read access can prevent user settings from that GPO applying on that computer, but this depends on the policy's permissions and processing setup. Validate it in a test OU and check the resulting policy report before using it broadly.
Be cautious with explicit deny permissions. They can be confusing to troubleshoot, and policy settings already written to a machine may not automatically revert just because the GPO stops applying.
Reply to this answer
I'd first confirm whether you need computer-based exclusions at all. If Intune is taking over the same settings, a controlled overlap may be simpler: assign the Intune configuration to a pilot, verify it actually applies and produces the intended result, then remove the old GPO when coverage is established.
Check which system wins if both manage the same setting, and test how the old setting is removed. Some settings can persist after policy stops applying, so a successful Intune assignment does not by itself prove cleanup is complete.
Reply to this answer
A separate user OU can work if you want to move users out of scope, but it sounds like a poor fit here if other policies and automation depend on the current OU structure. Duplicating those links and maintaining the parallel OU could create more work than the migration itself.
Since the desired condition is based on the computer, loopback or carefully tested computer-account filtering is more aligned with the requirement than moving users around.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions