Wireless Network policy stores its settings within the GPC for a given GPO. Specifically, a new container structure is created under the GPC container in Active Directory with the path of CN=Wireless,CN=Windows,CN=Microsoft. Within the CN=Wireless container, a new object of class msieee80211-Policy is created that holds the Wireless Network policy settings that you specify.

Folder Redirection policy is stored in the GPT for a given GPO and specified within a file called Fdeploy.ini. The Fdeploy.ini file contains the policy details. For example, if you configure redirection for the My Documents folder so that it points to the user’s home directory, the Fdeploy.ini file is created or updated to include the related settings, as shown here:

[FolderStatus]
My Documents=11
My Pictures=2
[My Documents]
s-1-1-0=\%HOMESHARE%%HOMEPATH%
[My Pictures]

In this example, the [FolderStatus] section tells the CSE what to do with the My Documents folder if redirection no longer applies. It also tells the CSE what to do about the My Pictures folder underneath My Documents. The values of these keys change as you choose different options within the Folder Redirection policy. The [My Documents] section lists the redirection that is taking place. Because we are specifying basic redirection, it specifies that the SID S-1-1-0, which indicates the Everyone group, should be redirected to the user environment variables that point to the user’s specified home directory when they log on.

When the Folder Redirection CSE is processed, the contents of Fdeploy.ini are cached on the workstation within the user’s profile, along with another file containing information about the redirected folders prior to redirection. These files are found in %UserProfile%Local SettingsApplication DataMicrosoftWindowsFile Deployment. Typically, this folder contains two .ini files—one called {0E35E0EC-FD6D-4CEF-9267-6EDB00694026}.ini, which contains the cached folder redirection instructions from Fdeploy.ini, and one called {25537BA6-77A8-11D2-9B6C-0000F8080861}.ini, which contains information about all possible redirected folders (such as Desktop, Start Menu, and so on), including the GUID of the GPO that is currently responsible for any redirection that is taking place.

Administrative Templates policy is stored within the GPT in a file called registry.pol. When both per-computer and per-user Administrative Templates policy is specified within a GPO, there will be a registry.pol file under both the Machine and User folders within the GPT. Registry.pol files are text files, but you cannot edit them manually because they contain some special characters and follow a precise format.

Because Disk Quota policy is a subset of Administrative Templates policy, the settings for this policy area are stored within the registry.pol file, just as with Administrative Templates policy. Because Disk Quota policy is available only per computer, the registry.pol file containing these policy settings is found only under the Machine folder within the GPT.

As with Disk Quota policy, QoS Packet Scheduler policy has its own CSE to process policy settings, but QoS Packet Scheduler policy is a subset of Administrative Template policy. The settings for this policy area are stored within the registry.pol file, just as with Administrative Templates policy.

Scripts policy encompasses both startup/shutdown and logon/logoff scripts. Both are stored within the GPT. Shutdown and startup scripts are found within the Machine subfolder of the GPT (in a scriptsshutdown or scriptsstartup folder, respectively). Logon and logoff scripts are found within the User subfolder of the GPT (in a scriptslogon or scriptslogoff folder, respectively).

When you configure scripts, you specify where they are located and any parameters that should be passed to the scripts when they are run. References to the scripts that you specify are stored in a file called Scripts.ini within the GPT. This file is located within the machinescripts or userscripts folder, depending on whether the policy describes per-computer or per-user scripts. The file contains references to the defined scripts and any parameters that are passed to them. When the Scripts CSE runs, information about which scripts need to be executed is stored within the registry. For per-computer scripts, the registry location is:

HKEY_LOCAL_MACHINESoftwarePoliciesWindowsSystemScripts

For per-user scripts, the registry location is:

HKEY_CURRENT_USERSoftwarePoliciesWindowsSystemScripts

When it comes time to actually execute the script, the path to the script is read from one of these two registry locations.

Internet Explorer Maintenance policy is stored within the GPT in the UserMicrosoftIEAK folder. The actual settings are stored in a file called install.ins. In addition, there might be a Branding folder within the IEAK folder that holds any custom bitmaps, icons, or other files that are specified within the Internet Explorer Maintenance policy.

When the Internet Explorer Maintenance CSE processes this policy, the install.ins file and any related folders and files under the Branding folder are downloaded and cached within the user’s profile under %UserProfile%Application DataMicrosoftInternet ExplorerCustom Settings. From here, they are processed and applied to the Internet Explorer configuration.

Table 13-7 shows where each of the Internet Explorer Maintenance policy areas stores its settings within the GPT.

Security policy is stored within the GPT in the MachineMicrosoftWindows NTSecEdit folder. Within this folder, a file called GptTmpl.inf is created to store policy settings. Not all security policy is stored within this file, however. Specifically, policies found within Computer ConfigurationWindows SettingsSecurity Settings and including Local Policies, Event Log, Restricted Groups, System Services, Registry and File System are stored in GptTmpl.inf. The settings in Account Policies are stored in the LSA database. Software Restriction settings are written to Registry.pol. IP Security policies are written to Active Directory.

If you open GptTmpl.inf in Notepad, you will see that the file has the same format as the Security Configuration and Analysis templates that you can create and apply outside of Group Policy. This is because Group Policy uses the same SecEdit engine to process Security policy as it does to process Security Configuration and Analysis templates.

When the Security Policy client CSE, Scecli.dll, processes security policy, it copies the GptTmpl.inf file to the computer’s local hard drive and processes the policy from there. The standard location to which GptTmpl.inf is copied is the %Windir%security emplatespolicies folder.

Because a computer can have multiple security policies from multiple GPOs, a series of temporary files is created within the %Windir%security emplatespolicies folder. These temporary files represent each GPO’s security policy settings and are numbered sequentially starting with Gpt00000.dom. Further, because some security policies, such as Account and Kerberos policy, can be applied only to the domain when found in a domain-linked GPO, these policies are downloaded to a special file with a .dom extension. This ensures that all domain controllers process only this domain-linked policy for these special policy settings.

Software Installation policy is a policy area that uses both the GPC and GPT to store its settings. Within the GPT under the Machine (or User) folder, an Applications folder is created with an Application Assignment Script file (.aas file). The .aas file is specific to the application, its MSI file, and the network path that it has been deployed from. The GPC portion of Software Installation policy is stored within the corresponding Machine (or User) container in the CN=Packages,CN=Class Store container within the GPC. For each application deployed within the GPO, there is packageRegistration object within the Packages container.

Each packageRegistration object contains information about the application that has been deployed. Some of the more interesting attributes on this object are:

Note

Because the path to the MSI file is embedded in both the GPC and GPT portions of a Software Installation policy, you cannot change the path of an application once it has been deployed without redeploy the application. As discussed in Chapter 9, it’s best to use DFS paths when deploying application packages for this very reason.

Unlike other areas of policy, details about IP Security policy are stored in a different part of Active Directory than the GPC. You’ll find IP Security Policy in the CN=IP Security,CN=System container within the domain naming context. This means you access it in ADSI Edit by connecting to the domain naming context, double-clicking the domain node, such as DC=cpandl,DC=com, expanding CN=System, and then selecting CN=IP Security (Figure 13-10).

Figure 13-10. Viewing IPSec policy objects within the CN=IP Security, CN=System container

When an IPSec policy that has been created in a domain and stored in Active Directory is assigned to a GPO, a container is created within the GPC to hold that association.

Specifically, within the CN=Windows,CN=Microsoft,CN=Machine container under the GPC, an object of class ipsecPolicy is created to hold the reference to the IPSec policy that is associated with that GPO. The reference to the IP Security policy itself is stored within the ipsecOwnersReference attribute on this ipsecPolicy object, and it contains the DN of the IP Security Policy object within the CN=IP Security container.

Group Policy history data is stored in the registry under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionGroup PolicyHistory. One primary use for maintaining history information is to determine whether a GPO being processed has changed since the last time it was processed. For this reason, version information and other details about processed GPOs are stored for later retrieval. Each key under the History key represents the CSE being processed and is named with the GUID of the related CSE. Following this, history data from processing the Administrative Templates CSE is stored in the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionGroup PolicyHistory{35378EAC-683F-11D2-A89A-00C04FBBCFA2} key.

Organizing the history keys according to the GUID of the related CSE makes it easy to compare the previously processed GPOs. A numerically indexed (0, 1, 2, and so on) list of keys under the CSE keys is used to store information related to the actual GPOs that have been processed during the last processing cycle by that CSE (Figure 13-11). The values stored in these keys include the GPO’s friendly name, its GUID, the path to the GPC and GPT, and most important, the version number of the GPO when it was last processed.

Figure 13-11. Viewing a GPO’s history within the registry CSE key

The version information is used to compare the GPO currently being processed to the previously processed one. If the GPO being processed has a version number greater than the one held in the registry, the CSE continues processing the GPO. If the version number is equal to that held in the registry, the CSE stops processing the GPO unless you’ve overridden the default processing behavior for that CSE.

Note

The version number of the GPO about to be processed should never be less than that held in the history key. If it is, that indicates some kind of problem with your Group Policy infrastructure. If a GPO’s version number is 0, it is not processed because it is assumed that there are no policies set on it.

The history information is also important in one other aspect of Group Policy processing that we haven’t covered yet—the notion of the deleted list. Here’s how the deleted list works:

As an example of how the deleted GPO list is used, consider the following: Folder Redirection policy provides an option that lets you redirect folders back to their original location when the GPO no longer applies. To know that a GPO no longer applies, the Folder Redirection CSE has to build a deleted GPO list before processing policy. If it didn’t do this, folders would never be redirected back to their original location.

Group Policy state data is stored in the registry under HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionGroup PolicyState. State information is used primarily by RSoP logging to report on certain aspects of the last policy processing cycle. Some of these include whether a slow link was detected during the last processing cycle, the time at which policy processing was last performed, the state of each GPO link, and the state of each GPO that was processed. If you examine the contents of the state keys, you will see that they are arranged in per-computer (under the Machine key) and per-user (under SID-named keys) fashion.

The per-machine and per-user SID keys have three subkeys in common:

The Extension-List key usually contains a sub-key called {00000000-0000-0000-0000-000000000000}. This all-zero GUID stands for the core Group Policy Engine. Within this key, you will see values that list when the last computer-specific Group Policy processing cycle started and ended (such as, StartTimeLo, StartTimeHi, EndTimeLo, EndTimeHi). Other extension keys typically contain RSoP logging information. The DiagnosticNamespace value lists which namespace was processed for logging, such as \ENGPC07ROOTRsopComputer.

Tip

The Gptime.exe utility on the companion CD uses this start and stop state information to report the times and duration of the last Group Policy processing cycle.

All linked GPOs that were processed by this machine are listed in the GPLink-List key along with their link status—such as Enabled or Enforced (a.k.a. No Override). The DsPath value provides the DN of the linked GPO, such as cn={9FC124A6-626F-4C4C-9BAE-D75B779D21BF},cn=policies,cn=system,DC=cpandl,DC=com. The SOM value provides the scope of the linked GPO (which level the GPO applies to, such as DC=cpandl,DC=com for a GPO that applies to the domain scope). For the local machine GPO, the DsPath and SOM values are set to LocalGPO and Local, respectively.

Within the GPO-List key, information about each GPO that was processed is stored. The AccessDenied value indicates whether the GPO was skipped because security filtering prevented it from being processed. The GPO-Disabled value indicates whether the GPO was disabled. The Options value details any options that were set on the GPO (for example, whether the Computer Configuration or User Configuration portions of the GPO were disabled). The GPOID value contains the GPO GUID. The GPO-List information is used when reporting on RSoP using a tool such as Gpresult.exe or the GPMC Group Policy Results Wizard.

The per-user SID-named key has two additional sub-keys: Loopback-GPLink-List and Loopback-GPO-List. These subkeys are used when you change the default loopback processing mode. Loopback-GPLink-List contains information on all linked GPOs that were loopback processed, and Loopback-GPO-List contains information on the loopback processed GPOs themselves.

Group Policy caches group membership information to track the specific security groups that the computer and the currently logged on user belong to. The membership information is used determine whether and how security filtering will affect the list of GPOs that need to be processed, and because it is so critical, the information is updated each time policy is processed. The membership information is also used to provide output details for Gpresult.exe and the GPMC Group Policy Results Wizard when tracking security or examining security filtering details.

The SIDs for all security groups a computer belongs to are stored under the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionGroup PolicyGroupMembership key. For any users who have logged on to a computer, a list of the groups they belong to is stored according to their SID under the HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionGroup Policy<SID of user>GroupMembership key.

If you examine the GroupMembership key, you’ll find key values named Group0, Group1, Group2, and so on that contain the SID of the security group to which they relate. You’ll also find a Count value, which provides a count of all the security groups that apply. For example, if four security groups apply, Count has a value of 4 and there are key values named Group0, Group1, Group2, and Group3.