A while back I wrote a post describing the new Group Policy caching feature in Windows 8.1. As I mentioned in the post, this feature was designed to speed up GP processing when “synchronous” foreground policy processing was occurring. Synchronous foreground processing, prior to Windows 8.1, happened during one of a few different scenarios:

1. The first time a new user logs in to a machine with a new profile, user GP settings process synchronously.

2. If you had enabled the policy under Computer Configuration\Policies\Administrative Templates\System\Logon\Always wait for network at computer startup and user logon, then policy, both machine and user, will always run synchronously. This was the equivalent of turning off the XP-introduced “Fast Logon Optimization” feature.

3. If one of four Client Side Extensions (CSEs) were implemented in a GPO processed by a computer or user, that required synchronous foreground processing to work. These included Folder Redirection, Software Installation, Disk Quota (found under Admin Templates) and GP Preferences Drive Mapping.

Now, when 8.1 shipped and introduced caching, my immediate thought was that if #2 and 3 above were true, then caching would kick in. Not so fast. In fact, if you have enabled “always-on” synchronous processing using the policy in #2, then caching does not actually kick in at all. I confirmed this with Microsoft as “by design” in Windows 8.1. That means that caching only kicks in when #3 is true. Namely, there’s a GPO processed by the computer or user that has requested that the next boot or user logon run synchronously so that that CSE may do it’s job. What’s more interesting is that, in Windows 8.1 two of those four CSEs no longer *require* a synchronous foreground processing cycle to run. Disk Quota (does anyone actually use this policy?!!) and GP Preferences Drive Mappings no longer require a foreground synchronous processing cycle to run.

What that means is that the only circumstances in which GP caching will kick in on Windows 8.1, is when the computer or user needs to apply Folder Redirection or Software Installation policy. In other words, almost never!

I sort of get this, but I sort of don’t. A lot of shops implemented the “Always wait for network…” policy back in XP days as a sort of catch-all to random GP processing issues. Even though this policy really only affects the CSEs I mentioned above, it was viewed as Band-Aid to “heal all wounds”. The caching feature in Windows 8.1. is meant to mitigate the performance issues that synchronous processing introduces. There’s no doubt that caching, as a technology, introduces complexity to, in this case, GP processing, but I admit that doing all that work to introduce caching, only to have it apply to this very small corner case, is puzzling. Why not implement it for clients when the “Always wait for network…” policy is enabled, where it will do some good. Because, as I mentioned in my original blog post, there are some downsides to introducing caching in terms of the latest policy not applying if it hasn’t been updated to the cache, then I can sort of understand their desire not to do this. But, at the end of the day, given limited resources, it seems like an awful lot of development effort to go through for relatively little benefit, and I’m left feeling that this feature, while interesting, is irrelevant…

Darren