Beginner Question - Why is there a baseline for every version and type?

Regular Contributor

Hi everyone,


i am currently double checking my settings against the baseline (2012R2 DC) and i am just curious why there is not one "DC baseline".


There may be new features incoming with each new server OS. But if i configure it on a Win2kR2 DC - it will just ignore it as there is no program that will read this reg key.

Same with Win10 - if there is the newest security setting out but only affects 1909+ - the older OS will ignore it.


So bottom-line i do not understand why it is separated by OS instead of just the roles (member server, dc, client,..)

I would assign the newest baseline for the domain controller to the OU "Domain Controllers" without the WMI filter - in my understanding that cannot break anything because of the older OS in this OU? 


Best regards



12 Replies

@StephanGee in theory that would seem the easiest.  However there have been various settings over the course of releases that do indeed change the behavior between OS versions and in those cases it would have caused everything from a crash to a less secure configuration.  We explored this in the past and the safest way to avoid conflicts is to keep them separate.


Thanks for your answer. Do you have any hints how to do a perfect rollout?
Do it all at once because some settings rely on each other?


I do not have a 100 percent dev/test/prod lab to test all settings for a week or two - so i need clearance that even if it breaks something that after i disabled the GPO and performed a Gpupdate /force and a restart - it is back to "normal" (the way it was before)


best regards


@StephanGee in many cases you can roll back but there are certain 'tattoo' settings that do not automatically rollback.  Also the security template settings do not roll back, they tattoo as well.  Within GPMC you will see the icon is different for those settings that tattoo in GP (not security template).  Take a look at the settings in the Security Compliance Toolkit area of the GPO and you should see them.


Every deployment is different so it's hard to give blanket advice.  We are working on an attempt at an article that describes many different options but due to several factors I dont see it being completed till after the first of the year.


I will offer this, for client machines, I wouldn't expect you to have much of an issue but I would be careful applying the server config to an up and running server, especially if it already has various roles on it as you might run into an issue there where the security template will adjust user rights.


My biggest concern is that i should apply them all at once(?) so that one setting does not collide with another. 

e.g. the SMB signing is forced on the one side but "disabled" on the other

@StephanGee testing is really however your organization feels comfortable.  If you have an existing baseline your company uses then I would start with Policy Analyzer.  This will help you identify where the different settings are.  From there you need to make a risk based determination on how you role it out.  I always recommend starting small and ensuring you dont break anything along the way.


Hi Rick. Yes - the policy analyzer is a great tool.

I have 2-3 critical settings that were set long time ago. But copied the DC to a Devlab and will test a few things out.

I came across settings like "IP Source Routing" also. But these are not available for me in the GPO.

Is it really necessary to execute the localgpo.wsf /ConfigSCE or are there just the admx somewhere that i can copy?

@StephanGee -

Don't run localgpo.wsf. The baseline downloads include ADMX/ADML files including the ones you need for some of those old MSS legacy settings, as well as for additional valuable settings exposed by the Security Compliance Toolkit. More information about the legacy MSS settings here:


Thanks. Yes i reviewed the WSF file and then decided not to deploy it. Even in my DEVLab ;)

I will try out the link you gave me. Appreciated

Thanks for all your help.

I am pushing the DC baseline step by step at the moment.


Another problem: I have some users with LM hashes. Is there an easy way to find out who so i can force them to change their password?

Just an update to get some information about some problems i came across (maybe other have them too)


MFP Printers vom HP need to be set to LDAPS with "simple bind" instead of Windows negotiation to work with "Channel binding" = "If supported"

Manage auditing and security log need "Exchange Servers" added to the ACL (if you have some) - or they will stop working (not immediately but within the next 2-3 days ;) ) 

Another question:
Why are the event log file sizes set so low? Is it because you should collect them right away to a SIEM?
If you don't have one - shouldnt they be higher?
32MB for Application seems a bit to low
Some of those log size recommendations haven't been revisited in a long time. 32MB has been the recommendation for the Application log in the baselines going back to Vista (except for an anomaly where 20MB was recommended for Win8).