0X00002097

Fix ERROR_DS_CLASS_NOT_DSA (0X00002097) in Active Directory

Windows Errors Intermediate 👁 8 views 📅 May 27, 2026

This error pops up when you try to add an object to a directory partition, but that object isn't a Domain System Agent (DSA). Here's how to fix it fast.

What you're looking at

You're getting ERROR_DS_CLASS_NOT_DSA (0X00002097) when you try to create or modify an object in Active Directory. The exact message is: "The object must be of class DSA." That sounds cryptic, but it's pretty specific: you're trying to add an object (like a user, computer, or group) to a partition that only holds domain controllers (DSAs).

This usually happens in two situations:

  • You're running a script or tool that accidentally targets the Configuration or Schema partition with wrong object types.
  • You're manually adding an object via ADSI Edit and picked the wrong container.

I've seen this most often when someone tries to create a user under CN=Configuration or directly under a domain controller object. The fix is straightforward once you know where to look.

Before you start

You need at least Domain Admin rights to do these fixes. If you don't have them, get a colleague with those permissions logged in.

Fix 1: 30 seconds — check where you're creating the object

This is the simplest thing to rule out. You're probably just putting the object in the wrong place.

  1. Open Active Directory Users and Computers (dsa.msc).
  2. Right-click the container you were trying to add to and select Properties.
  3. Look at the Object tab. Check the Object class field.

If it says domainDNS, organizationalUnit, or container, you're fine — that's a normal location for users and computers. If it says dMD or domainController or anything with "DSA" in it, that's your problem. Those containers only hold domain controller objects.

What to do: Move your object to a proper OU or the Users container. Right-click and choose New > User from a correct parent. If you were running a script, change the LDAP:// path to point to an OU.

After you do that, try the operation again. If the error goes away, you're done. Rest of this article is just backup reading.

Fix 2: 5 minutes — check your LDAP filter or script target

This fix is for when you're writing a PowerShell script or using a tool like csvde or ldifde to bulk-import objects. The error means your LDAP path is pointing at a DSA-only partition.

  1. Open ADSI Edit (adsiedit.msc). You'll need to install it from Remote Server Administration Tools if it's not there.
  2. Right-click ADSI Edit in the left pane and choose Connect to.
  3. In the Connection Point section, pick Select a well-known naming context from the dropdown. Usually you want Default naming context (that's your domain).
  4. Find the path your script is using. For example, LDAP://CN=Users,DC=yourdomain,DC=com is fine. LDAP://CN=Configuration,DC=yourdomain,DC=com is not.

If you see CN=Configuration or CN=Schema in your script's target path, that's why you got the error. Those partitions hold domain controller data and won't let you create users or computers.

Real-world example: A sysadmin ran this PowerShell to create a user:

New-ADUser -Name "TestUser" -Path "CN=Configuration,DC=contoso,DC=com"

That path targets the Configuration partition. The fix is to change the path to an OU, like:

New-ADUser -Name "TestUser" -Path "OU=Employees,DC=contoso,DC=com"

Run that corrected command and the error disappears.

Fix 3: 15+ minutes — clean up orphaned objects or permissions

This is the rare but stubborn case. Sometimes the error shows up even when you're targeting the right container. That happens when an object got orphaned (its parent was deleted) or when permissions are messed up, making the system think you're accessing a DSA partition.

  1. Open ADSI Edit as an administrator.
  2. Connect to Default naming context.
  3. Navigate to the OU or container where you're seeing the error. Expand the tree and look for any objects that show a red X or a warning icon.
  4. If you find one, right-click it and select Delete. Be absolutely sure it's not needed. Orphaned objects can confuse the directory service.

If that doesn't help, check the permissions on the container:

  1. Right-click the parent container in ADSI Edit, choose Properties.
  2. Go to the Security tab. You might need to click Advanced.
  3. Look for your user account or group. Make sure you have Create child objects permission. If it's missing, click Add, then select Create all child objects or a specific class like user.

Another obscure cause: a schema update failed halfway. You can check event logs for errors 1168 or 1084 under Directory Service in Event Viewer. If you see those, you might need to force a replication or temporarily move the object to a different domain controller.

Last resort: Restart the Active Directory Domain Services service on the domain controller where you're getting the error. From an elevated command prompt:

net stop ntds && net start ntds

This clears cached state. After it restarts, retry your operation.

When to call for backup

If none of these fixes work, you've got something nasty — maybe a corrupt schema class or a third-party tool that modified object classes. Open a case with Microsoft Support. Before you call, grab the exact error message, the LDAP path you're using, and a screenshot of the container's properties from ADSI Edit. That'll save you an hour on the phone.

But honestly? Nine times out of ten, it's Fix 1 or Fix 2. You're just putting the object in the wrong bin.

Was this solution helpful?

ERROR_DS_CLASS_NOT_DSA 0X00002097 Active Directory error DSA object class object must be of class DSA AD partition fix ADSI Edit LDAP error directory service error Windows Server AD domain controller issue