Dcgpofix: Safely Reset the Default Domain Policy and DC Policy

The dcgpofix command recreates the Default Domain Policy and the Default Domain Controllers Policy in the state Windows creates them in when a new domain is built, which makes it the recovery tool of last resort when either GPO is corrupted, deleted or damaged beyond repair. It is quick and built into every domain controller, but it discards every change ever made to those two GPOs, so this guide covers what it resets, what it never restores, and how to back up and re-apply your settings around it.

Short answer: Back up all GPOs with Backup-GPO -All -Path C:\GPOBackup. If a usable backup of the damaged GPO exists, restore it with Restore-GPO instead. Only when there is no backup, sign in to a writable domain controller as a Domain Admin and run dcgpofix /target:domain (or /target:dc), confirm the prompts, then immediately re-apply your password, lockout and Kerberos settings, and your domain controller user rights and audit settings.

Which method to use

Dcgpofix is one of several ways to recover a default GPO, and usually not the first choice.

Method	When it fits	Keeps custom settings	Risk
Restore-GPO from a GPMC backup	A recent backup exists; GPO damaged or deleted	Yes, as of the backup	Low; links are not restored for deleted GPOs
Import-GPO into the existing GPO	Settings are wrong but the GPO object is healthy	Yes, as of the backup	Low; GUID and links unchanged
Edit the GPO in GPMC	A few bad settings are known	Yes	Lowest
Fix SYSVOL replication	GPO differs between DCs, event 1058 on clients	Yes	None to the GPO itself
dcgpofix	No usable backup; GPO missing, corrupted or ACLs destroyed	No: everything returns to defaults	High for the DC policy (user rights)

If AD or SYSVOL replication is failing, fix that first. Running the rebuild on one DC while replication is broken produces a policy that other DCs never receive, or that later gets overwritten.

Prerequisites

• Membership of Domain Admins in the affected domain.
• An elevated command prompt on a writable domain controller (not an RODC) that holds a healthy copy of SYSVOL. Running it on the PDC emulator keeps the change on the DC that GPMC edits by default.
• Healthy replication: repadmin /replsummary without errors, and dfsrmig /getglobalstate reporting Eliminated.
• The fixed GUIDs of the two default GPOs, which dcgpofix reuses:
  • Default Domain Policy: {31B2F340-016D-11D2-945F-00C04FB984F9}
  • Default Domain Controllers Policy: {6AC1786C-016F-11D2-945F-00C04fB984F9}

Diagnose the damage first

Confirm what is actually broken before you reach for a rebuild. Each GPO has two halves: the Group Policy Container object in AD (CN={GUID},CN=Policies,CN=System,DC=contoso,DC=com) and the Group Policy Template folder in SYSVOL. Check both:

Get-GPO -Guid 31B2F340-016D-11D2-945F-00C04FB984F9
Get-ADObject -Identity "CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com" -Properties versionNumber, gPCFileSysPath
Test-Path "\\contoso.com\SYSVOL\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\GPT.INI"
Get-GPPermission -Guid 31B2F340-016D-11D2-945F-00C04FB984F9 -All

Typical findings and what they point to:

• AD object present, SYSVOL folder missing on one DC only: a replication problem. Fix DFSR, do not run a rebuild.
• AD object present, SYSVOL folder missing everywhere: restore the folder from a backup with Restore-GPO; the rebuild is the fallback.
• GPO deleted in GPMC: restore it from a GPMC backup, which recreates it with its original GUID. The AD Recycle Bin can bring back the AD object, but not the SYSVOL files, so on its own it does not produce a working GPO.
• Permissions removed so nobody can edit or read the GPO: a Domain Admin can usually take ownership and repair the ACL in GPMC. If that fails and there is no backup, dcgpofix is the right tool.
• Settings wrong but the object is healthy: edit the GPO or import settings from a backup. A full reset is unnecessary.

What dcgpofix resets and what it does not

Microsoft describes the command as a tool that restores only the settings contained in the two default GPOs and does not touch any other GPO. The practical effect:

Item	After dcgpofix
Password, lockout and Kerberos policy in the Default Domain Policy	Reset to Windows defaults
User rights assignment and audit policy in the Default Domain Controllers Policy	Reset to Windows defaults
Security options, restricted groups, registry and file ACLs you added	Removed
Administrative Templates, scripts, software installation, folder redirection and Preferences in the default GPOs	Removed, not rebuilt
Delegation and security filtering on the two GPOs	Review afterwards; do not assume custom entries survive
Links on the domain root and the Domain Controllers OU	Not managed by dcgpofix; check they exist
Every other GPO, WMI filter, OU link and SYSVOL folder	Unchanged
Settings added by applications (Exchange, backup agents, SQL service accounts)	Lost if they were in the default GPOs

This is why Microsoft’s best practice is to keep the Default Domain Policy for account policies only (password, lockout, Kerberos) and the Default Domain Controllers Policy for user rights and audit policy only. Everything else belongs in separate GPOs, where a dcgpofix run cannot erase it.

Step 1: Back up and document first

Even a damaged GPO usually holds settings you want to know about later. Take backups and reports before anything changes:

Import-Module GroupPolicy
New-Item -ItemType Directory -Path C:\GPOBackup -Force
Backup-GPO -All -Path C:\GPOBackup -Comment "Before dcgpofix"
Get-GPOReport -Name "Default Domain Policy" -ReportType Html -Path C:\GPOBackup\DDP.html
Get-GPOReport -Name "Default Domain Controllers Policy" -ReportType Html -Path C:\GPOBackup\DDCP.html
Get-ADDefaultDomainPasswordPolicy | Out-File C:\GPOBackup\password-policy.txt
secedit /export /areas USER_RIGHTS /cfg C:\GPOBackup\dc-user-rights.inf
auditpol /backup /file:C:\GPOBackup\dc-audit.csv

• The secedit and auditpol exports run on a DC and capture the effective user rights and audit policy, which is exactly what the Default Domain Controllers Policy is about to lose.
• If Backup-GPO fails on the damaged GPO, copy its SYSVOL folder instead. The security settings are in \\contoso.com\SYSVOL\contoso.com\Policies\{GUID}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf, a text file you can read later.
• Store the backup folder off the DC as well.

Step 2: Choose the target and switches

The syntax is:

dcgpofix [/ignoreschema] [/target:{domain | dc | both}]

Switch	Effect
/target:domain	Recreates only the Default Domain Policy
/target:dc	Recreates only the Default Domain Controllers Policy
/target:both	Recreates both (the default when /target is omitted)
/ignoreschema	Skips the schema version check

Always name the target explicitly. Resetting the Default Domain Controllers Policy when only the domain policy was broken removes user rights for no reason, and resetting the domain policy when only the DC policy was broken throws away your account policies.

By default, dcgpofix only runs when the AD schema version matches the Windows version it shipped with. After a schema update for a newer Windows Server release, running it from an older DC fails the check; /ignoreschema bypasses it. The preferred fix is to run it on a DC with the newest operating system in the domain, so the defaults it writes match the current schema.

Step 3: Run dcgpofix

1. Sign in to the chosen writable DC as a Domain Admin and open an elevated command prompt.
2. Run the command for the GPO you need, for example:
   

   dcgpofix /target:domain

3. Read the warning and answer Y to the confirmation prompts. The tool rewrites the GPO in AD and in SYSVOL, keeping the fixed GUID.
4. Force the change out to other DCs and check it arrived:
   

   repadmin /syncall /AdeP
   Get-GPO -Name "Default Domain Policy" | Format-List DisplayName, Id, ModificationTime, GpoStatus

For the domain controllers policy, the same flow applies with /target:dc. Plan it for a maintenance window, because services on DCs that depend on custom user rights can fail at their next restart.

Step 4: Re-apply account policies

After dcgpofix, the Default Domain Policy contains the Windows defaults. For the password policy these are a 24-password history, 42-day maximum age, 1-day minimum age, 7-character minimum length, complexity enabled and reversible encryption disabled. The lockout threshold is 0, which means accounts never lock. That is weaker than most organisations require, so put your values back straight away.

Option A: re-enter the values

Set-ADDefaultDomainPasswordPolicy -Identity contoso.com -MinPasswordLength 14 -PasswordHistoryCount 24 `
  -MaxPasswordAge 365.00:00:00 -MinPasswordAge 1.00:00:00 -ComplexityEnabled $true `
  -LockoutThreshold 10 -LockoutDuration 00:15:00 -LockoutObservationWindow 00:15:00

Use the values from password-policy.txt, not the example above. Set-ADDefaultDomainPasswordPolicy writes the domain object attributes directly; the Default Domain Policy will overwrite them at the next policy refresh on the PDC emulator unless the GPO holds the same values. Make the matching change in GPMC under Computer Configuration » Policies » Windows Settings » Security Settings » Account Policies so both agree.

Option B: import settings from the backup

Import-GPO -BackupGpoName "Default Domain Policy" -TargetName "Default Domain Policy" -Path C:\GPOBackup

This copies the backed-up settings into the freshly rebuilt GPO without changing its GUID or links. Only do this when the backup itself is trustworthy; if the corruption was inside the settings, re-enter them manually.

Kerberos policy

The Kerberos defaults are a 10-hour maximum user ticket lifetime, 7-day renewal, 600-minute service ticket lifetime and 5-minute clock tolerance, with user logon restrictions enforced. If you changed them, re-apply them under Account Policies » Kerberos Policy.

Fine-grained password policies (PSOs) live in the Password Settings Container, not in a GPO, so dcgpofix does not touch them.

Step 5: Re-apply domain controller user rights and audit policy

This is where most damage happens after dcgpofix. The rebuilt Default Domain Controllers Policy holds only built-in accounts in each user right. Compare against dc-user-rights.inf and put back what services need:

• Log on as a service and Log on as a batch job for backup agents, monitoring tools and service accounts running on DCs.
• Allow log on locally and Allow log on through Remote Desktop Services for any delegated admin groups you use.
• Manage auditing and security log for SIEM collectors or Exchange groups that had it.
• Deny rights you added for hardening, for example denying network logon to local accounts.

Edit them in Computer Configuration » Policies » Windows Settings » Security Settings » Local Policies » User Rights Assignment. For audit policy, if you used Advanced Audit Policy Configuration, restore it in the same GPO and check the result with auditpol /get /category:* on a DC.

Better still, move application-specific rights and your hardening into a separate GPO linked to the Domain Controllers OU. A second dcgpofix run then leaves them alone.

Check the links and delegation

Get-GPInheritance -Target "DC=contoso,DC=com"
Get-GPInheritance -Target "OU=Domain Controllers,DC=contoso,DC=com"
New-GPLink -Name "Default Domain Policy" -Target "DC=contoso,DC=com" -LinkEnabled Yes
New-GPLink -Name "Default Domain Controllers Policy" -Target "OU=Domain Controllers,DC=contoso,DC=com" -LinkEnabled Yes

Run New-GPLink only when the link is missing. The account policies in the Default Domain Policy take effect for domain accounts only when the GPO is linked at the domain root. Then check the Delegation tab: Authenticated Users must have Read and Apply group policy on the Default Domain Policy, and Enterprise Domain Controllers needs Read.

Exceptions and targeting

• Do not use security filtering or WMI filters on either default GPO to create exceptions. Account policies must apply to every DC, and a filter that skips one DC creates inconsistent password rules.
• For different password rules per group, use fine-grained password policies, which dcgpofix never touches.
• For per-DC differences in user rights, use an additional GPO linked to the Domain Controllers OU with security filtering, not edits to the default one.

Verify it works

1. On a DC, run gpupdate /force and gpresult /scope computer /r. Both default GPOs must appear under Applied Group Policy Objects.
2. Check the effective account policy: net accounts /domain and Get-ADDefaultDomainPasswordPolicy.
3. Check the SYSVOL copy on each DC matches: Get-GPO -Name "Default Domain Policy" -Server DC02 and compare the AD and SYSVOL versions.
4. Run dcdiag /test:sysvolcheck /test:netlogons and repadmin /replsummary.
5. On a member workstation, run gpupdate /force and confirm the System log has no GroupPolicy 1058 or 1030 errors.
6. Restart one service that relies on a custom right (for example the backup agent on a DC) and confirm it starts.

Troubleshooting

Symptom	Likely cause	Fix
dcgpofix refuses to run because of the schema version	Schema is newer than the DC’s operating system	Run it on a DC with the newest OS, or add /ignoreschema
Access denied	Not a Domain Admin, or prompt not elevated	Use an elevated prompt with a Domain Admins account
Password policy reverts to defaults later	Values set only with PowerShell, GPO still has defaults	Set the same values in the Default Domain Policy
Service on a DC will not start (logon failure)	“Log on as a service” right lost	Re-add the account in the DC policy or a separate DC GPO
Clients log event 1058 for the rebuilt GPO	SYSVOL not replicated to all DCs	Check DFSR backlog and repadmin; wait or fix replication
Password policy not effective at all	Default Domain Policy not linked at the domain root	Recreate the link with New-GPLink
Other GPOs look different afterwards	Coincidental change; the tool only touches the two default GPOs	Compare with the Step 1 reports

Roll back or undo

Dcgpofix has no undo switch. The Step 1 backup is your rollback:

Get-GPO -Name "Default Domain Policy"
Restore-GPO -Name "Default Domain Policy" -Path C:\GPOBackup
Restore-GPO -Name "Default Domain Controllers Policy" -Path C:\GPOBackup

Restore-GPO without -BackupId uses the most recent backup of that GPO in the folder. If you took several, list them with Get-ChildItem C:\GPOBackup and pass the backup ID. Restoring brings back the settings exactly as backed up, including any corruption they contained, so review the restored report before relying on it.

Afterwards, schedule regular GPO backups (for example a weekly Backup-GPO -All task) so the next recovery is a restore, not a dcgpofix rebuild. Keep the tool for the case it was designed for: default GPOs that are gone or unusable, with no backup to fall back on.

Dcgpofix at a glance

Official documentation: dcgpofix command reference, Backup-GPO (GroupPolicy module).

Related guides: Back up and restore GPOs with PowerShell · Fine-Grained Password Policy (PSO) in Active Directory: Easy 2026 Setup · Troubleshoot Group Policy not applying: gpresult, RSoP and Events 1058/1030.

Frequently asked questions

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts editorial team

Last full review

3 Oct 2026

Next review

1 Apr 2027

Sources

learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcgpofix
learn.microsoft.com/en-us/powershell/module/grouppolicy/backup-gpo