Group Policy order can be confusing. To understand how exactly Windows applies one GPO (Group Policy Object) versus another, you can use the "LSD OU" rule.

You should always ask yourself two questions when dealing with Group Policy:

  1. Where are you (local, site, domain, or organizational unit)?
  2. What are you (computer or user)?

The LSD OU rule

With these two questions, you will be able to understand how the system applies Group Policy Objects as well as which object you are attempting to add or remove settings to. Additionally, a simple acronym can help anyone understand the layering of GPOs. That acronym is LSD OU! It stands for the following elements:

L = Local

S = Site

D = Domain

OU = Organizational Unit

You can create and apply GPOs to computers and users, but most people think they only apply to domains. This is partially true, but you can configure Group Policies for local machines as well. This means you can apply GPOs in multiple ways, but GPOs will apply to a system or user in a specific order.

This specific order is the same as in the acronym: LSD OU.

LSD OU rule: L (local), S (site), D (domain), OU (organizational unit)

LSD OU rule: L (local), S (site), D (domain), OU (organizational unit)

Local Group Policy

On your local system, you can view and edit your Local Group Policy settings by searching your computer. Using the Start Menu, begin typing (searching) for "Edit Group Policy." You can configure settings for your local system or account, but all subsequent Group Policy layers (site, domain, and OU) that have the same setting configured or enabled can overwrite these settings.

This means you can configure Group Policies locally, but the system can overwrite them when you've set Group Policies to trump these settings from site, domain, or OU GPOs applied to your system or user account.

Site-based Group Policy

Now that we understand how Windows applies Local Group Policy settings, we move toward understanding how an organization that has Active Directory (AD) can apply GPOs. At the topmost layer, Group Policy Objects can apply to the "site" level. To understand how a site-based Group Policy could work, we must first generally understand how large organizations might structure their environment.

In Active Directory, we have a topmost layer called an AD forest. An organization can have multiple forests. Within each AD forest, we can have multiple domains.

Multiple AD forests and domains

Multiple AD forests and domains

If your organization has a large environment, the infrastructure design may look like the figure above. Even if you only have one domain in your environment, you can use AD sites, but you will not typically see this. You can understand an AD site as a subnet of your network. We can organize or group machines, systems, users, etc. that reside within a specific subnet. We can then apply a specific GPO to those objects even if those items do not reside in the same domain (or even forest).

Some organizations may use this feature. I have never had to use it personally, but it's a great way to organize your GPOs across domains and forests, especially for servers that may reside in your datacenter but belong to different groups, sub-organizations, or domains.

When linking GPOs to your sites (groups) and a Local Group Policy exists with the same setting, site-based GPOs will overwrite any Local GPO settings.

Domain-based Group Policy

Domain based Group Policy Objects are far more common in organizations, mostly because setting up a new domain creates a "Default Domain Policy" at the root of that domain. This policy contains a few default settings like a password policy for your users, but most organizations change these. Additionally, some organizations modify this default policy and add their own specifications and settings.

You can definitely add to and edit the Default Domain Policy, but you may be better off just creating a new GPO at the root of your domain. If you decide to modify the existing Default Domain Policy or create a new GPO, please be aware you should apply certain settings to your root domain and not subsequent locations like OUs. It is possible to set these settings in alternate locations, but not recommended. You can only set these settings once per domain, and thus the best practice is to apply these at the root of the domain.

  • Account policies
    • Password policy
    • Enforce password history
    • Maximum and minimum password age
    • Minimum password length
    • Passwords must meet complexity requirements
    • Store passwords using reversible encryption for all users in the domain (Noooooooooo!)
  • Account lockout policy settings
    • Account lockout duration
    • Account lockout threshold
    • Reset account lockout counter after
  • Kerberos policy settings
    • Enforce user logon restrictions
    • Maximum lifetime for service ticket
    • Maximum lifetime for user ticket
    • Maximum lifetime for user ticket renewal
    • Maximum tolerance for computer clock synchronization
    • Network access: Allow anonymous SID/NAME translation
    • Network security: Force logoff when logon hours expire

If you have a specific configuration or setting you want to apply to all systems, you should create and link that GPO to the root of your domain. This aids both visually and logically the design and layout of your GPOs. If you still want to apply a GPO to most of your systems or users, you can still create and link that GPO to the root of your domain. However, you will need to filter what the GPO will apply to.

You can filter a GPO several different ways, but the most common methods are using the Security Filtering sections on the GPO's Scope tab or using WMI Filtering (also located on the Scope tab). By default all GPOs have Authenticated Users set as the filtering scope. (Please note Authenticated Users means both user and computer objects authenticated to the domain.) But if you wish, you can specify both (or either) a Security, Distribution, or individual objects that contain either computers or users, instead of all Authenticated Users.

As I mentioned previously, you can also set a WMI Filter that will automatically filter what objects this GPO will apply to. For example, if I wanted to apply a GPO to all laptop and mobile computers, I could add a WMI filter that would look for the existence of a battery.

WMI filter to apply a GPO only to systems with a battery

WMI filter to apply a GPO only to systems with a battery

Group Policies applied at the domain level will apply to all objects that contain the specific setting you have configured. Applying either a local or site policy that includes an object (user or computer) within our domain will apply those settings first. If we set a domain-wide policy that has any portion of either a local or site GPO, our domain GPO will overwrite either of the previous settings.

In a typical organization, you will always see Account, Account Lockout, and Kerberos Policies at the root of that domain, but some choose to add other policies. For example, one could configure and add settings related to Windows Event Viewer logging across all systems. It is a best practice to create a specific policy for this setting instead of just adding it to the Default Domain Policy (but you can).

Most of your GPOs (configurations) will apply one step lower, at the Organizational Unit level. This allows for more granular control, and visually these OUs typically represent the structure of your organization (e.g. Finance, HR, Marketing, etc.).

Container-based Group Policy

Depending on who has designed or organized your Active Directory OU structure, you will typically have a set of containers or folders similar to the layout of a file system. These folders (OUs) can contain any AD object like Users, Computers, Groups, etc. Even though they contain these objects, all Group Policy Objects contain built-in filtering. When we create a new GPO, we will see there are two main configuration options available (built-in filtering). These are Computer Configuration and User Configuration. We can apply configurations to both Users and Computers within the same GPO, but we can also specify one or the other as well.

User and Computer based Group Policy

User and Computer based Group Policy

For example, let's imagine we have a simple setup for our domain that contains the following:

Example of Group Policy order in a simple organizational structure

Example of Group Policy order in a simple organizational structure

The Default Domain Policy will apply to all OUs and User or Computer objects that reside below where you applied the GPO (basically, in the domain). Again, typically this GPO contains all the Account, Account Lockout, and Kerberos settings for the entire domain and possibly other configurations and settings.

The second layer (Parent OU) has a Group Policy applied to it called Configure Default Logging, which applies to all Computer objects that reside within the Parent OU. This means that the Configure Default Logging policy will apply to any computers within either the Parent OU or Child OU.

The last layer is the Child OU. This OU has another GPO applied to it called Configure Child Default Logging. The Configure Child Default Logging GPO could be the same as the Configure Default Logging GPO. (You shouldn't do this, but if you have a reason to, you can.) But let's imagine we have decided to change the Retain application log setting for all computer objects residing under the Child OU. However, we don't want to apply it to all computer objects within the Parent OU.

This means our Default Domain Policy will apply first to our computer. (Remember, you can specify certain settings only once and thus only apply them once). Next the settings of our Configure Default Logging policy will apply to our computer. Finally, our changes to Configure Default Logging in our Configure Child Default Logging policy will apply last. This will modify any settings that are not "set only once" settings and are within the Configure Default Logging policy.

The order in which these GPOs will apply to our computer objects is as follows:

Default Domain Policy > Configure Default Logging > Configure Child Default Logging

There are a few caveats to this processing though. These are longer topics, which I plan on writing more about soon, but these caveats include both Enforced and Block Inheritance. A GPO applied higher in the hierarchy of your AD (OU) structure has the right to enable a setting on that GPO called Enforced.

Enforced means that if any other OUs have enabled another setting (which I'll talk about next) called Block Inheritance then that GPO will apply no matter what (even with Block Inheritance enabled). A GPO higher in the domain or OU structure that has Enforced enabled will overwrite any subordinate OUs that have enabled Block Inheritance.

To enable the Enforced setting on your GPO, you can right-click it and select Enforced.

Enforcing a GPO

Enforcing a GPO

To add Block Inheritance to an OU, you can select it, right-click it, and select Block Inheritance. Again, if certain settings like Account, Account Lockout, and Kerberos policies already apply, those settings will trump either one of these features since they only can apply once across your domain.

Block inheritance of GPOs to specific OUs to influence GPO order

Block inheritance of GPOs to specific OUs to influence GPO order


Remember the two main questions you should always ask yourself before enabling a Group Policy Object:

  1. Where are you (local, site, domain, or OU)?
  2. What are you (computer or user)?

Understanding these two questions is critical when you begin configuring GPOs that may impact hundreds or even thousands of users or computers in your organization. Additionally, if you understand LSD OU, you are well on your way to mastering Group Policy order and streamlining your IT processes.

  1. Leos Marek (Rank 4) 6 years ago

    Hi Josh,

    great article 🙂 just wondering what are you planning about the block/enforce? Id say these are pretty clear and with your short explanation its more than enough, or is there something else?

    thx L

  2. danielkr 5 years ago


    Does “Enforced” at the Domain level cause the enforced policy to

    a. Fall through a “Blocked Inheritance” OU and apply before OU policies, or

    b. Fall through a “Blocked Inheritance” OU and take precedence over OU policies, i.e. any OU policy with a setting already specified in the enforced policy in parent is ignored?



  3. danielkr 5 years ago


    Is Default Domain Policy going to

    a.  Ignore a Blocked setting in a subordinate OU or

    b.  Need to have the Enforced setting in order to apply in a subordinate OU with the Blocked setting?



    • Author
      Josh Rickard (Rank 2) 5 years ago

      Hello Daniel,

      Certain policies can only be applied once in a domain and those are typically in a Default Domain Policy. For example, password policy can only be applied once in a domain and will trump anywhere else that it is configured.

      If a OU has blocked inherentance but the parent (or any parent above it) with enforce enabled will trump that blocked inheritance setting.

      Does that answer your question?

  4. jimmy 5 years ago

    Hi there,

    Thank you for this great article.
    Here’s what I am trying to do. I want to create a GPO and force users to change their passwords every few months. Now because users are not aware of how many characters they should use for the new password (although we notify them) I was thinking to use interactive logon message policy to help them out.
    I test it on my laptop (used 2 VM’s) and it worked, message appears as it should.
    I created a test GPO on the domain and then was added to all OU. On the Security Filtering tab, I removed Authenticated Users and add just a test user. I run gpupdate /force on test user pc but nothing happened.
    What if I create that GPO on Group Policy Objects folder, should work that way?

    Thank you

  5. jimmy 5 years ago

    Hi Michael,

    Thank you for your reply.
    I’ve read the article you mention and it’s very helpful since i am not that much experienced with GPOs and stuff like that.
    So i will give another try then with my testing user and this time i’ll leave Authonticated Users as is.
    Hope that password policy will work this time as it should.


Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account