In a previous blog posting, I talked about the gpupdate command-line utility for forcing a GP refresh on a local system. I briefly mentioned the /sync parameter, which doesn’t actually do a GP refresh at all, but instead, just marks the next foreground GP refresh (either a machine restart or user logon) cycle as “Synchronous”. I’ve talked a lot lately about Synchronous policy processing as it relates to boot and logon performance, but how do you know if synchronous policy processing is happening, aside from using gpupdate /sync to force it to happen. Well the good news is that our Group Policy Health Reporter freeware utility actually reports out the state of both the last foreground processing cycle as well as the next one, so you can not only see if synchronous processing happened in the past, but whether it’s going to happen during the next machine restart or user logon. I’ve created a quick video that demonstrates how this works. I hope you enjoy it and find it useful!
Transcription
I’m going to do a quick demo of the GPUpdate Sync Command along with one of our freeware utilities that you can see the effects of Synchronous GP Processing. So let me bring up the Group Policy Health Reporter.
This is a freeware utility that we provide on our website, and let me just go ahead and bring that up here. And if you’re interested in downloading this utility, if you just go to our website on the Freeware page, you’ll find the Group Policy Health Reporter Product right at the top and you can register to download that. Now let’s go ahead and look at the Health Reporter. I’ve run the Health Reporter on this machine and one of the pieces of information that it returns is for both the computer and the user, it essentially returns the Foreground Refresh Mode, the last time Policy Processing happened, and the next Foreground Refresh Mode. So right now the previous Foreground Refresh was set to Asynchronous, the reason was basically, No Need for Synchronous. There was nothing that needed Synchronous Processing. The same holds true for the next Foreground Processing cycle. However, what I’m going to do here is I’m going to go in and run GPUpdate Sync. And it’s asking me if it’s “Okay to Restart?” because it’s trying to flag enforce a reboot on this machine in order for the Synchronous Processing to take effect. I’m going to say “No” to Restart and “No” to Logoff. Of course they won’t take effect until either a User Logoff or a System Reboot. But what I’m going to do is reconnect to this machine and what you see here now is that the next Foreground Refresh Mode is set to Synchronous, and the reason is that I forced it Forced to Sync Refresh. So essentially what happened here is by using the GPUpdate Sync Command, I’ve forced the next Policy Processing Cycle to be Synchronous. And I can see that very easily through my GP Health Reporter. I can also show it on the Pre-User side as well if I chose to do that. And that’s the end of this demo. Thanks for watching.
Darren
Trackbacks/Pingbacks