The title of this blog tells it all. I got asked the question–what happens to GP processing when a client machine isn’t on the network and can’t connect to it’s domain Domain Controllers (DCs)? Does policy get removed? Does it just stay where it is? Can I temporarily override policy by editing the local GPO? All of these are great questions and beg for an answer. Before I answer them all, a little background on GP Processing.
The Phases of GP Processing
The Group Policy engine basically has two phases it goes through to process GPOs. This is true regardless of whether it’s doing foreground processing (i.e. at boot or user logon) or background processing (either automatically or initiated by a user via gpupdate). These two phases are:
- Core
- CSE
At a high level, the core phase is where the client (AD computer or user) contacts it’s closest DC, figures out whether it is across a slow link, enumerates its place in AD and then queries AD to figure out which GPOs apply to it. Then, it queries those GPOs to figure out what Client Side Extensions (CSEs) should be run. All of that happens during the core phase. If any of these steps fail outright during the core phase, then all GP processing grinds to a halt. If it succeeds, then it’s on to the CSE phase.
Once the core phase is complete, the CSE phase kicks in. This is where the real work gets done. During the CSE phase, each implemented CSE (based on the list from the core phase) fires up and processes all GPOs that implement that CSE, in the order in which the CSEs are registered (for the most part) in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. If a given CSE fails to process a GPO that implements that area, and the failure is fatal, that CSE will bail out but the rest of the CSEs will generally continue processing. So a single CSE failure is not as dire as a core failure to overall GP processing.
When No DCs are Available
So, what happens when no DCs are available? This can commonly occur if the machine (e.g. a laptop) is off the corporate network, or network issues prevent the machine from successfully connecting to any DCs. During the core phase of processing, when the machine (or user) goes to resolve itself in AD, it will make 4 attempts (Windows 10) to contact a DC to get it’s account information. If it fails to do that, it will generate event ID 7320 in the GP Operations Event Log, as shown here:
At the point of the failure, GP processing will end, without attempting to run the CSE phase. Because of that, no GP settings that are currently in place, will be impacted. No existing settings will be removed, nor will any new settings be added. If the CSE phase never runs, then no GP settings changes can take place. This is a good thing, since you would not want a user to simply be able to disconnect the network cable from their machine to be able to get around GP enforcement…right? 🙂
Now the final question I asked above was, “Can a user circumvent policy that is currently in place, if they are off the network and can’t process policy?” This is a more complicated scenario for a number of reasons. First of all, if you are able to “edit” local policy (e.g. by modifying the local GPO) then the assumption is that you are an administrator on the box and therefore really all bets with respect to GP are off. With those rights, you can edit the registry directly to simply remove policy settings at will.
That said, it’s worth knowing what happens when you try to edit the local GPO while a machine is offline. And of course, because it’s Microsoft and it’s Group Policy, the answer is…it depends. Specifically, if you try to edit areas of the local GPO that implement actual policy settings files in the local GPO’s file system (i.e. within c:\windows\system32\group policy) then those settings are in effect “cached” in the local GPO without being implemented on the system (i.e. until a DC becomes available). So if I try to set, for example, an Administrative Template setting to a different value within the local GPO, than has been set on the machine via domain policy, it will simply be ignored, because those Administrative Template settings, even within the local GPO, are processed by the Admin Templates CSE and won’t run when the machine is offline from the DC. However, and this is where it gets tricky, there are some settings in the local GPO (namely those under Computer Configuration\Windows Settings\Security Settings) that are not stored in the file system, but, when you edit them, they will make changes to the computer’s configuration directly, at that moment, and don’t rely on a GP processing cycle to be successful. Those settings however, if they’ve been implemented at the domain level, cannot be undone in the local GPO (they are actually grayed out in the GP Editor UI). But if you find a security setting that you wish to enable in the local GPO, even when the computer is offline, and it hasn’t been enforced from the domain, you will be able successfully edit and apply that setting to the machine directly, while the machine is offline from a DC. This is a subtle, but important point to keep in mind.
So with all this complexity in mind, the bottom line is that when a machine is off the network, by and large all settings will remain in place until the next time a DC becomes available. Until then, just make sure your users can’t monkey with their local machines.
Darren
Darren,
Thanks for this, I recently had questions in this very arena. You’ve addressed all but one.
Will the client continue to try and find a DC, on the refresh schedule? (every 90 minute + 0-30)?
I have a group of GIS users, that have their screen flicker and pause whenever Group Policy is updating, and they’ve asked me about it.
Hi Joe. Yes, GP will continue to try to refresh on it’s normal background cycle. Not sure the flicker would result from this attempt but I suppose it’s possible ;).
So let say the machine has hit the 90 minutes and tries to update but can’t because it is off the network. 10 minutes later it is back on the network. Will the machine retry then or wait another 80 mins (80 + 10) ?
John-
Since about Vista, I think, GP will retry when it detects that the network has had a state change. So yes, it will retry immediately if GP failed during the last background refresh.
That is very interesting about the screen flicker.
We are using Windows 10 Enterprise LTSB and we have a number of users saying their screens flicker and we have managed to witness this.
Looking at the event logs it is at the exact same time that GP does its refresh.
Could this be a bug somewhere?
Screen flicker can definitely be a by-product of GP refresh, in general. There is part of the GP refresh cycle that triggers “Window Messages” in Windows so that running applications know that GP has refreshed. Frankly, this has been an artifact of GP in Windows since it came out. It does seem worse/more noticeable in certain situations, but I’m not sure what it is that makes it so.
very interesting information, thanks for sharing.
Question: How can I tell GPUPDATE where to go to find the DC? in the event that you cannot find it due to an incorrect DNS resolution, as well as by IP if I arrive at the DC. I clarify for the doubts that I am trying to do it connected to a VPN
So, if an attacker gets Admin on the box (laptop off network) and turns off defender and then adds a registration key to change a setting that is normally in GP like turning on SMBv1 then that will be on until the connectivity to the domain returns and the GPO responsible for that is reapplied, yes!?
Jesse- yes, if someone has admin on the box, they can do pretty much whatever they want, but at that point, on or off the network, GP is pretty useless ;).
Hi Darren,
Thanks for this article as it has been causing us some issue for time because of proxy settings being captured and overwritten by the VPN client, then returned when the user disconnects from the VPN.
The issue being that any GPO settings for the same values don’t get applied because of VPN client enforcement and the client never receives those changes because the GPO doesn’t apply when the user is offline.
MS should have a way around this for such situations, but we are looking to have to use a script to apply the required settings now, and a second preference item to copy the script locally.
*sigh*
Geoff