Asked by:
Default Domain Policy and Default Domain Controller Policy

-
I am looking for some help on explaining why these two policies really shouldn't be modified to use for anything other than default Policies, however I am having trouble putting into words a non-techie would understand...
Would anyone be able to help me out on this subject with Microsoft Best Practices ?
Thank you
Question
All replies
-
They contain very sensitive configurations and I believe this is the reason that is not recommended to update them. Instead, new GPOs could be created to achieve exactly the same results.
This posting is provided AS IS with no warranties or guarantees , and confers no rights.
Ahmed MALEK
- Proposed as answer by Andy_PanMicrosoft contingent staff, Moderator Wednesday, January 11, 2017 4:56 AM
-
Hi,
As X said, they contained sensitive configurations.
Besides, they're domain level policy, so their impact level is the whole domain.
If you edit it with a wrong configuration, the whole domain might encountered unexpected issues. That's fatal in product environment.
So, our principle is : reduce risk to a minimum. Also, making things as easier as we can.
It's also very helpful for troubleshooting issues.
Best regards,
Andy
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com. -
Hi,Am 10.01.2017 um 22:17 schrieb Jason_A_T:> I am looking for some help on explaining why these two policies> really shouldn't be modified [...]It´s completly up to you. There is no technical reason to handle it oneor the other way.GPOs are just a kind of transport modules to deploy information. Theobject does not care, if the settings comes from one or the otherobject. In the end the ruleset must give your desired result.I use the Default Policies for a few reasons, but I have some rules:- I only change existing values that do not fit. DefDomPol containsAccount, Lockout and Kerberos Settings nothing else. DefDomConPolcontains User Rights assignment and Security Settings.I do not add any other.- The Default Policies have hardcoded GUIDs, they are always the same inany AD. They are easy to find and easy to troubleshoot, because of that.- It creates more work, if "personal Defaults"-Policies are used.You need to be aware of the sort order. If you install a software on aDC, thats needs an entry in "User Rights assignment", this is doneautomatically into the DefDomConPol, because it´s a hardcoded GUID (youremember?) and the right GPO can be identified by the software.If you have youre own GPO, you need to set the value manually and youshould not forget that, otherwise the softwasre does not work.- There is a interaction between the DefDomPol and the Domain HeadPassword settings. If you edit the Password attribute in"dc=your,dc=dom" it will automatically update the value in DefDomPol.- Aswell, there is an interaction between the local policy of the PDCemulator and the DefDomPol. Which can cause a little confusion whenupdating or changung DCs.- I do not accept the argument: "Do not change the default, because wedo not know how to restore them, in a specific case".Thats stupid. It takes 10 minutes to install a NEW AD and DC by"enter-enter-ok". Get the settings from there ... It´s the DEFAULT, youdid not change the origin, so ANY fresh AD can give you the settings.- Create Backups of your GPO, easy job with the GPMC or script to backuponce a day, but only if changes happenConclusion:It´s up to you.Mark--Mark Heitbrink - MVP Group Policy - Cloud and Datacenter ManagementHomepage: http://www.gruppenrichtlinien.de - deutschAktuelles: https://www.facebook.com/Gruppenrichtlinien/
- Proposed as answer by Andy_PanMicrosoft contingent staff, Moderator Wednesday, January 25, 2017 4:03 AM