Using the exact same two GPOs, let's change some of the override settings and see what happens. Recall that the "enabled" GPO won out in the last round. Let's see what happens when we set the "disabled" GPO to no override .
Open Active Directory Users and Computers , pull up the Properties for the North Wing OU , and click the Group Policy tab.
Select the GPO that we created in step 2 of the previous tutorial and click the Options button.
Place a check in the item labeled No Override: prevents other Group Policy Objects from overriding policy set in this one . Click OK . A check appears in the column labeled No Override :
Click OK .
In the previous tutorial, the GPO positioned lower in the domain tree takes precedence over the one higher in the tree. But because we have just given the GPO higher in the tree the no override setting, any conflicting rules will default to the GPO with the no override setting enabled.
Run an RSoP on the Users OU, just as we did in the previous tutorial, and check to see which GPO "wins." Your results should mirror what we see here:
The rule in the upper level GPO wins out this time, just the opposite of our results in the previous tutorial. If you log into the domain as a user from the Users OU under the Accounting OU, Add/Remove Programs opens just fine.
We now turn our attention to altering the inheritance behavior of GPOs by using the Block Policy Inheritance function. In this tutorial, we set the Users OU inside the North Wing OU to block policy inheritance. This prevents this OU from inheriting any GPOs higher up the domain tree ( Note: there is no way at this time to block certain GPOs such as password policies set in the default domain GPO ).
In Active Directory Users and Computers, open the Properties for the Users OU under the North Wing OU and click the Group Policy tab.
In the bottom left corner of the Properties window, place a check in the box labeled Block Policy Inheritance :
Click OK .
This is where things start to get really hairy. We have told the Users OU to block any GPOs from any parent objects higher up in the domain tree. This includes the GPO that we assigned to its parent North Wing OU. But it also includes any GPOs assigned even higher up the domain tree. For example, recall that in previous tutorials, we assigned a GPO to the guinea.pig domain container to process a ZAP file installation for Adobe Acrobat Reader, as well as brand all Internet Explorer windows with our custom Guinea Pig, Inc., logo. Checking block policy inheritance forces Windows Server 2003 to try and prevent these GPOs from applying themselves to the Users OU. Even more complicated is the fact that the GPO in the previous tutorial is set to no override, which in effect overrides our inheritance blocking on the Users OU. Are you beginning to see why RSoP is so useful? Let's run a simulation and see how this all comes out.
Run an RSoP on the Users OU. Upon checking the results, you should find that under the User Configuration:
The Adobe Acrobat Reader ZAP installation policy is blocked due to policy inheritance blocking.
The custom Internet Explorer title bar and Guinea Pig, Inc. logos branding are blocked due to policy inheritance blocking.
This disabling of the Remove Add/Remove Programs control panel is allowed to pass to the Users OU because of the No Override setting on its GPO.