Fix ERROR_DS_DUP_OID (0X000020BB) – Duplicate OID in AD Schema

Most Common Cause: A Duplicate OID Already Registered in the Schema

This error hits when you're running an LDIF or a schema extension (like for Exchange, Skype, or a third-party app) and the OID you're trying to add already exists on the domain. I've seen it most often with Exchange 2013 schema prep failing on a domain that had a previous partial prep. The error text says ERROR_DS_DUP_OID (0X000020BB) and the event log will usually confirm which attribute or class is the problem.

The fix isn't complicated: you need to find and remove or rename the conflicting OID. But you can't just delete schema objects through ADUC – you need the AD Schema snap-in or ADSI Edit.

1. Open ADSI Edit on a domain controller (run as admin).
2. Right-click and select Connect to. In the Select a well-known naming context drop-down, pick Schema and click OK.
3. Navigate to CN=Schema,CN=Configuration,DC=yourdomain,DC=com.
4. Look for the attribute or class that matches the OID in the error. If the error message doesn't show it, check the Event Viewer under Directory Service events – it'll mention the specific OID.
5. Right-click that object and choose Properties. Look at the attributeID or governsID (for classes). If you see your OID duplicated across two different objects, you have your culprit.
6. If the duplicate is a mistake (like from a failed previous attempt), you can delete the object – but be careful. Only delete if you're certain it's not used by any production app. If it's needed but has the same OID, you'll need to rename the OID to a new one (usually by changing the attributeID to a temporary unique OID like 1.3.6.1.4.1.999999.x).
7. Re-run the schema update. It should pass now.

Real-world story: Had a client last month whose entire print queue died because of this error. They'd run the Exchange 2013 schema prep on a domain that already had an old Lyris ListManager schema extension that had grabbed the same OID range. Took me 20 minutes to find the conflict in ADSI Edit, delete the orphaned attribute, and rerun the prep. Prints came back in 10 minutes.

Second Most Common Cause: Schema Cache Not Updated After Previous Changes

Sometimes the OID isn't actually a duplicate – the schema cache on the domain controller is stale. When you add a new schema object, the DC caches it. If you've made modifications to the schema (like deleting or renaming objects) and the cache hasn't refreshed, the DC thinks the OID is still in use.

This is more common on large domains with multiple DCs or after a schema master transfer. The fix is simple: force a cache reload.

1. Run this on the Schema Master DC (or any DC that's acting as the schema operations master):

reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v Schema Update Allowed /t REG_DWORD /d 1 /f

Then restart the Active Directory Domain Services service (or reboot the DC). The cache will rebuild.

2. After restart, re-run the schema update. If the error persists, you're dealing with a real duplicate (go back to Cause #1).

I've seen techs spend hours chasing OID conflicts only to realize a simple cache clean was all it needed. Don't skip this step – it takes 5 minutes.

Third Most Common Cause: Schema Update Allowed Registry Key Missing or Set to 0

Less common, but I've hit it. If the Schema Update Allowed registry key isn't set, the DC will reject any schema modification – and the error can get misinterpreted as a duplicate OID. This is a safety lock to prevent accidental schema changes.

Check the value on the Schema Master DC:

reg query HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v Schema Update Allowed

If it says 0 or the key doesn't exist, set it to 1:

reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /v Schema Update Allowed /t REG_DWORD /d 1 /f

Then restart the NTDS service. And don't forget to set it back to 0 after your schema update is done – leaving it open is a security risk.

Quick-Reference Summary Table