How things work: Group Policy Caching

The release of Windows 8.1 and Server 2012 R2 introduced a new Group Policy concept called Group Policy Caching. Its purpose is to reduce the time it takes to perform certain scenarios for synchronous foreground Group Policy refresh. Here’s the drawback: for every Group Policy update interval, Group Policy Caching will download, and store a local copy of all Group Policies that apply to the computer or user. Even if no changes have been made to the Group Policy, and no local Group Policy Client Side Extension (CSE) is installed for the settings, the behavior will remain the same.

Here’s the issue as it relates to Specops Password Policy. Leaving the Group Policy Caching in its default state will download the password dictionaries and hash lists stored in the Group Policy. This is not an issue from a security perspective, but obviously an unnecessary network operation. These lists, which can be hundreds of megabytes in size, are copied at every Group Policy interval to the computers.

Our recommendation is to disable caching on clients if dictionaries are being used. Disabling the feature can be done using Group Policy from:

Computer Configuration\Policies\Administrative Templates\System\Group Policy

The actual setting is called Configure Group Policy Caching and it should be set to Disabled.

Once the GPO hits the clients, any background caching will stop.

Group Policy Processing 101

To further understand the issue, one needs to understand the different flavors of Group Policy processing. There are two main types of processing: foreground and background – both of which exist for User and Computer policies. The foreground processing also comes in two flavors, asynchronous and synchronous.

Foreground Group Policy processing happens when a computer starts, or when a user logs on. Every Group Policy processing thereafter is processed in the background. Back in the ancient days of Windows 2000, every foreground Group Policy interval was synchronous. When the computer booted, the logon dialog only displayed after the full foreground Group Policy processing was completed. The same applied for the user logon. The desktop was presented only after the full foreground processing was completed for the user. This made the process of booting and logging on to a Group Policy managed computer slow.

When Microsoft introduced Windows XP, the concept of foreground asynchronous processing was introduced. This made foreground processing work like background processing – Group Policy processing did not need to be complete to display the logon screen, or the user desktop.

So, why does foreground synchronous processing still exist?

There are certain scenarios where Windows will revert to the Windows 2000 foreground synchronous processing. The following contains the triggers for foreground synchronous processing on operating systems affected by Group Policy Caching (i.e. Windows 8.1/Server 2012 R2 system or later):

1. When a computer boots after joining a new Active Directory Domain
2. The first time a user logs on to a new computer
3. The setting Always wait for the network at computer startup and logon is enabled.
4. The command GPUpdate /Sync (or similar tool) is executed.
5. GPOs with either Software Installation (not Specops Deploy), or Folder Redirection settings, where at least one background Group Policy interval has passed. These two Group Policy extensions can only run without a user being logged on, and therefore require foreground synchronous processing.

Now, let’s map how Group Policy Caching relates to the above scenarios:

• (1, 2) Examples one and two are first-time events. Background processing that caches Group Policy could not have taken place prior to this, so they cannot be reading any cached objects.
• (3) Configuring the policy to Always wait for the network forces foreground Group Policy to be synchronous. But, this setting also implicitly deactivates the Group Policy Caching feature.
• (4) Forcing a manual sync e.g. “GPUpdate /Sync”, which requires local administrative privileges, will force the cache to be used.
• (5) Foreground synchronous processing, triggered by the Software Installation or Folder Redirection Group Policy Client Side Extension, will use the cache.

In most environments, foreground synchronous processing is a rare occurrence. But, the benefits of Group Policy Caching are even rarer. Aside from an administrator enforced sync, the only real scenario is when Group Policy Software Installation, or Folder Redirection Group Policies, are altered during the next boot or logon.

Group Policy Caching

With the knowledge of the types (foreground synchronous, foreground asynchronous and background) of Group Policy processing, we can now better understand the Group Policy Caching feature.

To start with, it is important to understand that caching does not in any way introduce any offline capabilities to Group Policy. The computer must be online and have full access to a Domain Controller for Group Policy to be processed, just as it has always been.

When Group Policy Caching is used, only one thing changes: during the foreground synchronous processing, the files are read from the local Group Policy Cache, instead of SYSVOL. Rather than finding the Group Policy files in a path like this \\acme.com\sysvol\acme.com\Policies, the following local directories will be used:

User GPO Settings – %localappdata%\GroupPolicy\DataStore

Computer GPO Settings – %windir%\System32\GroupPolicy\DataStore

GPC (AD/LDAP part of a GPO) related information can be found under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\DataStore. The specifics of this part are undocumented, but reading the operational log for Group Policy indicates that the AD calls do not take place when the cache is used.

This process is a much faster than reading all the Group Policies over the network, especially if there is a slow connection to the Domain Controller. Remember, the cache is used if Folder Redirection or Software Installation is applied. In the latter case, there is great chance that reading the Group Policy is not the time consuming action, rather it’s downloading and installing software since the installation packages are (normally) located on a server. The end user will still be blocked from accessing their desktop until the Group Policy is finished.

Drawbacks of Group Policy Caching

How is the Group Policy cache populated? There must be some mechanism that downloads the files. This is the main drawback of the Group Policy Caching feature; for every single background Group Policy processing interval, every single file from every Group Policy that applies is copied to the local cache, regardless of whether the GPO has changed or not. Everything from every Group Policy affecting the user or computer is downloaded every 90 to 120 minutes. If the scenario is to support users and computers behind slow network connection, the cost of the occasional faster foreground processing comes with increased network traffic over the slow connection.

Another drawback: if a downloaded cached Group Policy changes between being updated in a background processing, and a following foreground processing where the cache is used, the cached version is applied. The foreground processing does not update the local cache, and the computer must perform another reboot/logon foreground processing before the proper settings are applied.

The last drawback is more of an implementation flaw. Group Policy Caching does not evaluate applied Group Polices the same way as the actual Group Policy engine. This is important to understand when it comes to the effect on Specops Password Policy as the Caching feature downloads Group Policies it should not download. This is a simplified pattern of a Group Policy interval when determining what Group Policies to apply.

1. Find all GPOs that that are linked to the domain; or any OUs that the user/computer resides in; or any parent OUs.
2. Compare the list of GPOs with the security settings of each GPO – does the user/computer have proper permissions for the GPO to apply?
3. Evaluate WMI filters. Any GPO that has a filter that does not return true (e.g. any WMI objects) is not included. For example the following WQL as a WMI Filter would make sure that the GPO is only applied on Windows 10 computers, “SELECT * FROM Win32_OperatingSystem WHERE Version LIKE “10.%” and ProductType=”1″”.
4. Cross-check the list of GPOs for Client Side Extensions on the computer that can process the settings. You can see all installed Client Side Extensions in the registry from: “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions”. GPOs that don’t have a corresponding Client Side Extension are removed from the list of GPOs to process.

These four steps contain the Group Policy Objects that will be processed by Windows. However, when the Group Policy Caching determines what to download, it won’t work the same way. The evaluation process is stopped after the second bullet, downloading all the content, even from GPOs that never will be used due to the lack of a Group Policy Client Side Extension, or WMI filters that does not evaluate to true. While the WMI filters can be dynamic in theory, with different results every time they run, the lack of a Client Side Extension means that the corresponding policies are never processed, nor should they, as the Group Policies are evaluated on-the-fly during the password change on the Domain Controllers. This scenario is extra interesting when it comes to Specops Password Policy and Group Policy Caching as that is exactly what happens.

Group Policy Caching and Specops Password Policy

How does all of this relate to Specops Password Policy? Specops Password Policy does not have, nor does it require, a Group Policy Client Side Extension. The processing and evaluation of Group Polices takes place in the Specops Password Policy Sentinel on the Domain Controllers.  After installing the Sentinel on the AD Domain Controllers, there isn’t a need to deploy anything to the clients and servers. The Specops Password Client that can be deployed is not a Group Policy Client Side Extension, but rather an optional client that adds extra features to Windows, such as information on unfulfilled password policy rules during a password change, and a link to our password reset web page.

In theory, Group Policy caching should not have a single thing to do with Specops Password Policy. Unfortunately, due to the discrepancies between how Group Policies should be used, and how Group Policy Caching calculates what to download, the Specops Password Policy GPOs that apply to a user will be downloaded every Group Policy interval. Normally this wouldn’t cause any issues as it is only a few kilobytes of data. But, if large dictionaries are being used in the GPO, this can change. Imagine a 100 MB dictionary is imported into the GPO. This file would be downloaded every group policy interval causing a huge amount of network traffic.

Our recommendation is to disable caching on clients if dictionaries are being used. In fact, as I’ve demonstrated its slim benefits in this blog post, it might be a good idea to disable Group Policy Caching regardless.

Disabling the feature can be done using Group Policy, the setting is located here:

Computer Configuration\Policies\Administrative Templates\System\Group Policy

The actual setting is called Configure Group Policy Caching and it should be set to Disabled.

Once the GPO hits the clients, any background caching will stop.

Group Policy Caching and other Specops Software Group Policy based products

Although the focus for this post is to describe the effects of Specops Password Policy in combination with Group Policy Caching, let us have a quick look at how it can impact other Specops products.

Specops Password Reset, Specops uReset, Specops Password Sync, and Specops Authentication

The Specops Password and Authentication Management products are configured using Group Policy. As with Specops Password Policy, there is no need for a Group Policy Client Side Extension on client computers, neither desktops nor servers. Since the designers of the Group Policy Caching feature did not account for the existence of a local Group Policy Client Side Extension when determining what to download, there is a discrepancy between the Group Policy Caching policy result and the Group Policy engine policy result.

Specops Deploy

As Specops Deploy manages software during background processing, it removes the need to do foreground synchronous processing to manage software using Group Policy. Specops Deploy automatically detects, on a granular deployment level, if a package is configured to only install in the foreground. The next boot/logon will force synchronous foreground processing, reducing the amount of foreground processing to the absolute possible minimum.

The configuration files used by Specops Deploy will be cached if the Group Policy Caching feature is used, but the benefit is minimal as the actual software needs to be downloaded anyway.

Specops Inventory and Specops Command

If Group Policy Caching is enabled during foreground synchronous processing, the Specops Inventory configuration files will be downloaded. As most work done by Specops Inventory is performing actual inventory, the benefit is minimal.

Specops Command has a similar story as Specops Inventory, the cached files will also include the Scripts to execute, but if the scripts are heavy duty, the time executing scripts will consume much of what is gained. Also, similar to Specops Deploy, Specops Command is designed so that the execution can be performed in the background processing cycles.