Select Page

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:

A client failing to find a DC during GP processing

A client failing to find a DC during GP processing






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.