Select Page

The title of this blog says it all. What happens to Group Policy processing when a client machine is off the network and can’t contact its domain controllers (DCs)? When trying to find the answer, you face even more follow-up questions:

  • Does the applied policy get removed?
  • Does it simply remain in effect?
  • Can users temporarily override settings by modifying the local GPO?

This blog addresses all these questions and provides additional details to help you better understand Group Policy processes.

The Phases of GP Processing

Before we dive into the problem, let’s take a look at how Group Policy processing works. The Group Policy engine processes Group Policy Objects (GPOs) in two primary phases, regardless of whether it is performing foreground processing (during computer startup or user sign-in) or background processing (either during the regular refresh cycle or when triggered manually with gpupdate). These phases are:

  1. Core Phase
  2. Client-Side Extension (CSE) Phase

The Core Phase

The core phase is where the client (AD computer or user) contacts a DC using the DC Locator process, which follows this sequence:

  1. The client sends a DNS SRV record query to find DCs registered in its AD site
  2. If a DC is found in the client’s own AD site, that DC is preferred
  3. If no DC is available within the site, the process falls back to any available DC

In addition to establishing DC communication, the core phase also:

  • Determines whether the connection is over a slow link
  • Identifies the client’s location within Active Directory
  • Queries AD to determine which GPOs apply
  • Builds the list of Client-Side Extensions required to process those GPOs

If the core phase fails, Group Policy processing stops. If it succeeds, the system proceeds to the CSE phase, where each applicable extension processes its portion of the GPOs.

The CSE Phase

Once the core phase is complete, the CSE phase kicks in. It is here that each applicable Client-Side Extension (CSE) runs and processes the settings in the GPOs that apply to the computer or user. This is where the actual policy settings are evaluated and applied.

During CSE processing, every extension identified in the core phase initializes and evaluates all GPOs that include that extension. CSEs generally run in the order in which they are registered under:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions

If a CSE encounters a fatal error while processing its portion of a GPO, that extension stops, but the remaining CSEs typically continue. As a result, a single CSE failure is disruptive for the settings it handles but does not halt overall Group Policy processing the way a core-phase failure does.

When No DCs are Available

So, what happens when no DCs are available? This can commonly occur if the machine is off the corporate network, or network issues prevent the machine from successfully connecting to any DCs. During the Core phase, Windows uses the Domain Controller Locator process to locate and communicate with a domain controller so it can determine the applicable GPOs and retrieve policy information.

If Windows cannot successfully complete the Core phase because no domain controller can be contacted and no applicable stored policy information can be used, Client-Side Extension processing that depends on domain policy will not occur. At that point, Windows logs events such as ID 7320 in the Group Policy Operational log, as shown below.

What about Existing GPO Settings?

Fortunately, Group Policy is not continuously enforced by maintaining a live connection to a domain controller. This means that although new GPO settings will not take effect, the settings already in place will remain unchanged. No existing settings will be removed, and no new settings will be added. If the CSE phase never runs, then no Group Policy changes can occur. 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? 🙂

Can GPO Settings be Undone When Disconnected?

Now the final question asked at the beginning was, “Can a user circumvent Group Policy that is already in place simply because the computer is offline and cannot contact a domain controller?”

The answer is no, but with a few exceptions, so let’s talk about them.

First off, 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 do a lot of things:

  • Directly modify or delete registry keys that store policy settings
  • Replace or delete LGPO files
  • Disable services involved in GP processing
  • Change file system ACLs
  • Install software that bypasses or overrides policy
  • Take ownership of protected objects
  • Reset permissions on any GP‑applied configuration

In other words, an administrator can remove or override almost any policy setting at will. However, while an admin can absolutely undo or circumvent enforced settings when offline, Domain GPOs will eventually reapply after the machine reconnects to a domain controller, restoring any settings that were altered or removed while offline.

What happens when you try to edit the local GPO while a machine is offline?

Of course, because it’s Microsoft and it’s Group Policy, the answer is…it depends. For many policy areas such as Administrative Templates, changes made through the Local Group Policy Editor are written to the local policy store located under:

C:\Windows\System32\GroupPolicy

However, those changes do not automatically override settings that were previously applied through domain-based Group Policy. Domain GPOs have higher precedence than the Local GPO, so if a domain policy has already configured a particular Administrative Template setting, editing the Local GPO while the computer is offline generally has no immediate effect on that setting. The previously applied domain policy remains in force until the computer can once again contact a domain controller and successfully process Group Policy.

Security Settings are an interesting exception. These are managed in the local GPO at:

Computer Configuration\Windows Settings\Security Settings

Because these settings are not stored in the file system, editing them changes the computer’s configuration directly at that moment rather than waiting for a Group Policy processing cycle to complete. However, before you get too alarmed, know this:

  • When a Security Setting is enforced by a domain GPO, it appears grayed out in the Local GPO editor and cannot be changed locally.
  • When a Security Setting is not enforced by the domain, however, it can be modified in the Local GPO even while offline, and the change applies instantly.

This distinction is subtle but important.

Conclusion

So, with all this complexity in mind, the bottom line is that simply disconnecting a computer from the network does not provide a way to bypass existing domain Group Policy. 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.