Fix ERROR_DS_DSA_MUST_BE_INT_MASTER (0x00002096) Fast

You're hitting this AD error and it's annoying. Let's fix it.

I've seen this one a lot — usually when someone tries to modify a schema attribute or transfer a FSMO role using ADSI Edit on the wrong domain controller. The culprit is almost always targeting a DC that doesn't hold the needed FSMO role for that specific operation.

What actually triggers this error?

You'll see it when:

• You run ADSI Edit and try to change a schema object on a non-schema master DC.
• You attempt to transfer a FSMO role via GUI or PowerShell but connect to an ordinary DC.
• A script or tool tries to modify the domain naming context without talking to the domain naming master.

Error message looks like: The operation can only be performed on an internal master DSA object. 0x00002096

The fix — connect to the right DC

Step one: figure out which FSMO role you need. Here's the short version:

Step two: find which DC holds that role. Run this on any DC:

netdom query fsmo

Or use PowerShell:

Get-ADDomainController -Discover -Service "[desired service]"

For schema master specifically:

Get-ADForest | Select-Object SchemaMaster

Step three: connect your tool to that DC.

If you're using ADSI Edit:

1. Right-click ADSI Edit in MMC, select Connect to.
2. Under Connection Point, choose Select or type a Distinguished Name or Naming Context.
3. Enter the right naming context (e.g., CN=Schema,CN=Configuration,DC=yourdomain,DC=com for schema).
4. Under Computer, pick Select or type a domain or server and type the DC hostname you got from the previous step.
5. Click OK. Now you're talking to the master.

If you're running a PowerShell command, add -Server <DCName> to the cmdlet. Example:

Get-ADObject -Server dc-schema-master.yourdomain.com -Filter * -SearchBase "CN=Schema,CN=Configuration,DC=yourdomain,DC=com"

Why this works

Active Directory is picky about who modifies core objects. The schema master is the only DC allowed to write to the schema partition. Same for domain naming master and the domain partition. This isn't a bug — it prevents corruption from conflicting writes. The error is AD's way of saying "you're not talking to the one guy who's allowed to do that."

Less common variations

• Cross-forest operations: If you're trying to modify a schema attribute in a different forest, you must connect to that forest's schema master. You can't do it from your own DC.
• Read-only DC (RODC): You'll never get this error on an RODC because they can't hold FSMO roles. But if you're trying to write a schema change through an RODC, you'll get a different error — just an FYI.
• Seized roles after crash: If a previous FSMO holder crashed and you seized the role, the metadata might still point to the old server. Run ntdsutil and use "metadata cleanup" to remove the old server. Then retry.
• PowerShell remoting: Running commands via Invoke-Command against a remote DC? The script runs in the context of that remote DC, not your local one. Make sure the remote DC holds the role, or specify the correct target server inside the script block.

Prevention for next time

Three things:

1. Always check FSMO roles before starting schema or domain-wide changes. Don't assume your default DC is the right one — especially if you have multiple DCs and a load balancer.
2. Use a naming convention for your tools. In ADSI Edit, save a connection point labeled "Schema Master" so you don't waste time later. Same with PowerShell scripts — hardcode the server name or parameterize it.
3. Document your FSMO role holders and run a weekly script to report any changes. If someone transfers a role without telling you, you'll know before it causes issues.

That's it. Connect to the right DC, do your work, move on. This error is one of the easier ones to fix — it's just a targeting problem.