Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)

How Client Systems Get Group Policy Objects

The items stored on the server make up only half the story. The real magic happens when the GPO is applied at the client, usually a workstation, although certainly servers are not immune. Half of Group Policy's usefulness is in that it can apply equally to servers as well as desktops and laptops. Indeed, with Windows 2003 and the new policy settings it brings to the table, there's more than that you can control and configure. So the details in this section are for all clients servers and workstations.

When Group Policy is deployed from upon high to client systems, the clients always do the requesting. This is why, when the chips are down and things aren't going right, you'll need to trot out to the system and crack open the Event Log (among other troubleshooting areas) to help uncover why the client isn't picking up your desires.

Microsoft doesn't provide a way to instantaneously "push" the policy settings inside GPOs to clients, even if you think they should get a new change right now. Out of the box, there's no "push the big red button and force the latest Group Policy to all my clients" command to make sure every client gets your will. This can be a little disappointing, especially if you need a security setting, such as a Software Restriction Policy propagated to all your clients right now. There are two ways, however, to make this a reality:

• In Chapter 7, I'll show you a little scripting magic to forcefully push Group Policy out the door. Note, however, that this script needs to be "prepared" on the client machine before you can leverage it.

• Also available in the Third-Party Group Policy Solutions Guide on WWW.GPanswers.com is a link to a free tool, called RGPrefresh, which also performs this function. (Alternatively, you can download that tool right from my fellow MVP Darren Mar-Elia's website at http://www.gpoguy.com/Tools.htm#GPO%20Refresh .)

But, without these "tricks," unfortunately , Group Policy is processed only when the computer starts up, the user logs on, at periodic intervals in the background, as discussed in Chapter 3. In that chapter, you learned "when" Group Policy is processed; in this section, you'll learn both "how" and "why" Group Policy is processed .

Client-Side Extensions

When a Group Policy "clock" strikes, the Group Policy engine springs into action to start processing your wishes. The GPOs that are meant for the client are downloaded from Active Directory, and then the client pretty much does the rest.

When GPOs are set from upon high, usually not all policy setting categories are used. For instance, you might set up an Administrative Template policy, but not an Internet Explorer Maintenance policy. The client is smart enough to know which policy setting groups affect it. This happens after the client downloads all the GPOs and figures out what it should do with what it just downloaded. To do this, it compares the downloaded instructions with each known client-side extension (CSE).

CSEs are really pointers to DLLs (Dynamically Linked Libraries) that actually perform the Group Policy processing. These DLLs are built into clients capable of processing Group Policy: Windows 2000, Windows XP and Windows 2003. These CSEs are automatically registered in the operating system and are identified in the Registry by their Class IDs (which take the same naming convention as GUIDs).

Today, Group Policy has 13 major functional groups. You can see these groups if you open the front cover. In reality, Group Policy could be an unlimited set of functions, but only 10 are built into Windows 2000 out of the box, and another three are built into Windows XP and Windows 2003.

Additional CSEs can be created by third-party programmers who want to control their own aspects of the operating system or their own software.

To take a look at the CSEs on a workstation, follow these steps:

1. On Windows XP, log on as Administrator.

2. Choose Start ˜ Run to open the Run dialog box, in the Open box type Run Regedit , and press Enter to open the Registry Editor, as shown in Figure 4.13.

3. Drill down into HKLM ˜ Software ˜ Microsoft ˜ Windows NT ˜ Current Version ˜ Winlogon ˜ GPExtensions. Here you will find a list of Class IDs, each representing a CSE.

Figure 4.13: The client-side extension DLLs actually perform the GPO processing.

Figure 4.13 shows a sample CSE and the settings for disk quotas. See Table 4.1 for the CSEs listed by Class ID, the functions they perform, and the associated DLLs. Note that a particular DLL can be responsible for more than one function.

Neither Remote Installation Services (RIS ) nor Software Restriction polices require CSEs associated with DLLs. RIS is active before the operating system is. (For more information on RIS, see Chapter 11.) Software Restriction policies don't require CSEs because Windows XP has a bit of magic that occurs each time a new process starts. That is, each process verifies that it isn't in the "restricted" list. If it's not, it runs! (For more on Software Restriction policies, see Chapter 6.)

For each CSE, several values can be set or not. Not all CSEs use these values. Indeed, Microsoft does not support modifying them in any way. They are presented in Table 4.2 for your own edification, but in most circumstances, you should not be modifying them unless explicitly directed to do so by Microsoft Product Support Services (PSS).

I hope you won't have to spend too much time in here. But I present this information so that if you need to debug a certain CSE, you can go right to the source and see how a setting might not be what you want.

Remember that most of these settings are established either by the system default or can be changed. You can change the settings yourselfsuch as the ability to process over slow links, the ability to be disabled, or the ability to be processed in the backgroundusing the techniques described near the end of Chapter 3.

Where Are Administrative Templates Registry Settings Stored?

Because one of the most commonly applied policy settings is the Administrative Templates, let's take a minute to analyze specifically how Administrative Templates are processed when the client processes them.

I've already discussed how Group Policy is more evolved than old NT 4-style policies. Specifically, one of the most compelling features is that most policy settings do not tattoo the Registry anymore. That is, once a setting is applied, it applies only for that computer or user. When the user or computer leaves the scope of the GPO (for example, when you move the user from the Human Resources Users OU to the Accounting Users OU), the Registry settings that did apply to them are removed, and the new Registry settings now apply.

When an NT 4-style policy was written, the writer could choose to modify any portion of the Registry. Now, as you've seen, when the settings specified in the Administrative Templates section of Group Policy no longer apply (for example, when a new user logs on or the computer is moved to another OU), the settings are removed or applied appropriately for the next user.

Administrative Templates Group Policy settings are usually stored in the following locations:

• User Settings HKEY_CURRENT_USER\Software\Policies

• Computer Settings HKEY_LOCAL_MACHINE\Software\Policies

Alternatively, some applications may choose the following locations:

• User Settings HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies

• Computer Settings HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Currentversion\Policies

Knowing how this works helps us understand why Windows XP has about 200 more Administrative Templates policy settings that can apply to it. It's quite simple: the specific program that's targeted for the policy setting looks for settings at these two Registry locations. Sometimes that application is one we overlook a lot Explorer.Exe! For Windows XP, Explorer.exe has been "smartened up" and now knows to look in these Registry keys for about 200 new items. Windows XP/SP2's Firewall has been smartened up to look for about 20 new items. You get the idea.

This also answers the question of why Windows 2000 machines "overlook" policy settings that are designed only for Windows XP or Windows 2003. Ditto for how XP/SP1 machines overlook policy settings designed only for Windows XP/SP2. All systems that can download the policy settings do . But, who cares? If an older system downloads a policy setting, the registry is modified and then it's generally ignored. Windows 2000 just doesn't know to look for the new Registry changes that new Windows XP or Windows 2003 policy settings change. Occasionally, with the release of a service pack, the application in question might get a new lease on life and understand some new policy settingsbecause the application has now been updated to look for them in the Registry. This has already happened for Explorer, Software Update Services, Windows Media Player and Office to name a few.

Because the settings inside Administrative Templates are written to only these four locations, we are free from the bonds of having our Registries tattooed. The Administrative Templates CSE and DLI. ( Userenv.Dll ) applies the settings placed in any of these four locations to the current mix of user and system. When that mix changes, the settings change. It's as easy as that.