GROUP POLICY - DEFAULT DOMAIN POLICY

[Koldov]

So, firstly I'd like to say 'most' of this isn't my fault... but I have been guilty of adding things that I want to apply to all computers or users to the DDP...

 

In my defence I would like to say that the majority of settings in it were there before I started and due to my ignorance in the early years I too put a fair bit in there.

 

However, now I need to clean it up and I really don't know where to start...

 

The only thing is, if I now split all those settings out into individual GPOs at the root of the Domain it will add about 16 computer and 10 user gpos (I'm guessing I have to recreate each individual setting into its own GPO and apply it to the root).

 

But I'm kind of wondering the actual reason for having the DDP set as default...?

 

Is it best practise to have every setting in its own GPO, or can you put a bunch of settings in one GPO? Because I also had another idea of just copying the DDP applying it at the root and then resetting the DPP!

[3s-gtech]

Put them (all that are domain wide and not user settings, taken out of the DDP) in one GP. Each one that’s processed adds a small chunk to startup (or at least readiness) times, as well as size in the sysvol. These won’t have big effects with modern kit (not like running Windows 2000 clients on a Pentium II, with 10/100 hubs, where efficiency was key!) but still.

 

Your default domain policy can be re-created I believe, but if you strip out everything that has been added (and not the default settings) it should be okay.

Edited July 23, 2021 by 3s-gtech
Clarity

[Mako]

It's recommended not to fiddle with the DDP although in practise it shouldn't really break anything.

 

How you build your GPOs is up to you but it tends to be around how you're assigning the settings. I'm currently building a new domain and there are some Trust-wide things that will apply to everyone, everywhere. So user configurations are in a single GPO, it's a pretty meaty one too, but nitty-gritty things tend to have their own. For example, all students in all schools will have the same setting, but then there's separate GPOs for site/room-specific things.

 

As long as it's documented so you know what GPO does what.

[Koldov]

Put them (all that are domain wide and not user settings, taken out of the DDP) in one GP.

 

The DPP has both Computer and User settings, can't other GPOs set at the root do the same? Or should User settings that apply Domain wide and Computer settings that apply Domain wide be in separate GPOs at the root?

 

It's recommended not to fiddle with the DDP although in practise it shouldn't really break anything.

 

Yeah that's what I figured... it hasn't for the last 11 years!

 

How you build your GPOs is up to you but it tends to be around how you're assigning the settings.

 

Unfortunately I'm not really that confident in making big sweeping changes - I know they can be quite powerful and have all sorts of settings in them that can be really, really useful if you know what you're doing (especially with item level targeting and GPP options), there were a few lockdown policies from before that had a bunch of settings in them, but I tend to break things down into separate OUs and apply individual GPOs when I want to do specific things (it does make for quite a complicated structure though)...

 

One last question for now... obviously things set at the root of the Domain apply to Domain Controllers as well... With such a chunky DPP having lots of settings in (such as SRP, Applocker, disable script host, other script extensions opening with notepad) does anyone else block GPO inheritance for the DC OU?

Edited July 23, 2021 by Koldov

[Davit2005]

To be honest I'd always make a copy of the Default Domain Policy then change that instead. Or make a copy of it as backup so you know what the original settings were.

[3s-gtech]

There’s very little that I’d actually apply domain wide anyway, especially with user settings. I tend to separate them from computer settings to allow easier management, and there are some user accounts that I don’t want to have any GPOs applied to other than the DPP.

 

Basically, I use a separate GPO for each granular policy. I have ‘big’ GPOs for things like ‘staff PCs’ or ‘students’ but granular GPOs for ‘install VLC’ or ‘Start Menu for main ICT suite’.

[Chaniel]

I had something similar - the old IT team added a load of superfluous stuff to the Default Domain Policy and I wasn't sure what was support to be the default.

 

I duplicated the GPO and then used dcgpofix (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/dcgpofix) to recreate the default policy and went from there.

Compared settings and added everything that was required into my own policy at top level (for domain wide stuff) or just straight up removed settings that weren't required anymore.

[HPlum78]

Yeah leave the default domain and domain controller policies alone, because if you ever raise an MS prem support call chances are you will be putting those back to their defaults...

 

You can setup the GPO'S as required and use security filtering to limit the scope of the policy.

 

So for instance you probably dont want to have the same WSUS/ update policy applied to every server in your estate so having GPO's configured for Wednesday 02:00/ Wednesday 03:00.... And groups called/ identified the same way you can drop your servers in the appropriate group and the corresponding GPO will be applied.

 

You can also leverage this methodology for testing that the settings applied are going to have the desired results on a limited number of test machines before the BIG BANG go live. Also look at using AGPM to manage your GPO's.

[jthompson]

For each GPO you can also disable either the Computer Configuration or the User Configuration section ('GPO Status' in GPMC). Therefore, if you've got a clutch of GPOs high up in your domain tree that are purely for computer settings and not using any of the user config section, disabling the user configuration on them will mean that they get ignored when clients are processing user policies (one imagines*). Similarly, computer config can be disabled for GPOs that only contain user settings.

 

*Not sure what, if any, payoff it gives, but we tend towards having lots of separate GPOs, so I like to think it's a useful optimisation.

 

 

EDIT: Just been reading that it's doesn't really save anything when processing, but I think it feels tidier to do it anyway.

Edited July 23, 2021 by jthompson

[Roberto]

Is it best practise to have every setting in its own GPO, or can you put a bunch of settings in one GPO? Because I also had another idea of just copying the DDP applying it at the root and then resetting the DPP!

 

As a bare minimum, I would keep user settings and computer settings apart. Aside from that, have a philosophy / design that you feel will work for you and then stick with that.

 

For example, you might decide to have all your settings related to end user experience - e.g. changes that affect what the user can see and will do, all in one GPO and all settings related to back-end security that they wouldn't see in another. Not too sure about this one myself, but its a suggestion. I would probably break stuff down into a different pattern based on things I thought would make sense to deliver together, e.g. browser/internet settings in one GPO, settings related to Office software in another, etc.

 

Whatever you choose, breaking things down has the advantage of allowing you to target different settings to different groups of people quite surgically, as well as being able to test and stage a rollout of new settings, whereas if you have fewer, more monolithic GPOs, you're making it harder to troubleshoot and stage rollouts of settings.