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.

Tip	The three new Windows XP and Windows 2003 CSEs are Software Restriction policies, 802.11x Wireless policies, and Quality of Service Packet Scheduler policies.

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

Note

Come to www.GPanswers.com for a latest look on products that have their own CSEs. As of this writing, PolicyMaker Professional by DesktopStandard, "Quest Group Policy Extensions for Desktops" by Quest Software, IntelliPolicy by FullArmor, and Special Operations Suite by Special Operations Software have their own CSEs.

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

On Windows XP, log on as Administrator.
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.
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.

Table 4.1: Class IDs, Their Functions, and Their Corresponding DLLs
Class ID	Function	DLL
C6DC5466-785A-11D2-84DO-OOC04FB169F7	Software deployment	Appmgmts.dll
3610EDA5-77EF-11D2-8DC5-00004FA31A66	Disk quotas	Dskquota.dll
B1BESD72-6EAC-11 D2-A4EA-OOC04F79F83A	EFSrecovery	Scecli.dlI
25537BA6-77A8-11 D2-9B6C-OOOOF8080861	Folder redirection	Fdeploy.dll
A2E30F80-D7DE-11d2-BBDE-OOC04F86AE3B	Internet Explorer settings	Iedkcs32.dll
e437bc1c-aa7d-11d2-a382-00c04f991e27	IP security	Gptext.dll
35378EAC-683F-11D2-A89A-00C04FBBCFA2	Registry settings (Administrative Templates)	Userenv.dll
42B5FAAE-6536-11D2-AE5A-0000F87571E3	Scripts	Gptext.dll
827D319E-6EAC-11D2-A4EA-00C04F79F83A	Security	Scecli.dll
OACDD40C-75AC-47ab-BAAO-BF6DE7E7FE63	Wireless (802.11x) (Windows XP only)	Gptext.dll
426031cO-Ob47-4852-bOca-ac3d37bfcb39	Quality of Service Packet Scheduler (Windows XP only)	Gptext.dll
None	Software Restriction (Windows XP only)	None
None	Remote Installation Services (RIS)	None

Note	When creating custom ADM templates (see "ADM Template Syntax" on this book's website), the CLIENTEXT keyword specifies which client-side extension is needed to process particular settings on the client computer.

Why Don't All CSEs Have DLLs?

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).

Table 4.2: Client-Side Extension Values
Value	Data Type	Function	Data	Default
DLLName	REG_EXPAND_SZ	Contains the DLL name	CSE DLL	Per CSE
ProcessGroupPolicy	REG_SZ	Used to call a subset of the CSE DLL	The function call name	Per CSE
NoMachinePolicy	REG_DWORD	Enable/disable machine processing	0=Process; 1=Don't process
NoUserPolicy	REG_DWORD	Enable/disable user processing	0=Process; 1=Don't process
NoSlowLink	REG_DWORD	Enable/disable over slow link	0=Process; 1=Don't process
NoBackgroundPolicy	REG_DWORD	Enable/disable background GPO processing	0=Process; 1=Don't process
NoGPOListChanges	REG_DWORD	Process if changed or not	0=Always process; 1=Do not process unless changes
PerllserLocalSettings	REG_DWORD	Caches policies for user or machine	0=Don't cache; 1=Cache
RequiresSuccessfulRegistry	REG_DWORD	Forces CSE DLLs to be registered with the operating system	0=Don't care; 1=CSEs must be registered
EnableAsynchronousProcessing	REG_DWORD	Enable/disable asynchronous GPO processing	0=Synchronous; 1 = Asynchrounous	Depends on the CSE

Warning

Remember, the CSE sets these valuesyou don't, unless you're directed by Microsoft PSS to help make sure the CSE is working the way it's supposed to.

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

Tip	Microsoft is encouraging third-party developers to write their applications so that they look in the first set.

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.

Tip

If you have a mixture of Windows 2000 desktops and member servers and Windows XP and Windows 2003 member servers, you might need to keep track of policy settings that affect only XP. It's likely a good idea to create GPOs with names specific to what operating system they apply to: Windows 2000, Windows XP, and/or Windows 2003.

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.

Note	For information on how to use other Administrative Templates, see Chapter 5, and for information on how to create your own Administrative Templates, see "ADM Template Syntax" on this book's website.