Fixing ERROR_DS_MISSING_INFRASTRUCTURE_CONTAINER (0X00002131)

Why This Error Happens

ERROR_DS_MISSING_INFRASTRUCTURE_CONTAINER is an Active Directory problem that shows up when the CN=Infrastructure object inside your domain's NC head is gone or corrupted. I've seen it most often after a botched domain controller demotion or when someone deleted the container by accident through ADSI Edit. It'll also pop up if you're promoting a new DC against a corrupted copy of the database.

The error code 0X00002131 translates to "the infrastructure container object is missing" — the DC can't find that container during LDAP binds or replication. You'll notice dcpromo fails, or repadmin /replsummary shows errors on this specific DC.

Cause #1: The Infrastructure Container Was Deleted or Never Created

This is the most common culprit. Someone (maybe a junior admin) opened ADSI Edit and deleted the CN=Infrastructure object under the domain partition. Or a replication conflict removed it. The fix is simple: recreate it manually.

Fix: Recreate the Container via ADSI Edit

1. Open ADSI Edit. Connect to the Default naming context (your domain DN, like DC=contoso,DC=com).
2. Navigate to: CN=Infrastructure,DC=contoso,DC=com. If it's missing, you'll see the error immediately.
3. Right-click the parent container (your domain DN) and choose New > Object.
4. Select infrastructureUpdate as the class (yes, that's the weird spelling — it's not a typo).
5. Set the value for CN to Infrastructure.
6. Leave all other attributes blank. Click Finish.

Once created, run repadmin /syncall /AdeP from an elevated command prompt to force replication. The error should clear on the next check.

Cause #2: Corrupted Active Directory Database

If the container exists but the error still shows, the NTDS database has corruption in the Infrastructure container's metadata. This usually follows an unclean shutdown or disk failure on the DC. Don't bother with chkdsk alone — you need to repair the database.

Fix: Repair the NTDS Database with ntdsutil

1. Reboot the DC into Directory Services Restore Mode (DSRM). Press F8 during boot and select it.
2. Log in with the DSRM admin account.
3. Open an elevated command prompt and run:

ntdsutil
activate instance ntds
files
integrity

This checks the database for corruption. If it finds issues, run:

repair

Let it finish — could take 30 minutes on a large database. After repair, exit ntdsutil and reboot normally. Then check the error again with repadmin.

If the repair fails, you're looking at a restore from backup. Sorry.

Cause #3: Replication Failing to Bring the Container Over

Less common, but I've seen it when a lingering object or a schema mismatch prevents the container from replicating from another DC. The container might exist on other DCs but not on the problematic one.

Fix: Force Replication from a Healthy DC

1. Identify a healthy DC in the same site. Run repadmin /showrepl on the broken DC to see partner connections.
2. Force replication inbound from a good DC:

repadmin /syncall /AdeP  

If that doesn't work, use ADSI Edit on the healthy DC to confirm the container exists. Export it with ldifde -f export.ldf -d "CN=Infrastructure,DC=contoso,DC=com". Then import that LDF file on the broken DC with ldifde -i -f export.ldf. This forces the container into the local database.

Quick Reference Summary

Tip: Always check event log ID 1925 or 1988 on the problematic DC — they often point straight to the missing container.