First of all, you shouldn’t do this. But in case you are hell bent on making a mess, the following steps allow some modifications that Active Directory would otherwise block.

The interesting bit is schemaUpgradeInProgress. It tells the DC to skip particular constraint checks while adding, updating or removing objects. It doesn’t switch off every access check or make every system-owned attribute writable; the AD technical specification identifies the constraints that honour it.

With LDP

  1. Use an account with the Change-Schema-Master control-access right on the schema naming context root. Schema Admins is the usual route in a lab; that specific right is what the operation checks.
  2. Launch LDP.exe, connect and bind to the intended DC.
  3. Open Browse > Modify.
  4. Leave the DN blank to target the root DSE. Put schemaUpgradeInProgress in the attribute field and 1 in the value field.
  5. Choose Add, click Enter, then Run.

schemamod

On Windows Server 2008 and later, this applies to that LDAP connection. Opening another tool or a second connection doesn’t inherit the setting. That’s easy to miss if LDP accepted the operation but your modification still fails elsewhere. Older Server 2003 behaviour was broader, applying it across the DC’s LDAP connections.

Once you’ve done whatever horrible thing you needed to do, return the same connection to normal: modify the root DSE again, using schemaUpgradeInProgress with value 0, and run it. Then close the connection.

Small but consequential spelling detail: it is schemaUpgradeInProgress both times. schemaUpdateInProgress was a typo in the original note.

Turning it off restores the checks for subsequent operations. It doesn’t undo any modifications already accepted, including changes that have replicated to other DCs.