So today, I'm going through and cleaning up/consolidating our GPOs and moved a couple from a second-level OU to the domain level. These (user) policies are used to block/allow access to the command prompt. By default, all users are blocked from using the command prompt. Users can then be added to a security group that has permission to run the second (higher precedence) GPO to turn it back on.
When the GPOs are in the second level, they work as expected. But once I move them to domain level, all users are blocked from using the command prompt, to include the onces that should have access.
Our GPOs are well segregated, and I verified there were no conflicting GPOs. Link order and policy inheritance precedence was verified. Group Policy results showed both policies applying on the appropriate users, yet command prompt access is still blocked. Moved the GPOs back down... and everything works again?
What gives? Is there something special at the domain level that would cause this behavior?
There's nothing special about the root of the domain as compared to a sub-OU when it comes to Administrative Template Group Policy settings (password policy treats it specially, but that's not what you're talking about).
I don't know what you mean by "conflicting GPOs". GPOs don't "conflict". They are applied in the order specified and the last setting applied is the one that "takes". There are no "conflicts" and no "conflict resolution" protocol.
Examine the output of a
gpresult /zfor both "types" of users with the policies linked as you'd like them and as they were. You should be able to find the cause of your issue in comparing those outputs. My gut says that you've got your link order wrong for what you want.Microsoft didn't make it easy to tell in the Group Policy Management Console what order the GPOs are applied in. It was a lot easier in the W2K3 / WK2 "gold" releases, in my opinion, to see what order the GPOs were going to be applied.