- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
- Automatically mount an NVMe EBS volume in an EC2 Linux instance using fstab - Mon, Feb 21 2022
Group Policy caching is enabled by default in Windows 8.1 and Windows Server 2012 R2; however, contrary to what I have read in some blogs, it probably will be inactive in most environments. The benefit of this feature is that it can speed up the logon process because the Group Policy engine loads policy information from a local cache (Microsoft calls it a datastore) instead of downloading it from a domain controller.
How to disable Group Policy caching ^
The tricky part about Group Policy caching is to understand when it is used and when it is not. The new Group Policy setting “Configure Group Policy Caching,” under Computer Configuration > Administrative Templates > System > Group Policy, allows you to disable Group Policy caching. If the policy is not configured, caching is enabled by default.
Group Policy Caching
However, this policy alone doesn’t determine if the Group Policy cache is actually read on the client. We need a little excursus about Group Policy processing to understand when caching is active and when it is not. That is, you have to understand foreground/background processing and synchronous/asynchronous processing.
Foreground/Background processing ^
Foreground Group Policy processing comes into play when a computer starts or shuts down and when a user logs on and off. Background processing takes place every 90 minutes for domain members and every 5 minutes for domain controllers. (These time intervals can be changed with “Set Group Policy refresh interval…” under Computer Configuration > Administrative Templates > System > Group Policy.)
The terms might be a bit misleading. You just have to keep in mind that background processing happens while the user is logged on, and foreground processing happens while the user is logged off. Here is a good overview that explains the concept.
Synchronous/Asynchronous processing ^
Synchronous processing is sometimes confused with foreground processing. Synchronous processing means that policies are processed in a fixed order relative to other processes. This is sometimes necessary if policies depend on each other or on other processes.
By contrast, asynchronous processing means that policies can occur on different threads simultaneously. During startup, this means that policies can be applied before the logon screen appears, and it is possible that not all policies are applied when the logon process is finished.
The advantage of asynchronous processing is that the user doesn’t have to wait until all policies are processed. The downside is that this can have unwanted effects—for instance, a Folder Redirection that the user needs is not yet available after logon. This is why some policies require synchronous processing.
It appears that, in Windows 8.1, only Folder Redirection and Software Installation policies need synchronous processing. In previous Windows versions, Drive Mappings and Disk Quotas also required synchronous processing. However, I didn’t find official confirmation for this claim. We will see that this is important with regard to Group Policy caching.
It is also important to note that you can force the Group Policy engine to always use synchronous processing during startup and logon with the setting “Always wait for the network at computer startup and user logon” under Computer Configuration > Policies > Administrative Templates > System > Logon. Notice that servers always use synchronous Group Policy processing.
Synchronous Group Policy Processing
When the Group Policy cache is written ^
The Group Policy cache is written in background mode, in asynchronous foreground mode, and when you don’t disable Group Policy caching with the policy mentioned above.
Group Policy Caching - EventViewer 5216
You can verify this by running gpupdate /force on the client and then looking for the event IDs 4216 (starting to save policies to local datastore) and 5216 (successfully stored policies to the local datastore) in the Group Policy event log under Applications and Service Logs > Microsoft > Windows > Group Policy.
You can also check the C:\Windows\System32\GroupPolicy\Datastore folder where the Group Policy cache is stored.
Group Policy Cache - File Explorer
When the Group Policy cache is read ^
The Group Policy cache is only read in synchronous foreground mode. This is what the help text of the policy explains. However, this is only half of the story.
Some bloggers seem to conclude that if your force Windows into synchronous mode with the policy mentioned above, then the cache is always used when you restart the machine and log on. According to my tests, this is not the case.
Whenever the Group Policy cache is read, an event log is created with the event ID 5217 in the Group Policy event log. The corresponding message text is “Successfully loaded policies from the datastore.” I never saw this event log with enabled synchronous mode, after a reboot, on a freshly installed Windows 8.1 computer.
Group Policy Cache - Event ID 5217
So when is the cache actually read? It always happens when one of the above-mentioned Client Side Extensions (CSEs) come into play: Software Installation, Folder Redirection, Disk Quota, or Drive Mappings. I only tested Folder Redirection and Drive Mappings, but I guess the other two policies behave the same way.
Thus it appears that even though Drive Mappings and Disk Quotas no longer require synchronous processing in Windows 8.1 (that is, they can now also run in asynchronous background mode), they are still being processed synchronously in foreground mode and thereby trigger the Group Policy engine to read the cache.
Slow link value and timeout value ^
The Group Policy for configuring the cache allows you to set a slow link value and a timeout value. As I understand “slow link value”, whenever the cache is read, the Group Policy engine contacts a domain controller to measure the link speed. If the speed is slower than the value configured here, the link is considered to be slow; then, only certain policies, such as the security policy, are later cached in asynchronous background mode. Other policies, such as Folder Redirection, are then not downloaded. The help text is not really clear, but this is the only way I can make sense of the slow link value setting.
The timeout value is the time interval Windows waits to connect to a domain controller. If this value is exceeded, the user is logged on with cached credentials, and the contents of the Group Policy cache are not read.
Please note that this part about the thresholds is only guesswork. If you have better information, please let me know.
To sum up ^
Group Policy caching is supposed to speed up the sign-in process for policies that are processed in synchronous mode during logon (Software Installation, Folder Redirection, Disk Quota, and Drive Mappings). The point here is that the cache comes into play only when synchronous processing is required in foreground mode. This makes sense because synchronous processing can slow down the logon process significantly. If you only use Group Policy settings that can run in asynchronous foreground mode, then the cache is not used even if you enabled synchronous Group Policy processing.
Did you try Group Policy caching? Please let me know if you got the same results.