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 DDP | Where it goes | Suggested GPO name |
|---|---|---|
| Password Policy | Stays in DDP | Default Domain Policy |
| Account Lockout Policy | Stays in DDP | Default Domain Policy |
| Kerberos Policy | Stays in DDP | Default Domain Policy |
| Security Options, Audit Policy, User Rights (non-DC) | New GPO linked at domain or workstation/server OUs | Domain – Security Baseline |
| Windows Defender Firewall rules | New GPO | Domain – Firewall |
| Drive maps, printers, shortcuts (Preferences) | New GPO linked at user OUs | Users – Drive and Printer Maps |
| Desktop, Start menu, Control Panel restrictions | New GPO linked at user OUs | Users – Desktop Settings |
| Software installation, AppLocker, Software Restriction | New GPO | Computers – Application Control |
| Windows Update / WSUS settings | New GPO | Computers – Windows Update |
| Settings on domain controllers only | Default Domain Controllers Policy or a DC-specific GPO | Domain 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:advertisingand 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
dcgpofixas 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" -NoTypeInformationOn 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 /fStep 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
- 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. - On the pilot OU, enable Block Inheritance so the production DDP does not apply there.
- Link
TEST - DDP Cleanedand the new GPOs to the pilot OU. - Run
gpupdate /forceon pilot clients, sign in as a pilot user, and rungpresult /h C:\Temp\RSoP-pilot.html /f. - Compare
RSoP-pilot.htmlwithRSoP-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
- 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.
- Wait for AD and SYSVOL replication to complete on all domain controllers.
- Edit the Default Domain Policy and delete every setting outside Account Policies.
- 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.htmllists only Password, Account Lockout and Kerberos policy.net accounts /domainon a member computer shows the expected password and lockout values.gpresult /h C:\Temp\RSoP-after.html /fon the same sample clients matchesRSoP-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
| Pitfall | What happens | How to avoid it |
|---|---|---|
| Deleting from the DDP before linking the replacement | Clients lose settings at the next refresh (about 90 minutes) | Link the new GPOs first (Step 6.1), then strip the DDP |
| Tattooed settings | Registry values written outside the Policies keys, and some Security Settings, stay on clients after the GPO stops applying | Moving 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 moved | Move the item intact; tick the option before any future removal |
| Password policy set in an OU-linked GPO | It does not change domain account passwords, only local accounts on computers in that OU | Use Fine-Grained Password Policies for group-specific rules |
| Account Policies left in the copied GPO | Two GPOs at the domain root define password policy and precedence decides which wins | Remove Account Policies from every copy made with Copy-GPO |
| Security filtering or WMI filter on the DDP | Some objects silently miss account policy | Authenticated Users: Read + Apply; no WMI filter |
| Unhealthy SYSVOL replication | DCs disagree on the DDP version and clients get inconsistent results |