Fix ERROR_DS_NO_MSDS_INTID 0x00002194 in AD Schema

Quick Answer

This error means the msDS-IntId pool is exhausted. You need to either extend the range via msDS-IntIdRange attributes or remove orphaned entries from the CN=Deleted Objects container.

Why This Happens

Active Directory assigns a unique msDS-IntId to every new object during schema updates. Think of it like a ticket number — each domain controller pulls from a shared pool. When the pool runs dry (usually because someone deleted a ton of objects without cleaning up the IDs, or the range was set too small at domain creation), the update fails with 0x00002194. I've seen this most often after a big bulk deletion of user accounts or when a third-party app like Exchange or Skype for Business tries to extend the schema and can't get a new ID.

The error shows up in the Directory Service event log as event ID 1699 or 1977, and the exact message reads: "Schema update failed: No values for msDS-IntId are available."

Fix Steps

Identify the current range. Open ADSI Edit (run adsiedit.msc), connect to the CN=Schema,CN=Configuration,DC=<yourdomain>,DC=<com> partition. Navigate to CN=ms-Exch-Schema-Update-Now or CN=msDS-IntIdRange — the exact path depends on your schema version. Look for the rangeUpper and rangeLower attributes. Default is usually 0–32768.
Check the used count. Run this PowerShell on a domain controller (run as admin):
```
Get-ADObject -Filter {msDS-IntId -like '*'} -SearchBase "CN=Schema,CN=Configuration,$((Get-ADDomain).DistinguishedName)" -Properties msDS-IntId | Measure-Object
```
Compare that count to your rangeUpper — if you're within 100 of the limit, that's your problem.
Extend the range. If you're sure you need more IDs, bump the upper limit. In ADSI Edit, double-click the CN=msDS-IntIdRange object (or the Exchange equivalent), set rangeUpper to 65535 (the max allowed). Click OK. Wait 15 minutes for replication, then retry the schema update.
Clean orphaned IDs (faster and safer). Open ADSI Edit, go to CN=Deleted Objects,DC=<yourdomain>,DC=<com>. Search for objects with msDS-IntId set — these are deleted objects still holding an ID. Right-click and delete them permanently. Then run repadmin /syncall /AdeP to force replication, and try the schema update again.
Check if Exchange is the culprit. If you see CN=ms-Exch-Schema-Update-Now anywhere, that's Exchange's range. You can delete that object (it's safe — Exchange recreates it) and let AD reassign IDs from the default pool.

Alternative Fixes

Reset the DSID counter. This is risky — only do this if you're stuck. Use ntdsutil: ntdsutil → metadata cleanup → reset DSID. This bumps the internal ID counter to the next available value. But it's a nuclear option — make a system state backup first.
Restore from backup. If you have a recent backup of the schema partition, restore it to a test DC first, then seize roles and restore production. Only do this if you can't extend the range and can't delete orphans.
Create a new domain controller and promote it. Sometimes a clean DC with a fresh schema gets you past the error. Then demote the old one.

Prevention Tips

Monitor msDS-IntId consumption monthly. I run a script that alerts when usage hits 80% of the range.
Never delete thousands of objects without cleaning up their attributes first. Use Remove-ADObject -Identity "<DN>" -IncludeDeletedObjects to purge them completely.
Set the initial rangeUpper to 65535 when you first create the domain — it's free performance-wise and saves you headaches later.
If you run Exchange, give it its own dedicated msDS-IntIdRange object with a high upper limit (like 50000) so it doesn't eat into the general AD pool.

Real-world example I dealt with: A client with 12,000 users deleted 8,000 stale accounts in one go. The next day, Exchange schema update failed with 0x00002194. We found 7,900 orphaned IDs in Deleted Objects. Purging them freed up the pool, and the update went through in 20 minutes. Extending the range wasn't needed once we cleaned house.

If none of this works, check the CN=Schema,CN=Configuration partition for any third-party application that might have its own msDS-IntIdRange object with a low cap. That's your bottleneck.