- 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.
Michael- I think you misunderstood what I wrote, but in any case, you may want to test again. You write, “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.” This isn’t the only time the cache is used. In fact, any time synchronous foreground processing runs, it will be used. This was confirmed in a set of emails several of us Group Policy MVPs had with the Group Policy product team. So, your conclusion, is unfortunately wrong.
Darren, are you referring to the policy that determines whether processing is synchronous? I tested it and the Group Policy cache was definitely not read when enabled. Did you test it yourself?
I’ll make a couple of points here Michael.
1. This feature was built by Microsoft *specifically* to speed foreground synchronous refreshes, as my blog pointed out. A synchronous refresh can happen through one of 3 different mechanisms. First, because a CSE asks for it. Second, because you force it through the “Always wait…” policy and Third, because you set the flag using gpupdate /sync. Each of these will trigger the cache in 8.1. In my testing, I used gpudate /sync to force a synchronous foreground refresh. But you can easily verify that using the “Always wait” policy also sets that flag (folks can use my GP Health Reporter from http://www.sdmsoftware.com/freeware to see previous and next flag settings). The fact that it didn’t work for you doesn’t automatically mean it’s not supported, esp. given the fact that this is beta code. In addition, you need to actually verify that the sync flag has been set for both computer and user before you draw your conclusion. It’s easy to *think* it is when it’s not, in my testing.
2. If you’re going to write a derivative blog posting, which this clearly is, since you reference both my original blog and Alan’s, then at least have the courtesy of consulting with me about the issue you’re seeing before referring to me as “some bloggers” and saying that I’m wrong, esp. given that I might have a little bit more “inside information” than you and that you know me, personally. That’s just bad form in the effort to get some page views, which happens far too often.
Darren, I just tried it again in a different test environment and got the same results. Enabling the “Always wait” policy is not enough for forcing the Group Policy engine to read from the Group Policy cache. At least there is no indication in the even log. I verified with gpresult that the policy was applied. It doesn’t matter if you reboot with a changed or an unchanged GPO.
Gpupdate /sync appears to always force the cache to be read. Sometimes I also saw the 5217 event id on a freshly installed system when I rebooted right after I enabled the “Always wait” policy.
Of course, it is possible that the feature is buggy or incomplete. It is also possible that not all product managers know all the details yet. However, since many admins will try this feature with the current release, I feel it is important to test by yourself and then publish your findings.
Michael-
You may be 100% right. Talk to me when the *release* product ships. All I can tell you is that is NOT how this feature is supposed to work. Given that this is beta code, let’s see how it ends up.
Darren
Michael–I wanted to officially and publicly apologize for my rant above. I got way too defensive and, given that I’ve been doing this for so long, I should know better. My bad and I’m sorry. I went back and re-read my posting that you reference above and I still stand by it. What I said in that post–that GP caching was developed specifically to speed GP processing during foreground synchronous cycles and that foreground sync can be triggered by the 3 methods I mentioned, is still all true. But I should have been more helpful in my response than I was. The fact that you experienced no caching with the Sync policy set is definitely an issue. I went and dug into the GP debug logs myself on this and sure enough, when that policy is set, the GP engine is treating it as if it were a Server SKU (i.e. server SKUs always process synchronously and never cache). Now, why this is happening is a mystery to me because probably the vast majority of scenarios where caching will help reduce startup and logon times are exactly for shops that use this policy–since it was widely used since XP days. So, I’ve lobbed a question about this to MS to see if this truly an artifact of the Preview release (I hope so) or the way it will be in RTM (I hope not). In any case, I am again sorry and will do better next time.—Darren
Darren, we all have a bad day sometimes. 🙂 Your findings are interesting. Maybe it is indeed because the GP engine is incomplete in the preview version. However, for me the behavior somehow makes sense because usually it is not because policies are processed in a certain order that slows downs the logon process. Often it is because during synchronous processing the GP engine has to wait for a server, for instance until the drive mapping on an unresponsive file server is finished or software is downloaded. Thus perhaps it makes sense to use the cache only for certain policies during synchronous processing and the CSEs mentioned in the articled are notorious for slow processing. Caching can cause a lot of trouble and should only be used if the benefits are significant. Of course this is all speculation. So let’s wait until the RTM.
Great article! Can you please tell me what is the corresponding registry entry for this policy. Thanks 🙂
Great article. I had been running into some walls testing 8.1 recently. This answered (and solved) some of those issues.
Here is the key for the policy Kapil => HKLM\Software\Policies\Microsoft\Windows\System!SlowlinkDefaultToAsync according to http://www.microsoft.com/en-us/download/details.aspx?id=25250
Thanks,
.bill
Just to follow up on this. Now that RTM is available, I can confirm that Microsoft, in it’s infinite wisdom, decided that if the “Always wait for network…” policy is enabled, even though that forces synchronous foreground processing, it doesn’t enable the cache. I asked specifically about this and was specifically told it wasn’t going to change in RTM. I also indicated that this was, in a word, lame, considering that this policy is probably 90% of the reason that synchronous foreground actually happens. So, it appears that in the 5-10% of the cases where sync foreground is enabled in 8.1, the caching will work as expected. So basically, hardly ever 🙂
Darren, thanks for the update! At first, I found it also strange that the cache comes to play only in rare cases. However, caching can also cause a lot of trouble. Thus it makes sense to only utilize the cache if policies are involved that can slow down the login process significantly.
Great post. This solved some of those problems. Thanks 🙂
so in the background processing cycles has anyone tested the download behavior? Is it doing any kind of delta based on timestamp or ?, or is it a full re-download of all applied policies every 90 minutes for a feature that is almost never used???
thanks….great post