Fix STATUS_USER_DELETE_TRUST_QUOTA_EXCEEDED (0xC0000403)

Yeah, this one's a head-scratcher the first time you see it. You're trying to clean up an old trust—maybe a legacy domain from a merger or a test forest you spun up last year—and bam, STATUS_USER_DELETE_TRUST_QUOTA_EXCEEDED (0xC0000403). It looks like a permissions thing but it's actually a quota. Here's the real fix.

First, the quick fix (requires domain admin rights)

If you're a domain admin, you can bypass the quota entirely by assigning yourself the right to delete trusts for this specific domain. Open PowerShell as administrator on a domain controller or a machine with RSAT tools installed.

# This bumps your deletion quota on the target domain
Set-ADObject -Identity "DC=yourdomain,DC=com" -Replace @{'msDS-DeleteTrustQuota'=100}

Replace DC=yourdomain,DC=com with the distinguished name of the domain whose trust you're trying to delete. The value 100 gives you plenty of room—most orgs never hit that. If you're still blocked, try Set-ADObject with the -Server parameter pointing at the source domain's DC if the trust is cross-forest.

Now delete the trust using the normal GUI (Active Directory Domains and Trusts) or Remove-ADTrust in PowerShell:

Remove-ADTrust -Identity "OtherDomain.com" -Confirm:$false

That's it. The operation should succeed now. If it doesn't, double-check you're running as a user who's a member of Domain Admins in the target domain. The quota attribute is on the domain object itself, not on your user account.

Why this works

Microsoft introduced the msDS-DeleteTrustQuota attribute back in Windows Server 2003 as a safety measure. Without a quota, any delegated user with the right to create trusts could also delete them—potentially wreaking havoc. The default quota for non-admin users is zero. For domain admins it's effectively unlimited (the attribute doesn't apply), but the error still shows up if the trust is cross-forest and the source domain doesn't recognize your admin status.

Had a client last month who couldn't delete a trust between their production domain and a retired acquisition domain. They'd run the forest prep but the trust stuck around. This exact command fixed it in thirty seconds. The quota attribute just needed a nudge.

Less common variations of the same issue

Variation 1: You're not a domain admin

If you're delegated only specific permissions (like Account Operators or a custom role), you might still hit this quota. In that case, ask a domain admin to either delete the trust for you or temporarily add you to Domain Admins. The alternative is to have them assign you a higher quota via the same cmdlet—but honestly, delegating trust deletion is risky unless you have tight change control.

Variation 2: The error appears when creating a trust

Rare, but it happens. The same quota attribute can also block creation if the domain has been configured with a zero or very low quota. The fix is identical: bump msDS-DeleteTrustQuota. Yes, the attribute name says "delete" but it governs both create and delete operations for delegated users. Go figure.

Variation 3: The trust is in a different forest

Cross-forest trusts often throw this error even if you're a domain admin in both forests. The issue is that the Set-ADObject command must target the domain where the trust object lives. For a forest trust, that's the forest root domain. Use -Server to point at a DC in that forest's root:

Set-ADObject -Identity "DC=otherforest,DC=com" -Replace @{'msDS-DeleteTrustQuota'=100} -Server "DC01.otherforest.com"

Prevention going forward

Once you've cleaned up the rogue trust, set a sane default quota for delegated users. You can do this with Group Policy or a startup script, but the simplest way is to set a baseline on every domain object in your forest:

Get-ADDomain | ForEach-Object { Set-ADObject $_.DistinguishedName -Replace @{'msDS-DeleteTrustQuota'=10} }

This gives delegated users enough slack to clean up orphaned trusts (I've seen test labs leave 3-4 behind) without letting them nuke your whole trust topology. Keep an audit log of trust deletions via PowerShell logging or an event subscription pulling Event ID 1644 from domain controllers.

One last thing: don't confuse this with the more common STATUS_TRUST_FAILURE (0xC000004DC). That error means the trust itself is broken, not that you've hit a quota. If you see 0xC0000403, you know it's quota-related. Saves a lot of head-scratching.