WARNING: This post involves playing around with Active Directory, so don’t do this in a production environment. You use this information at your own risk. For other warnings, please see the disclaimer.
Group Policy is an incredibly powerful feature in Active Directory that allows one to implement specific configurations for users and computers. By creating Group Policy objects (GPOs), administrators can apply thousands of different settings to objects within Active Directory by linking the GPO to sites, domains, or organizational units (OUs).
Unfortunately, Group Policy’s flexibility can also increase its complexity. It’s one thing to specify a single setting, such as a password complexity rule, to the entire domain. It’s an entirely different thing to specify unique configurations for thousands of users or computers spread across different geographic areas. One area where there can be confusion is in determining which settings are applied to a particular user or computer when multiple policies exist.
Inheritance in Group Policy works very similarly to inheritance when it comes to NTFS permissions. The basic rule is “settings on parent objects are inherited by child objects”.
For example, let’s say you have an Organizational Unit (OU) hierarchy as follows:
Because it is linked to the domain, every OU under the domain inherits the settings of the Default Domain Policy GPO.
Let’s say the Default Domain Policy configures users to get a green desktop background. Regardless of where your user account is in the domain, you end up with a green desktop because the settings in the Default Domain Policy are inherited by all child objects (everything in the domain).
Now, let’s say that you need to create some settings for your sales department. So you create a GPO called “Sales Stuff” and you link it to the Sales OU:
Once you do that, the settings in Sales Stuff is applied to everything in the Sales OU, including Managers, Sales Reps and Sales Admin and everything they contain. Again, this is just how Group Policy works.
When multiple GPOs are applied, they are applied from the top down. So, the first GPO applied is the Default Domain Policy and the second is the Sales Stuff. (It’s not quite like that, but close enough for this discussion).
As each policy is applied, it will overwrite conflicting settings that previous policies applied. In our example, the Default Domain Policy GPO changes the desktop color to green. But, let’s say the Sales Stuff policy has the desktop color set to yellow.
Well, the first policy applied when you logon is the topmost policy. That’s the Default Domain Policy. So, it changes the setting on your computer to make the desktop background green. However, the Sales Stuff policy is applied next and it changes the setting to make the desktop background yellow.
Keep in mind, this only applies for configured settings which conflict with each other. In this case, the desktop color. But, if the Default Domain Policy also dictated what kind of mouse pointer you had, and that wasn’t specified in the Sales Stuff policy, the Default Domain Policy settings would be there, and because they won’t get overwritten by the Sales Stuff GPO, they would apply.
Well, the CEO will have none of that! By God, those desktops are going to be green, or some heads are going to roll!
No problem. In your Group Policy Management console, right-click on the Default Domain Policy and select “Enforced”.
Now, the Sales Stuff policy cannot overwrite the Default Domain Policy settings (and neither can any other GPO). So, when you log on, any setting the Sales Stuff policy would have overwritten, including the desktop color, are kept intact.
This is a very simplified explanation, but I hope it might clear up some fog on how this works.