Default Domain Policy School of Thought 1 1/2 Page 1:373

[RTHJr]

And I do mean School of Thought <b>one and a half</b> ( 1+1/2).

One can gain the benefits of both schools of thought behind "best practice" use of the Default Domain Policy.

Do both, that is use the Default Domain Policy for the domain-wide settings noted in the book; but make a copy of your clean and pristine Default Domain Policy before using it (or after a system default reset by the DCGPOFIX.exe or RecreateDefPol utility noted on pp 375-376) and name that policy something like:

"Domain Out of the Box"

and then disable it.

The value of this is that you have in reserve the default settings as a reference. I have found many times that I never seem to learn...well OK, not always never but enough times anyway...where I follow along a KBase article that has the premise of the default settings and not our actual environment and get stumped. So hanging onto a GPO with the defaults can be handy to keep yourself from troubleshooting a "ghost" setting you think you should have because documentation says so (usually stating it as a default for a clue) when in actuality the policy is applying correctly.

Some oddities about the DCGPOFIX.exe I found are:

The Default Domain Policy get double linked. One to the domain and one to the site when resetting (at least) the forest root domain. Linking sites is a no-no and something to watch out for. This may occur if resetting other sub-domains down a forest tree but I cannot say not having that done.

The other oddity I found is the Default Domain Policy and Default Domain Controller Policy get set to "Enforced". Any other GPO settings are ignored regardless of what link number other GPOs may be on the domain container.

It seems the premise of the DCGPOFIX.exe is to really, really make sure that the defaults are punched in hard to regain control for poor admins who inherit (or disinherit, whatever perspective you may go by) a royally screwed up set of default GPOs.