How to inherit from Default Domain GPO?

You are correct that it's generally advisable to leave the Default Domain GPO alone.

If I understand your question correctly, you want another GPO that is linked at the same level (i.e. to the domain at the top level,) but if there are any settings in your custom GPO that conflict with what is in the Default Domain GPO, then the settings in your custom GPO should take precedence.

In this case, what you want to look at is the link order of the GPOs.

The GPO with the lowest link order is processed last, and therefore has the highest precedence.

You can modify the link order of the GPOs in the Group Policy Management Console. They're just up and down arrows that re-order the GPOs. If your GPO has a link order of 1, then it is processed last, meaning that it takes precedence over other GPOs in that same context (linked at the same level,) or overwrites the Default Domain GPO only on settings that are configured in your custom GPO. For settings that you do not configure in your custom GPO, the settings in the Default Domain GPO (where configured) will still apply.

You're misunderstanding what Group Policy Inheritance is and what it means. Group Policy Objects don't inherit settings from each other. Changes you make to one GPO are applicable to that GPO, other GPO's won't inherit the settings from another GPO.

I'm sure someone else here will post a lengthy and educational answer about Group Policy Inheritance, so I'll forego doing that myself. Suffice it to say, if you want to leave your Default Domain GPO untouched but want to create a new GPO that has all of the settings of the Default Domain GPO which you can then make changes to, then you can simply make a copy of the Default Domain GPO, rename it, and link it to the Domain. You can then make any changes you desire to this new GPO.

Introduction

One thing to keep in mind is that unless you're getting into extravagances like containers with blocked inheritance, or security-filtered GPO's, it's redundant to configure the same setting on more than one policy, especially if both policies are linked to the same container. As such, you normally want to create a new GPO, not copy an existing one.

Unless you want to disable and unlink your default domain policy, you don't want to copy it. Leave it alone and have it configure most of the settings. Create a new GPO that changes only what you want to change. Ideally, your Default Domain Policy should contain no settings (or at most, just the standard Account Policies, Local Security Policies and Public Key Policies). See our Default Domain Policy settings for an example:

Everything else should be defined in a baseline policy you create. Don't bother defining any settings in this baseline policy that your default domain policy already applies. Just define any new settings you decide to apply here. More on why below.

Since I'm on lunch, this is more 'quick and dirty' rather than 'lengthy and educational', still it's essential to have a good understanding of inheritance in order for your policy settings to work like you expect. In this case 'quick and dirty' means 'less time spent discarding content'. Go section-by-section.

Focus on the 'Don't Copy GPO's!' subheading. The other sections focus on the actual function of inheritance and how to use it properly, nuances around why you shouldn't copy GPO's, and the very rare, few exceptions that prove the rule.

Inheritance and Link Order Within a Single Container

See the image for an overview on how inheritance works. The images are from the Microsoft Group Policy Management Console, which visualises Group Policy settings. Don't panic, I will expand on the image:

When you click on 'Domain.Forest.com' (or any container, such as 'Domain Controllers'), the below image will show up on the right-hand pane:

You'll notice that we have two policies configured with a higher link order than the Default Domain Policy. These will apply their settings after the Default Domain Policy is processed, and overwrite any settings that conflict with it. If the default domain policy defines settings that they do not define, however, those settings will still apply, because they have not been overwritten.

For example, Let's assume the default domain policy stipulates that both the Wired AutoConfig and WLAN AutoConfig services are set to 'Automatic Startup' (Computer Configuration\Windows Settings\Security Settings\System Services). If the 'Domain Security' policy then stipulates that WLAN AutoConfig be set to 'Disabled' and that all logon events be audited (Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy), then this is the resultant set of policy (RSoP):

Wired AutoConfig: Automatic Start

WLAN AutoConfig: Disabled

Audit logon: Success, Failure

So the Wired AutoConfig setting was retained from the Default Domain Policy, because it was not overwritten. But the new setting for the WLAN AutoConfig was overwritten, as it was both 1) Defined, and 2) From a policy of higher precedence.

If we selected the "Default Domain Policy" in the second image and clicked on the single up-arrow on the left-hand side of that image, (changing the link order), the Default Domain Policy would now have higher precedence than the Domain Security policy. The RSoP is now:

Wired AutoConfig: Automatic Start

WLAN AutoConfig: Automatic Start

Audit logon: Success, Failure

Don't copy GPO's!

Keep this in mind when defining policy settings. Defining a setting (e.g. enabling a service) in your link order 3 policy, then re-defining it in your link order 2 policy, is wasteful. Whether or not the link order 2 policy disables or enables the service (continuing from our example). Feel free to split settings among policies for ease of administration and to create logical groupings of settings, but never define the same setting more than once, across multiple policies, at the same level of the hierarchy.

Processing of Group Policy objects is also known to blow out logon times to workstations. The more policies to process, and the more settings in the policy, the slower the login.

Define the setting once in an appropriately-named policy and do not override it at the same container level.

This is also why you want to create new policies, not copy them. Otherwise, the policies are processed once. Then the policy with higher precedence processes them all again, and the only gain will be the one or two settings you changed from the original policy

Instead, these settings can simply be put into a new, otherwise blank GPO. Then, one or two extra settings are processed, rather than potentially hundreds. Ideally, then take these settings out of the original policy, so you aren't processing and re-processing settings.

The only cases where you should be specifying settings that conflict, is where you have lower-level containers override settings applied by higher-level containers.

For instance, you might turn the WLAN AutoConfig Service on in your Domain Security policy, but set it to disabled for your Domain Controller Policy (in the Domain Controllers container). In this case, the lower-level policy takes precedence and your Domain Controllers don't try to auto-configure Wireless LAN. However, your workstations and laptops, inheriting from the domain root and not sitting under the 'Domain Controllers' container, still receive the setting to turn on WLAN AutoConfig and attempt to connect a wireless network if it is available using the WLAN profiles your policy defines.

Again, this isn't a reason to copy Group Policy Objects. Just create a new GPO at the appropriate level in the Hierarchy, and define only those settings you want to overwrite.

Inheritance and Link Order Across Multiple Containers

Going back to managing inheritance, 'Linked Group Policy Objects' is editable, but only shows group policies linked to the current container (the domain root counts as a container for this purpose). Each container has its own link order. 'Group Policy Inheritance' gives you the complete view, which looks pretty much the same for the domain root (note the unlinked policy "Password Policy" is not displayed):

But if you look at the inheritance window from a container further down the tree (aka Domain Hierarchy):

Notice that the policies from the lower level containers are higher up in precedence. Policies from lower level containers will always run after policies from higher level containers, overwriting their settings. The link order is only relevant in the context of the current container, lower-level containers will always trump higher-level containers regardless of link order. As before, if the lower-level policy does not specify a setting, the setting from the higher-level policy is not overwritten and still applies.

Don't Copy, Link the Same GPO to Multiple Places

We've gone across all the times when you SHOULDN'T copy a GPO. Let's assume you want to create a container with blocked inheritance. In this case, only policies linked directly to this container will apply to it. Containers below the container with blocked inheritance will still inherit policies from the 'inheritance-blocked' container (as if it was the domain root), unless they themselves are configured to block inheritance.

In this case, If you need to cut out a large number of Enterprise policies but still need most of the settings from some specific GPO's that are further up in the hierarchy, simply add a Group Policy Link to the higher level GPO. Right-click on the container with Blocked Inheritance and select 'Link an Existing GPO'. Select the GPO you need from the list.

Okay, Sometimes Copy (and Migrate) GPO's

Let's say you have a container with blocked inheritance, and you need a few hundred settings from a GPO higher in the hierarchy. You also need to change a few dozen settings in the same policy. In this case, it's acceptable to copy the policy, rename it, make the changes, then link it into your container with blocked inheritance.

In this case, due to the way your inheritance is configured, clients aren't processing both the original policy and its copy. They are processing only one or the other, depending on where they are in the hierarchy. If you wind up using security-filtered groups, the same rules apply.

If you decide to mix security filtering with loopback processing, read this. First try to use neither security filtering or loopback. Failing that, try to use replace mode. If you use merge mode, you will need to use the advanced security settings to give the computer accounts read, but not apply permissions to the group policy. Don't just add them to the security filtering - that implies apply as well as read!

Finally, if you run Test or Pre-Production environments, you'll often want to Migrate GPO's between domains. There are ways to do this using GPO migration tables. If your policy settings don't reference any domain security principals (don't worry about security settings on the GPO itself), the simpler way is using PowerShell.

Create a new, empty file folder on a machine in the source domain. On the same machine, run these commands:

import-module grouppolicy
backup-GPO -GUID "<aka Unique ID from GPMC including parenthesis - select the GPO in the left-hand pane and then select the Details tab>" -path "<Backup Path>"

Copy your file folder from the source domain to a machine on the target domain. Make a note of the new subfolder of your backup path from above - it will have a parenthesis-enclosed number that looks like a GUID. I will refer to this as the 'Unique ID folder'. Make sure 'manifest.xml' is also present.

Create a new, blank GPO on the target domain, take a note of its unique ID and run these commands:

import-module grouppolicy
import-gpo -targetGUID "<Unique ID from GPMC of new policy in target domain>" -backupID "<Unique ID folder name from your backup path>" -path "<The parent folder, under which your unique ID folder sits>"

All of the settings from your GPO in the source domain will now be contained inside your GPO on the target domain.