dcsimg

Learn AD in 15 Minutes a Week: Active Directory Group Policy Page 3

By ServerWatch Staff (Send Email)
Posted May 29, 2002



Group Policy Processing Exceptions

As with everything, there are always exceptions to the rules.

If a workstation is in a domain and a user logs on with a LOCAL account only, the computer configuration settings are processed only and then any LOCAL user account configurations. Also, if you log on to a domain member that is disconnected from the network with a CACHED DOMAIN ID, you will not get your UPDATED user configuration settings. You will log on with the CACHED credentials ONLY.

GPOs may be affected by Block Policy Inheritance and No Override settings.

Site, domain, or OU level group policy inheritances can be blocked via the Block Policy Inheritance setting. (GPO links set to No Override are always applied and cannot be blocked -- I will mention this in a minute.)

Block Policy Inheritance is applied at the site, domain, or OU level and is an all or nothing deal. It cannot be applied to specific GPOs or the links. If you set Block Policy Inheritance at the site level, then all of the site level group policy settings from all site level linked GPOs are stopped. If you set Block Policy Inheritance at the domain level, then all of the domain level group policy settings from all domain level linked GPOs are stopped. If you set Block Policy Inheritance at the OU level, then all of the OU level group policy settings from all OU level linked GPOs are stopped from any and all GPOs linked at that OU and all inheritance is stopped from that OU as well.

[NOTES FROM THE FIELD] -  If you set Block Policy Inheritance at the OU level, it will affect inheritance from that OU down if the GPOs are set to that OU. Anything lower in the hierarchy is not affected. That is, if you have an OU called US and child OUs named NY, MA and CT and if the children of each one of those are Sales and Management, and you place a Block Policy Inheritance at US, you will stop anything set at US from propagating down to all of the OUs below it. If you set three identical GPOs, one at NY, MA and CT, these WILL propagate down to the Sales and Management OUs.

No Override is applied to the GPO links, and it always trumps Block Policy Inheritance. If Block Policy Inheritance is set at the site level and there are three site level GPOs and one of them has No Override set to it, then Block Policy Inheritance will stop the other two but not the one set to No Override.

GPOs linked to sites, domains, or OUs can be set to No Override so that none of its policy settings can be overridden at any level. That is, if site level GPO C is executed third and wants to change a setting that No Override site level GPO A set, it won't be able to since No Override was set. If any domain level GPOs (which are processed AFTER all of the site level GPOs are processed) attempts to change a setting forced from the site level GPO it will not be able to do so either.

[NOTES FROM THE FIELD] -  This is a very sticky and difficult exception to wrap your head around. (It was for me anyway.) There is a great download on the Microsoft website and the main page it is on also defines this as well:

"You can set No Override on a specific Group Policy object link so that Group Policy objects linked at a lower-level of Active Directory, closer to the recipient user or computer account, cannot override that policy. If you do this, Group Policy objects linked at the same level, but not as No Override, are also prevented from overriding. If you have several links set to No Override, at the same level of Active Directory, then you need to prioritize them. Links higher in the list have priority on all Configured (that is, Enabled or Disabled) settings.

If you have linked a specific Group Policy object to a domain, and set the Group Policy object link to No Override, then the configured Group Policy settings that the Group Policy object contains apply to all organizational units under that domain. Group Policy objects linked to organizational units cannot override that domain-linked Group Policy object."

GPOs may also be affected by a Loopback setting, which provides alternatives to the default method of obtaining and executing the normal order and processing of computer and user configurations.

Domain user settings come from a GPO list that depends on all of the factors mentioned earlier. Local GPOs are first, then site GPOs, followed by domain GPOs, and finally OU GPOs, as well as any ordering lined up by the domain administrator and so on.

In some cases you might not want to have user specific settings applied to certain computers. For example, you might have a software deployment set to your user ID so that no matter where you went in the domain and no matter which computer you logged on to, it would allow you to have that program at your disposal. This might not be warranted on a server that you need to log on to locally with your domain ID. This is where loopback is an asset.

Loopback can be set to Not Configured, Enabled, or Disabled, just like any other group policy setting. Once loopback is enabled it can be set to Merge or Replace.

When Replace is set, the GPO list for the user is entirely overwritten again by the computer configuration GPO. The computer configuration GPOs replaces the user configuration GPO in its entirety.

[NOTES FROM THE FIELD] -  In this scenario the computer configuration GPO is run at startup and every time a user logs on to the given computer or server their user configuration GPO is run. However, before the GUI appears to allow the user to work on system, the computer configuration GPO is run again to "correct" all of the user configuration GPO settings by overwriting them.

When Merge is used, the GPO list is obtained for the computer at startup and is appended to the GPO list obtained for the user after they log on. Basically the computer configuration is applied again later which allows it to take precedence if it conflicts with settings in the user's list, but it may not overwrite all of the settings made by the user configuration GPO.

[NOTES FROM THE FIELD] -  In this scenario the computer configuration GPO is run at startup and every time a user logs on to the given computer or server their user configuration GPO is run. However, before the GUI appears to allow the user to work on system, the computer configuration GPO is run again to "append" all of the user configuration GPO settings by ADDING the computer configuration GPO settings to the system again. This may not overwrite all of the settings made by the user configuration GPO like the loopback replace setting does.


Well, that wraps up this section of  Windows 2000 Active Directory Group Policy. I hope you found it informative and will return for the next installment of Learn Active Directory Design and Administration in 15 Minutes a Week.

If you have any questions, comments or even constructive criticism, please feel free to drop me a note.

I want to write good, solid technical articles that appeal to a large range of readers and skill levels and I can only be sure of that through your feedback.

Next week, I plan to start with an overview of the Lightweight Directory Access Protocol (LDAP). (Really, I promise!)

Until then, best of luck in your studies.


"F.Y.I. can mean more than one thing"


Jason Zandri
Jason@Zandri.net

www.2000trainers.com

Page 3 of 3


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.