Fix 0xC01A0014: Log Policy Already Installed

The 30-Second Fix: Clear the Duplicate Policy with auditpol

This is the first thing to try. Open an admin Command Prompt (right-click CMD, Run as Administrator). Then run:

auditpol /clear /y

This nukes all audit policies and restarts the audit service. It's safe — the defaults come back immediately. If the error was caused by a stale policy that got applied twice, this wipes it.

After that, run gpupdate /force to reapply any domain policies. Then try your original operation again.

Doesn't work? Move to the moderate fix.

The 5-Minute Fix: Remove the Duplicate Policy from Registry

If the quick clear didn't help, there's a duplicate entry hiding in the registry. This is common on Windows Server 2016 and 2019 after a GP update goes sideways.

Open Regedit (admin) and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Policy

Look for any subkeys that have two entries with the same GUID. You'll see something like {0CCE922B-69AE-11D9-BED3-505054503030} — that's an audit policy GUID. If you see the same GUID twice under different policy names, one of them is the problem.

Delete the duplicate subkey. Be careful — only delete if it's a true duplicate. The safe way: export the whole Policy key first, then delete the suspicious entry. Reboot.

Still getting the error? Let's go deeper.

The 15+ Minute Fix: Auditpol and Group Policy Reset

This is for stubborn cases where the policy is baked into your local security policy or a domain GPO. Here's the process:

1. Open an admin PowerShell.
2. Run auditpol /list /subcategory:* to see what's installed. Look for duplicate GUIDs in the output.
3. If you see duplicates, run auditpol /remove /subcategory:"{GUID}" for each duplicate. Replace {GUID} with the real one.
4. Then run auditpol /backup /file:C:\auditpol_backup.csv to save current state.
5. Run auditpol /clear /y again.
6. Open secpol.msc (Local Security Policy) and go to Security Settings → Local Policies → Audit Policy. Check if any audit categories show as "No Auditing" — that's normal after a clear.
7. Close secpol.msc and run gpupdate /force.

If the error still appears, the problem might be in a domain GPO. Check the event logs for Application and System — look for Event ID 4719 (audit policy change) or 1102 (audit log cleared). That will tell you which GPO last applied the conflicting policy.

On a domain controller, run rsop.msc to see the resultant set of policy. Look under Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration. If you see the same audit subcategory listed twice, you found the culprit — a GPO that has both basic and advanced audit settings for the same category. That's the one to fix.

Why This Happens

The most common trigger: someone applies a GPO that uses the old Basic Audit Policy (secpol.msc) and then another GPO that uses Advanced Audit Policy Configuration (auditpol.exe). Windows doesn't handle the conflict well — it throws 0xC01A0014 instead of merging them cleanly. Seen this a lot on Server 2012 R2 and 2016.

Avoid It Going Forward

Stick to one method. Either use secpol.msc for everything or use auditpol.exe. Don't mix them inside the same GPO. If you need advanced auditing, disable the basic audit policy sections in the GPO first.

One more thing: if you're on Windows 10 1809 or newer, the error can also pop up when Windows Defender Application Guard tries to install its own log policy. In that case, disable Application Guard via Windows Features and reboot — then re-enable it cleanly.