When does AD domain-joined Group Policy override local?

Understand Group Policy settings

IT administrators can configure Group Policy settings using local and AD-based Group Policy Objects (GPOs). Both are useful, but local policies are rarer in AD environments.

Local Group Policy settings

Configuring workstations with local Group Policy settings allows admins to manage configurations on domain-joined and non-domain Windows systems alike.

However, local GPOs are decentralized. Desktop admins have to configure and apply them per computer, which is difficult when managing numerous systems. Imagine configuring 30 local Group Policy settings on 15 different computers. That would be time-consuming and leaves room for human error. Admins must return to each system to adjust any of those configurations later as well.

Active Directory Group Policy settings

Centralization is a key benefit of Active Directory, especially with Group Policy. AD-based GPOs have thousands of settings to manage -- far more than local GPOs -- and may be managed from one Group Policy Management console.

Administrators must link a GPO to apply its settings -- this process associates a GPO with one or more AD objects: AD Sites, the Domain and Organizational Units, or OUs. AD admins cannot link GPOs to individual user accounts or groups.

Be careful of the AD terms container and Organizational Unit. Containers are built-in storage objects for basic AD functionality. OUs are administrator-created groups to logically organize user and computer accounts, often by department, project or location. The critical difference is that IT can apply GPOs to OUs but not containers.

The three AD objects to which admins can link GPOs allow different scopes for their settings.

• Site-linked GPOs apply to all users or computers that authenticate in a given physical location, such as company headquarters or a branch office.
• Domain-linked GPOs apply to all users or computers that are domain members.
• OU-linked GPOs apply to all users or computers stored in that OU. OUs often represent departments or other business units needing similar configurations.

Hierarchy of Group Policy settings

Admins can apply GPOs at four levels: locally, AD Sites, the Domain and OUs -- and problems arise when GPO settings conflict. For example, one administrator might enable a setting in a domain-applied GPO, and another administrator could disable the same setting in an OU-applied GPO. This leads to unexpected results unless the IT team understands the exact rules of GPO processing.

The GPO application order is local, site, domain and OU. The last setting applied wins.

1. Local GPOs. Systems process and apply these settings first. Most business environments avoid these decentralized GPOs.
2. AD Site GPOs. AD GPOs that are linked to a Site apply next. These location-specific settings related to a particular location depend on where a user or computer authenticates. Admins might use a GPO to deploy printer settings to all systems at the location where the print device resides.
3. AD Domain GPOs. Domain-linked GPOs apply next. These GPOs should contain company-wide settings that apply to all users and computers. These are often security settings, such as firewall or encryption policies.
4. AD OU GPOs. GPOs linked to OUs apply last. These are the most granular and typically represent department-specific settings. IT might link a GPO to the Sales_Dept_OU that deploys sales-specific software not licensed for other departments. GPOs linked to child OUs apply after GPOs linked to the parent OU.

Administrators have a No Override utility that causes the specified GPO to apply last, therefore winning any conflicts. This prevents OU-linked policies from applying settings that contradict domain-linked policies.

Group Policy conflict troubleshooting example

Consider a firewall configuration that results in a series of GPO conflicts at various steps in the processing order.

1. Local GPO. The Windows Firewall is Disabled. If processing stops here or if the system is not domain-joined, then the firewall is off. Status = Off.
2. Site GPO. The firewall is set to Not Configured, meaning it uses the Windows default setting or a setting from a previously applied GPO -- in this case the local GPO, which disabled the firewall. Status = Off.
3. Domain GPO. The firewall is enabled, which turns the firewall on. If the Group Policy processing stops here, the firewall is enabled because this GPO applies later in the process than the local and Site GPOs, which disabled it. Status = On.
4. OU GPO. The workstation is in a lab that requires the Windows Firewall to be off, so this GPO disables it. This GPO applies after the Domain GPO, so the firewall is disabled. Status = Off.

After the four GPOs process, the firewall configuration is disabled because the OU-linked GPO wins.

Troubleshooters could observe some GPOs that disable the firewall and others that enable it, leading to confusion about the firewall status. The key is to understand that the last GPO applied overrides GPOs applied earlier in the process.

GPO management best practices

Local GPOs should be rare in AD environments. Managing decentralized configurations is just too time-consuming. Administrators should link all GPOs at the AD Site, Domain and OU levels if possible. It's far easier to change settings and manage options for multiple systems using a centralized AD Group Policy.

The following command-line tools can also help admins reapply GPO configurations on desktop systems:

• gpresult. This command displays winning GPOs that define the system's final settings.
• gpupdate /force. This command downloads and reapplies GP settings from the authenticating domain controller.

Event Viewer logs can also help in troubleshooting scenarios. This tool helps IT administrators dive deeper into specific error messages and logs. IT can learn which policies are in place and how they may have affected the outcome.

Damon Garn owns Cogspinner Coaction and provides freelance IT writing and editing services. He has written multiple CompTIA study guides, including the Linux+, Cloud Essentials+ and Server+ guides, and contributes extensively to TechTarget Editorial and CompTIA Blogs.