dcsimg
 

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

Wednesday May 29th 2002 by ServerWatch Staff

Jason Zandri's latest article in the Learn Active Directory Design and Administration in 15 Minutes a Week takes an in-depth look at the topic of Active Directory Group Policy.

by Jason Zandri
www.2000trainers.com

Welcome to the fifth installment of Learn Active Directory Design and Administration in 15 Minutes a Week, a weekly series aimed at current IT professionals preparing to write the new Windows Active Directory Design and Administration exams (70-219 and 70-217 respectively), as well as newcomers to the field who are trying to get a solid grasp on this new and emerging directory service from Microsoft. I was going to discuss the Lightweight Directory Access Protocol (LDAP) this week, but I had a few people write to me about Group Policy so I thought I would write about Active Directory Group Policy instead and delay my Lightweight Directory Access Protocol (LDAP) article until next week.


Group Policy

There are two types of group policy settings within the Windows 2000 Active Directory; computer configuration settings and user configuration settings. There are also two types of scripts that are run at start up; computer startup scripts and user logon scripts. The following sections will give an overview of how these configuration settings are applied.

[NOTES FROM THE FIELD] - Much of this information is an Exam Requirement for both the 70-217 AND the 70-219 exams. Some would argue it is more so for the 219 and I would agree, but you need to know both the Group Policy Administration pieces of 70-217 and the Group Policy Design requirements for 70-219 and much of this overlaps both exams. I took both exams singly and saw it for myself.

Computer Configuration Settings and Startup Scripts Overview

Computer configuration settings are used to set specific policies on local systems and are applied when the operating system initializes. They are the first things that are applied to any system due to the obvious fact that the system needs to fully initialize before a user can log on. The computer configuration settings are applied to everyone that logs on to that system. There may be user configuration settings (which are applied next) that override the computer configuration settings, but this does not mean they were not applied to the local system, only that they were overwritten by a subsequent user configuration setting or settings.

Computer configuration settings are processed synchronously (one after another, after another) by default, but this setting can be changed by the domain administrator. These settings are processed in a specific order. Local GPOs are first, then site GPOs, followed by domain GPOs, and finally OU GPOs. There is not an option to log on while the computer configuration settings are being processed.

Any computer startup scripts that are set to run for the system start after all of the GPOs are processed. This is also hidden from the user's view and runs synchronously by default. This is important because each script must complete or time out before the next one starts. If there are issues with any one single script, this will delay the startup competition of the system, as the default timeout period is set for 600 seconds (10 minutes). It is not recommended to change the synchronous execution nature of the scripts, as one may have a dependency on another, but it can be done at the administrator's discretion. The default timeout period of 600 seconds can be changed and often is.

[NOTES FROM THE FIELD] - In the following section titled Group Policy Settings Processing Order, I detail the full GPO processing as it follows the GPO order and inheritance tree.


User Configuration Settings and Logon Scripts Overview

The Ctrl+Alt+Delete screen appears for the first time since startup and the user can log on. When the user finishes entering their ID and password, a list of GPOs connected to the user is gathered and processed, determined by factors such as the user's domain membership (or lack thereof), whether the loopback setting is enabled on the local system and which loopback policy setting is being used, as well as a host of other factors, detailed below.

[NOTES FROM THE FIELD] - In the section below titled Group Policy Processing Exceptions I detail all of the exceptions to the group policy rules, which covers a few things including the loopback settings.

Also, do not confuse domain accounts and local accounts. If a workstation is in a domain and a user logs on with a LOCAL account only, any domain user account configuration GPO settings are not processed because the account is local. 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.

User configuration settings are used to set group policies for specific groups of users. The settings are applied to the users no matter where in the forest they log on and are processed synchronously by default. (So long as that system is in the domain. Domain user account configuration settings will not apply when a user logs on to a machine locally using a local account. The LOCAL user account settings from the LOCAL GPO will be applied.) The synchronous setting can be changed by the domain administrator. The user configuration settings initialize as the user logs on to the system and will overwrite any conflicting settings that were processed at the computer configuration level and are set in the following order; Local GPOs are first, then site GPOs, followed by domain GPOs, and finally OU GPOs. No user interface is displayed while user policies are being processed. This is that little piece of time after the Ctrl+Alt+Delete screen disappears and it seems as if something is happening behind the scenes. (Now you know what.) After all of the GPOs have been processed, all and any group policy-based user logon scripts run. These scripts are also run hidden, however, they run asynchronously by default.

The GUI will appear once the last user logon script completes.


Group Policy Settings Processing Order

All Windows 2000 systems have one Local Group Policy Object, which is processed first when the system is started. In a domain scenario, chances are, due to the fact that subsequent GPOs are likely to overwrite these settings, this GPO will have the least amount of impact on the local system when it is in a domain. On a STANDALONE Windows 2000 system it is usually the only GPO processed and in this case will have a large impact.

The next set of group policy settings that are processed are computer configuration settings for Site GPOs, if there are any set to your site. These GPOs are processing synchronously, meaning the domain administrator sets the order in which these will execute.

After any and all Site GPOs are run, the next set of GPOs to be deployed are Domain level computer configuration GPOs. These too are processed synchronously, with the order set by the domain administrator.

The final set of GPOs to be executed are OU level computer configuration GPOs. All of the GPOs linked to the upper most OU in the inheritance tree are executed first, followed by all that are in the next highest and so on, until you reach the local OU, which is executed last. At each OU in the hierarchy there may be several group policies. They are all processed synchronously in a specific order set by the domain administrator at each level. This means that all of the GPOs in the highest point of the inheritance tree are executed first in the specific order set by the domain administrator and then all of the GPOs at the next point of the inheritance tree are executed in the specific order set by the domain administrator and so on all the way down to the local OU.

After this is complete, any and all computer startup scripts that are set to run for the system start, and the Ctrl+Alt+Delete screen appears when they complete and the user can log on.

[NOTES FROM THE FIELD] -  The same set of steps follow with the user configuration settings. After a user logs on, the Local GPOs are run first, then site GPOs, followed by domain GPOs, and finally OU GPOs. With the OU level computer configuration GPOs, the GPOs linked to the upper most OU in the inheritance tree are executed first, followed by all that are in the next highest and so on, until you reach the local OU, which is executed last. At each OU in the hierarchy there may be several group policies. They are all processed synchronously in a specific order set by the domain administrator at each level.

After all of the user configuration GPOs have been processed, any and all group policy-based user logon scripts run. These scripts run hidden and asynchronously by default.

The GUI will appear once the last user logon script completes.


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

Mobile Site | Full Site