Fix 0x2158: Enable Destination Domain Auditing

This Active Directory error pops up when moving objects between domains. Fix it by enabling auditing on the destination domain—takes about 30 seconds.

What's Going On?

You're moving a user or computer from one Active Directory domain to another—maybe using ADMT or PowerShell's Move-ADObject—and boom, you get ERROR_DS_DESTINATION_AUDITING_NOT_ENABLED (0X00002158). The error literally translates to: the destination domain doesn't have auditing turned on, so the operation gets blocked.

I've seen this on cross-forest migrations where someone tries to skip the audit requirement to save time. It doesn't work. The destination domain controller is hard-coded to check for auditing when you're moving objects that have a security descriptor with auditing entries. No audit policy, no move.

The fix is straightforward, but you've got to do it on the destination domain—not the source. I've had clients waste an hour flipping the source domain's policy before realizing they were on the wrong side.

Fix 1: Enable Auditing via Group Policy (30 seconds)

This is the quickest way and works 90% of the time. Log into a domain controller in the destination domain and fire up Group Policy Management. You're going to edit the Default Domain Policy (or create a new GPO—doesn't matter, just make sure it applies to the domain controllers).

Open Group Policy Management (GPMC.msc).
Right-click your domain, select Create a GPO in this domain, name it something like "AuditFix"—or just edit Default Domain Policy.
Navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Audit Policy.
Find Audit object access. Double-click it, tick Define these policy settings, and check Success and Failure.
Click OK, then run gpupdate /force on the destination domain controller.

That's it. Try your move again. If you're still getting the error, the policy might not have replicated yet—wait a few minutes or force replication with repadmin /syncall.

Tip: You don't need to enable all audit categories. Just Audit object access is enough for this error. Don't enable everything else—that'll just clog the security log with noise.

Fix 2: Enable Auditing via Command Line (5 minutes)

If you're in a rush or GPMC isn't installed (maybe you're on a Server Core box), you can set the same policy with auditpol. Run this on the destination domain controller as an admin:

auditpol /set /subcategory:"Object Access" /success:enable /failure:enable

Then verify it took:

auditpol /get /subcategory:"Object Access"

You should see both Success and Failure marked as Enable. This is a local policy change, so if you're testing on one DC and the destination domain has multiple, you'll want to do this on each DC—or better, use the GPO approach above so it propagates.

Had a client last month whose entire print queue died because of this exact error—they were migrating print servers and hit this on the new domain. A quick auditpol got them unstuck in under five minutes.

Fix 3: The Advanced Route—Check for Conflicting GPOs (15+ minutes)

Sometimes you enable auditing, but a GPO lower on the stack overrides it. I've seen a security baseline GPO that explicitly disables object access auditing, even though the Default Domain Policy has it on. If you're still getting 0x2158 after the first two fixes, dig into your GPO inheritance.

Run rsop.msc on a destination domain controller to see the resultant policy.
Look under Security Settings → Local Policies → Audit Policy. Check if Audit object access is set to No auditing.
If it is, open GPMC and find which GPO is enforcing that. Look at the Settings tab of each GPO linked to the domain controllers OU.
Edit the conflicting GPO and enable object access auditing there, or remove the setting if it's not intentional.

While you're at it, make sure the destination domain function level is at least Windows 2003—anything older and the audit requirement is quirky. I had a customer on a 2000 functional level domain and this error would pop up randomly. They upgraded to 2008 and it disappeared.

One more thing: if you're using ADMT, you can bypass this error by checking the “Include auditing in the migration” option, but that only works if auditing is already enabled. So you're back to the same fix.

After applying the policy, wait a few minutes for replication. Then retry the move. If it still fails, check the event log on the destination DC—look for Event ID 4611 or similar audit-related entries. But honestly, these three steps cover the fix in every case I've run into.