Home

General GP Concepts
.. GPMC
.. Create/Edit GPOs
.. Targeting GPOs
.. Applying GPOs
.. Developer Issues

Extensions
.. Admin Templates
.... Windows Firewall
.... Internet Explorer
.. Security Policy
.. Software Installation
.. IE Maintenance
.. Scripts

Policy Exceptions
.. Loopback
.. Enforce/Block
.. Slow Links
.. WMI Filters

Reference
.. Third Party Products
.. KB Articles
.. Community

Terms of Use
Trademarks
Privacy Statement

Client Side Extension (CSE) processing order is calculated by the operating system, which initiates each CSE. During each policy refresh interval, the operating system determines which CSEs should be launched based on several criteria, including the following:

• Computer/user processing
• Settings changes/policy
• Slow link detection/policy
• Background/foreground/policy
• Registry policy success/failure
• Security filters
• Enabled/disabled state
• WMI filters
• Enforcement
• Inheritance blocking
• Loopback processing

It should be clear from the list above that determining why a CSE is not being launched by Windows is often a complex troubleshooting task.

Processing Order

The CSEs that are to be launched are launched in the order listed in the following registry key (sorted alphabetically by their ID). This is the documented location where each extension must register in order to process its policy and/or planning mode data. This ordering is the same for user and for computer policy, although these two modes operate independently. Given that these two types of configuration operate independently, it is possible and not uncommon for user and computer processing to occur simultaneously.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions

Processing is always Sequential

CSEs always process policy in order and one after the other, i.e. sequentially, for user or computer configuration respectively. As a result policy can be "chained" in order to leverage the results of one in another. For example, a PolicyMaker Drive Maps policy may set a drive map to the end-user’s home directory. This drive map can be referenced in Microsoft’s Folder Redirection policy. Later the PolicyMaker Folders policy can create nested folders within the drive, PolicyMaker Files policy can copy a file to the new folder, and PolicyMaker Mail Profiles policy can configure a Personal Folders service to point to that file. Extensions are generally ordered to optimize the potential for policy chaining.

Policy chaining implies that if a specific policy fails subsequent policies that rely on the failed setting may also fail or result in unpredictable behavior. In order to account for this possibility, policy filters may be used to detect the proper conditions for applying chained policies. Note that this situation may exist for unchained policies as well. The native extensions do not provide per-setting filtering, making the handling of such situations more complicated, as filtering must be applied at the GPO level. In many cases the failure and associated results reporting of chained (or unchained) policy is sufficient error handling, although the net result is still that the policies are not applied.

Foreground, Background and Asynchronous Processing

This is possibly the most misunderstood aspect of Group Policy processing. Asynchronous processing does not mean that CSEs are processed out of order or processed concurrently, that GPOs are processed out of order, or that "cached" GPOs are applied. These are never the case (with the exception that user and computer policy may process simultaneously, as noted above). Processing is always ordered and sequential. Asynchronous processing is simply a reference to the asynchronous foreground mode of policy processing. Policy is processed in two basic modes, foreground and background. However, foreground mode is split into synchronous foreground and asynchronous foreground. The mode in which the computer processes policy in the foreground is subject to several factors, but the change in processing is relatively simple.

Asynchronous processing is nothing more than background refresh that starts during the logon or startup process. The essential difference with asynchronous processing is that it does not hold up the logon or startup process, thereby giving the end-user the impression that the process is faster. However, there are important things to consider when allowing Group Policy to process in the foreground asynchronously.

1. The most important consideration is that settings that would otherwise be applied before the user has access to his/her environment, are not applied until later. This may have negative security or end-user experience implications.
2. Some individual policy settings will only take effect if set before the computer or user logon process completes. For example, when the explorer loads it may look for the policy that sets the wallpaper, and load the default wallpaper if the policy is not set. Of course it must do this or the wallpaper would be changing right before the end-users' eyes. As a result, these policies have no effect if not run in synchronous foreground. As we will see, this produces some unpredictable results.
3. Some policy types will only be effective when run in synchronous foreground. For example Microsoft's Disk Quota CSE disallows background processing (which also prevents asynchronous foreground processing). One might think that this would result in Disk Quota policy never being applied unless the computer had asynchronous processing disabled, which would be the case if it were not for something call ForceRefreshFG, which also produces results that might seem unpredictable.
4. It's also important to note that while some CSEs are generally documented to only apply policy in one mode or another, they may in fact be registered to run in both modes. For example, Microsoft's Software Installation policy processes in all three modes, but performs different actions in synchronous foreground vs. background/asynchronous foreground. While this policy type is not registered to require foreground processing, the features that only run in foreground do require it. However, because the extension allows background and asynchronous processing, the system is never forced into synchronous processing because of this policy type alone. This too can lead to unpredictable results.

Tip

From the above four situations, it should be clear that it might be best to avoid asynchronous foreground processing altogether. See "Configuring Synchronous Processing".

What's in a Name?

The name asynchronous is meant to indicate that the logon process executes concurrently with Group Policy processing, not that the Group Policy extensions process concurrently with each other. Interestingly the name foreground is a reference to the fact that during such processing the startup/logon splash window is presented and the Group Policy extensions have the opportunity to write status messages to this window. The window is in the "foreground". Some people have taken the fact that there is also a shutdown/logoff window, and that fact that there are shutdown/logoff scripts, to mean that foreground also a reference to shutdown/logoff. Although these windows may actually state that Windows is processing policy, this is in fact not Group Policy processing. No Group Policy processing occurs at shutdown or logoff (what would be the point?). Logoff and shutdown scripts are executed at this time, however such scripts are not Group Policy. Microsoft's Scripts policy only configures the registry to run scripts, but does not run them itself. This also explains why this extension runs in background refresh but scripts do not.

Forced into Foreground

A CSE that registers a requirement for foreground processing forces the computer/user into synchronous foreground processing, on the next foreground event. On other words if any one CSE is to be launched, but requires foreground processing, Winlogon will not launch that CSE, and will set the value ForceRefreshFG=1 into that CSE's section of the registry. If during the next startup/logon event, Winlogon sees this value for any CSE, it will initiate policy processing synchronously and thereby be able to launch the extension(s) that require it. This automatic mode switching leads to the generally undesirable effect of some CSEs applying policy only after a second logon or startup, or even at every other logon or startup.

Configuring Synchronous Processing

Windows 2000 and Windows 2003 Server computers process foreground policy synchronously by default. Windows XP processes foreground policy asynchronously by default. In order to enable synchronous processing (at startup/logon) on Windows XP, you must ensure that the following policy is enabled (and disabled/not configured on Windows 2000/2003):

Computer Configuration\Administrative Templates\System\Logon\
"Always wait for the network at computer startup and logon"

This setting ensures that policy completes before the startup/logon is completed. The change to the default setting on Windows XP was designed to speed up startup and logon processing. However, when performing configurations that must take effect before the end-user has access to his/her desktop, synchronous processing must be enabled.

Ordering of GPOs

When a CSE process its policy, it always process all GPOs that have settings applied. Winlogon gives each CSE a list of GPOs that have policy settings that may apply to the user or computer, depending on the context (i.e. the changed list). A list of GPOs that formerly had, but no longer have, policy settings is also provided (i.e. the deleted list). Technically, it's up to each CSE to decide exactly what to do with these lists. However, standard processing rules dictate that if the CSE is to execute any policy, it must execute all of its policy from each GPO in the order provided to it by Winlogon. This preserves GPO enforcement and other processing issues related to precedence. If only changed GPOs were ever processed independently, then merely changing one GPO would allow a low-level administrator to override higher precedence policy.

Policy Caching

Group Policy objects (GPO) neither download nor cache to network computers. A GPO is a combination of all of the settings in the Group Policy Template (GPT) and the Group Policy Container (GPC). The GPT is file system storage in SYSVOL, and the GPC is Active Directory data. The GPC information is read by Winlogon as it launches CSEs, and the GPT information is read by each individual CSE as necessary. However, given that often one CSE will run, and others will not - even though all may have settings in particular GPO - it should be obvious that downloading the entire GPO to workstations would cause a serious and unnecessary performance hit.

Since GPOs are never downloaded, they cannot be cached. This confusion around this subject is based on several issues. First, the fact that there are aspects of GPO processing that create cached data. For example Winlogon records a historical list of all GPOs that have been processed for all users, including all extensions that processed policy. This list contains no information about individual policy settings. Therefore it could be said that the GPC is cached, however the implications are substantially different than GPO caching.

Some individual extensions also record historical data. This information is used to perform policy removal. Microsoft's Folder Redirection is an example. Without this information it would not be possible to remove settings that were previously applied, since the removal often corresponds to an event such as the deletion of the entire GPO by an administrator, and revertible actions taken by CSEs will vary by each computer and/or user. Other extensions may independently cache data for other reasons.

Offline Behavior

When a computer disconnects from the network, and the domain is no longer accessible, policy is no longer processed. GPOs are stored in domains and without access to those domains, policy cannot be processed. If the user logs on with cached domain credentials, it's the same as if they had merely unplugged the computer from the network while on the domain - policy does not process. However, if the user switches to a local account, the computer/user account will then be subject to Local GPO processing. When on the domain, Local GPO processes first (at the lowest priority). When on a local computer account, Local GPO is the only GPO to process. If the computer is then accessible to a different domain, policy from that new domain is now processed - again following the processing of the same Local GPO.

Comments:

From wallets and bag [58.226.29.19] - 8/19/06 5:01 PM

From EricF [71.123.22.138] - 3/16/06 8:47 PM

From gpoguy - 3/1/06 11:02 AM

From Mohammed Sajid [61.95.192.104] - 2/28/06 11:18 PM

From SebastianP - 10/1/05 7:26 AM