Skip to main content
Print

Clean Up a Disorganized Default Domain Policy –

The Default Domain Policy (DDP) should hold only account policies: password, account lockout and Kerberos. This article moves every other setting into purpose-named GPOs, then strips the DDP back to those three areas without changing what clients receive.

Applies to: Active Directory domains managed with the Group Policy Management Console (GPMC) and the GroupPolicy PowerShell module.

GPO identity: Default Domain Policy, GUID {31B2F340-016D-11D2-945F-00C04FB984F9}, linked at the domain root.

Symptoms of a disorganized DDP

  • The Settings report runs to many pages and mixes security, software, drive maps, printers and desktop settings.
  • Admins edit the DDP for unrelated changes because “everything is already there”.
  • Troubleshooting a single setting means reading the whole report, and nobody knows why some settings exist.
  • Security filtering or WMI filters have been added to the DDP, so not every object receives it.

What stays and what moves

Keep only the settings under Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies. Everything else moves to a GPO named for its purpose.

Domain password and lockout policy for domain accounts is read from GPOs linked at the domain root, which is why these settings live in the DDP. Different password rules for specific groups belong in Fine-Grained Password Policies (Password Settings Objects), not in OU-linked GPOs.

Setting area found in the DDPWhere it goesSuggested GPO name
Password PolicyStays in DDPDefault Domain Policy
Account Lockout PolicyStays in DDPDefault Domain Policy
Kerberos PolicyStays in DDPDefault Domain Policy
Security Options, Audit Policy, User Rights (non-DC)New GPO linked at domain or workstation/server OUsDomain – Security Baseline
Windows Defender Firewall rulesNew GPODomain – Firewall
Drive maps, printers, shortcuts (Preferences)New GPO linked at user OUsUsers – Drive and Printer Maps
Desktop, Start menu, Control Panel restrictionsNew GPO linked at user OUsUsers – Desktop Settings
Software installation, AppLocker, Software RestrictionNew GPOComputers – Application Control
Windows Update / WSUS settingsNew GPOComputers – Windows Update
Settings on domain controllers onlyDefault Domain Controllers Policy or a DC-specific GPODomain Controllers – Hardening

Adjust names to your own convention; the point is one purpose per GPO.

Before you begin

Do not start until a backup exists and a change window is approved; the DDP applies to every computer and user in the domain.

  • Domain Admin (or delegated GPO edit rights) on the DDP and rights to create and link GPOs at the domain root and OUs.
  • GPMC and the GroupPolicy PowerShell module installed on the admin workstation (RSAT).
  • SYSVOL replication healthy on all domain controllers; check with dcdiag /test:sysvolcheck /test:advertising and the DFSR event logs.
  • A pilot OU containing representative test computers and users.
  • A change ticket and a maintenance window.
  • A secure folder for backups and reports, e.g. C:\GPOBackups.

Do not use dcgpofix as a cleanup tool. It resets the DDP to its out-of-box state, wiping your password and lockout values along with the clutter. Treat it as a last-resort recovery only (see Rollback).

Procedure

Build the new GPOs first, prove they deliver the same result, and only then remove settings from the DDP. At no point should a client lose a setting.

Step 1: Back up and capture the current state

Run from an elevated PowerShell session on the admin workstation.

$path = "C:\GPOBackups\DDP-$(Get-Date -Format yyyyMMdd)"
New-Item -Path $path -ItemType Directory -Force | Out-Null

Backup-GPO -Name "Default Domain Policy" -Path $path -Comment "Pre-cleanup"
Get-GPOReport -Name "Default Domain Policy" -ReportType Html -Path "$path\DDP-before.html"
Get-GPOReport -Name "Default Domain Policy" -ReportType Xml  -Path "$path\DDP-before.xml"
Get-GPPermission -Name "Default Domain Policy" -All | Export-Csv "$path\DDP-permissions.csv" -NoTypeInformation

On two or three representative clients (a workstation, a member server, a test user), capture the resultant set of policy:

gpresult /h C:\Temp\RSoP-before.html /f

Step 2: Inventory every setting

In GPMC, open Group Policy Objects > Default Domain Policy > Settings, then choose show all. Work through DDP-before.html and list every configured setting in a tracking sheet with three columns: setting, target GPO, owner.

Step 3: Classify and confirm ownership

Sort each setting with the table in What stays and what moves. For any setting nobody can explain, find its owner before deciding; do not delete it during this change. Unknown settings can move to a holding GPO such as Domain - Legacy Review and be retired later.

Step 4: Build the new GPOs (unlinked)

The fastest path for large security sections is to copy the DDP and strip the copy down to one purpose:

Copy-GPO -SourceName "Default Domain Policy" -TargetName "Domain - Security Baseline"

Edit the copy and remove everything outside its purpose, including Account Policies, so password and lockout are defined only in the DDP. For small areas (drive maps, printers), create a blank GPO with New-GPO -Name "Users - Drive and Printer Maps" and recreate the items. Do not link anything yet.

Step 5: Pilot

  1. Make a test copy of the cleaned DDP: Copy-GPO -SourceName "Default Domain Policy" -TargetName "TEST - DDP Cleaned", then strip it to Account Policies only.
  2. On the pilot OU, enable Block Inheritance so the production DDP does not apply there.
  3. Link TEST - DDP Cleaned and the new GPOs to the pilot OU.
  4. Run gpupdate /force on pilot clients, sign in as a pilot user, and run gpresult /h C:\Temp\RSoP-pilot.html /f.
  5. Compare RSoP-pilot.html with RSoP-before.html. The only expected differences are the names of the winning GPOs.

Block Inheritance also blocks any other domain-root GPOs; if some are marked Enforced they still apply, so note them before comparing.

Step 6: Cut over in production

  1. Link each new GPO to its production target (domain root or the relevant OUs). At the domain root, keep the DDP at link order 1. Settings now exist in two places with identical values, which is harmless.
  2. Wait for AD and SYSVOL replication to complete on all domain controllers.
  3. Edit the Default Domain Policy and delete every setting outside Account Policies.
  4. Reset any Security Filtering on the DDP so Authenticated Users has Read and Apply, and remove any WMI filter from it.

Step 7: Tidy up

Unlink and delete TEST - DDP Cleaned, remove Block Inheritance from the pilot OU, and add a comment to the DDP (GPO Details tab) stating that it holds account policies only.

Get-GPOReport -Name "Default Domain Policy" -ReportType Html -Path "$path\DDP-after.html"

Verification

The cleanup is done when the DDP report shows only Account Policies and clients’ resultant policy matches the pre-change capture.

  • DDP-after.html lists only Password, Account Lockout and Kerberos policy.
  • net accounts /domain on a member computer shows the expected password and lockout values.
  • gpresult /h C:\Temp\RSoP-after.html /f on the same sample clients matches RSoP-before.html, apart from winning GPO names.
  • Every DC reports the same DDP version: in GPMC, Default Domain Policy > Status tab, run Detect Now to confirm AD and SYSVOL versions are consistent.
  • No new Group Policy errors (Event IDs 1058, 1030, 1096) in the System log on sample clients.
  • Help desk sees no tickets for missing drives, printers or blocked applications in the 48 hours after cutover.

Rollback

Restore the DDP from the Step 1 backup; this puts every original setting back in one command and leaves the new GPOs in place (their duplicate values are harmless).

Restore-GPO -Name "Default Domain Policy" -Path "C:\GPOBackups\DDP-yyyyMMdd"

For a problem limited to one area, unlink only the new GPO for that area and restore the DDP from backup, or re-add the single missing setting to the new GPO.

Last resort only: if the DDP is corrupt and no backup exists, dcgpofix /target:Domain recreates it with default settings. Afterwards you must re-enter your password, lockout and Kerberos values by hand.

Common pitfalls

PitfallWhat happensHow to avoid it
Deleting from the DDP before linking the replacementClients lose settings at the next refresh (about 90 minutes)Link the new GPOs first (Step 6.1), then strip the DDP
Tattooed settingsRegistry values written outside the Policies keys, and some Security Settings, stay on clients after the GPO stops applyingMoving a setting is safe; only removing it entirely needs an explicit “undo” value
Preferences without “Remove this item when it is no longer applied”Drive maps and shortcuts remain on clients if the item is deleted rather than movedMove the item intact; tick the option before any future removal
Password policy set in an OU-linked GPOIt does not change domain account passwords, only local accounts on computers in that OUUse Fine-Grained Password Policies for group-specific rules
Account Policies left in the copied GPOTwo GPOs at the domain root define password policy and precedence decides which winsRemove Account Policies from every copy made with Copy-GPO
Security filtering or WMI filter on the DDPSome objects silently miss account policyAuthenticated Users: Read + Apply; no WMI filter
Unhealthy SYSVOL replicationDCs disagree on the DDP version and clients get inconsistent results