6

I have been working on speeding up network logins. As part of this process I'm disabling the 'always wait for network' option.

This isn't inherently a problem, but I would really like to be able to pop up a dialog along the lines of "we see your drives aren't mapped / your folders haven't been redirected. please log off and back on to complete the process". This would cut helpdesk calls tremendously.

Is there a good way determine when group needs to run synchronously? A flag in the registry, etc?

Tim Brigham
  • 15,545
  • 10
  • 75
  • 115

2 Answers2

7

My take is "Group policy needs to be run synchronously".

Seriously.

The default in Windows 2000 was to run all Group Policy (computer and user) synchronously. Microsoft had materials in their "Official Curriculum" back then that even describe asynchronous policy application as potentially unreliable.

You can change this default behavior by using a policy setting for each so that processing is asynchronous. This is not recommended unless there are compelling performance reasons. To provide the most reliable operation, leave the processing as synchronous.

When asynchronous computer policy application became the default in Windows XP I found that it was unreliable and non-deterministic. From that point on I've been forcing policy application to be synchronous and I've been happy with the results.

I'd like logons to be faster, but at the same time I need things to be reliable. Reliability trumps speed to me.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • Evan, I agree with you. I'm the one that set specified the synchronous policy settings when I came on board about 5 years ago. I'm not the one making this decision. – Tim Brigham Jul 11 '14 at 15:50
  • 1
    @TimBrigham - Understood. I'd take the decision to management: Do you want reliability or "speed"? Group Policy processing is much more reliable when it's applied synchronously. Your increased helpdesk calls are evidence enough of that lack of reliability. Building some kind of "shim" to "prop up" the poor reliability performance of asynchronous policy processing is, in my opinion, fighting a losing battle and throwing good time (and money) after what will ultimately be bad results. – Evan Anderson Jul 11 '14 at 16:30
2

Found a solution to this issue, without needing to go with a full blown synchronous run. Gotta love procmon.

The registry keys HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\Status\GPExtensions\{guid}\ForceRefreshFG are set to 1 whenever a GPP item needs a synchronous run for the currently logged on user. With a little bit of scripting wizardry we at least have another option.

Tim Brigham
  • 15,545
  • 10
  • 75
  • 115