Fix ERROR_DS_BAD_INSTANCE_TYPE (0x00002079) in AD

Cause 1: A domain controller was cloned or restored from a snapshot without proper preparation

This is the most common trigger. I've seen it dozens of times when someone restored a DC from a VM snapshot, or used a cloning tool that didn't run the proper Sysprep-like steps for domain controllers. The NTDS Settings object in Active Directory still holds the old instance type, but the server's actual role has changed.

Here's what you need to check and fix.

Step 1: Identify the problem server

Log into the server that's throwing error 0x00002079. Open Event Viewer and look for Directory Service events with this error code. The event usually names the object that's causing the problem. It looks something like: CN=NTDS Settings,CN=SERVERNAME,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=yourdomain,DC=com. Write down the full distinguished name.

Step 2: Check the current instance type

Open ADSI Edit (it's in the Remote Server Administration Tools under AD DS and AD LDS Tools). Connect to the Configuration naming context. Drill down to CN=Configuration,DC=yourdomain,DC=com → CN=Sites → CN=Default-First-Site-Name (or your site's name) → CN=Servers → CN=SERVERNAME → CN=NTDS Settings.

Right-click the NTDS Settings object and choose Properties. Scroll down to find the instanceType attribute. Double-click it. The value will be a number. Write it down.

• 4 = writable domain controller (normal DC)
• 2 = read-only domain controller (RODC)
• 1 = not a DC at all (typically from a botched demotion)

If you see 1 and the server is supposed to be a DC, that's your problem. If you see 2 and it's supposed to be a full DC, same issue.

Step 3: Fix the instance type with ntdsutil

The safe way is to use ntdsutil. Don't just edit the attribute in ADSI Edit unless you're absolutely sure—you can orphan the DC. Here's the command sequence:

1. Open an elevated command prompt (Run as Administrator).
2. Type ntdsutil and press Enter.
3. Type metadata cleanup and press Enter.
4. Type connections and press Enter.
5. Type connect to server yourdomaincontroller.yourdomain.com (use the fully qualified name of a working DC). Press Enter.
6. Type quit and press Enter.
7. Type select operation target and press Enter.
8. Type list sites. Note the site number.
9. Type select site X (where X is the site number from above).
10. Type list servers in site. Find the server with the bad instance type. Note its number.
11. Type select server Y (Y is that server's number).
12. Type list naming contexts. Note the number for the NTDS Settings object.
13. Type select naming context Z (Z is that number).
14. Type remove selected server. This will remove the NTDS Settings object from AD.
15. Confirm the removal.
16. Type quit until you're back to the command prompt.

After you've removed the NTDS Settings object, you need to re-add it. The easiest way is to just reboot the problem server. When the NTDS service starts, it recreates the NTDS Settings object with the correct instance type. After the reboot, check the error—it should be gone. You can verify by running dcdiag /test:replications /v and looking for any failures.

Cause 2: The server was moved between sites or renamed without updating AD

Sometimes you rename a server, or you move it to a different AD site, and the NTDS Settings object doesn't get updated. The instance type stays as a remnant of the old location. The error message will point to the old distinguished name.

Step 1: Verify the server's correct site membership

Open Active Directory Sites and Services. Expand your site tree. Check if the server appears under the right site. If it's in the wrong one, drag its server object to the correct site.

Step 2: Delete and recreate the NTDS Settings object

Right-click the server object in Active Directory Sites and Services. Choose Delete. Confirm you want to delete the NTDS Settings object. Wait a minute, then right-click the server object again and choose New → NTDS Settings. Follow the wizard. This recreates the object with the correct instance type based on the server's actual role.

After you do this, run dcdiag /test:replications on both the fixed server and another DC to make sure replication works.

Cause 3: A lingering replication conflict

This one's rarer, but I've seen it in environments with slow WAN links where replication is delayed by hours. Two DCs disagree about the instance type because one hasn't received the latest replication update. The error will appear intermittently.

Step 1: Force replication

On a working DC, open Active Directory Sites and Services. Expand the site where the problem server lives. Click on NTDS Settings under the problem server. In the right pane, right-click the connection object (usually a line to another DC) and choose Replicate Now. Watch for a success message.

On the problem server itself, run this from an elevated command prompt:

repadmin /syncall /AdeP

Wait a couple minutes. Then check the error again. If it's gone, the forced replication cleared the conflict.

Step 2: Check for lingering objects (tombstone issues)

If forced replication didn't help, run this:

repadmin /removelingeringobjects yourdomaincontroller.yourdomain.com DC=yourdomain,DC=com /advisory_mode

This lists all lingering objects without deleting them. If you see the NTDS Settings object for the problem server listed, you need to remove it. Run the same command without /advisory_mode:

repadmin /removelingeringobjects yourdomaincontroller.yourdomain.com DC=yourdomain,DC=com

Then do the same on the problem server, targeting a working DC. After removal, you'll need to recreate the NTDS Settings object as described in Cause 1, step 3.

Quick-reference summary table

Note: If none of these fix it, the server might have a corrupt AD database. Run ntdsutil → files → integrity to check. If it reports errors, you'll need to restore the DC from a healthy backup or demote and promote it fresh.