Recently a fellow Group Policy MVP asked about whether it was possible to control the order of Client-Side Extension (CSE) processing in Group Policy. The CSEs are the DLLs that do the real work of policy processing in GP. They reside on all Windows client machines and each policy area (e.g. software installation, folder redirection, security, admin templates, all the various Group Policy Preferences areas, etc.) has a CSE that does it’s bidding.

With the exception of Admin Templates, which always runs first in the CSE processing order, the rest of the CSE run in the order that they are registered in the registry under HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentversionWinlogonGPExtensions. Each registry key under that key contains the registration information for each CSE. And each CSE has a GUID that identifies it (the name of the key). These GUIDs are simply alph-numerically sorted and that is the order in which they run during a given GP processing cycle. So, I thought, well, what happens if you change the GUID on a particular CSE? Will it change the processing order?

As a matter of fact, it does! Prior to messing around with it, 802.3 policy would run just after EFS Recovery policy, as an example. But I mucked with the GUID of 802.3 to move it just ahead of EFS Recovery in the registry key sort order, did a gpupdate /force and lo and behold, the GP processing order showed as changed in userenv.log (this was an XP system I was testing, just because it was easy). Pretty cool.

So, while this is not something that you would want to do everyday, it was a useful thought experiment to see if it would work. The downside to changing these GUIDs is that they are considered “well-known” GUIDs, and other stuff, like Group Policy history and probably a few other things I’m missing, are keyed off of them. So changing them runs the risk of breaking some other behavior. But, at the end of the day, it is THAT simple to change CSE processing order!