Understanding Group Policy Behavior When a Computer or User is Moved in Active Directory

A question came up on Twitter the other day related to how Group Policy behaves on a given client, when you move either the computer or user account in Active Directory. As we know, the Group Policy that applies to a computer or user is a function of what GPOs are linked to the container(s) path that the computer or user object are part of. Let’s say you move a computer account from the Marketing OU to the Sales OU. That means that the GPOs that apply to that computer will potentially be different. That said, what is curious is that the Group Policy engine doesn’t actually detect the move of the object right away. There is some caching of object location that goes on within the Group Policy engine. That was the gist of the Twitter conversation–why does this happen and how can I work around it?

To cut to the punch line, if you issue a gpupdate /force command on the machine in question–this will trigger the machine to update it’s cached AD location to reflect the AD object move, and process the correct policy immediately. I spent some time digging around the gpsvc.log to see if I could understand what was happening in this case. After comparing it to a refresh where I just issued a regular old gpupdate, I saw the following command, which explained why gpupdate /force worked:

As this shows, the GetUserNameEx call happens when you use the /force switch on GPupdate. What’s interesting is that it doesn’t ever seem to get called otherwise. As an experiment, I wanted to understand how long it takes GP to update the object’s location naturally, and what happens when that does get updated. In my testing, it seems that it takes one background refresh interval to pick up the object move normally. In other words, on my Windows 10 test machine, approximately 90 minutes went by before the machine realized it was in the new location and updated it’s cache. And the cache doesn’t appear to be persisted to disk. I used Process Monitor from SysInternals to view what was going on when I did a gpupdate /force and while several registry values that seem to be related to the computer (or user’s) DN were read and written to–they appear to be downstream of the cache itself. For example, I tried artificially modifying the following registry location, which was read and written to in Process Monitor:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Distinguished-Name

But instead of taking the value I wrote here, this value was essentially overwritten during the next forced refresh. My guess is that this cache is held in memory and only updated during a regular background refresh, whenever that happens to occur.

I hope this was a helpful discussion and takes some of the mystery out of GP location caching.