Stop making unneeded Active Directory schema changes…

If you manage an Active Directory (AD) forest, schema changes may or may not be a touchy subject.  In my case it is.  I've seen too many AD schema changes that have gone haywire.  To better understand what I'm talking about lets first review a couple of facts about AD's schema:

  1. When a schema change is made, it impacts the entire forest.
  2. Schema changes are replicated to every DC.
  3. When you make changes to the schema, those changes cannot be reversed.
  4. When your forest is in Windows 2003 native mode, you can defunct attributes and classes.
  5. Defuncting a class or attribute does not remove the element from the schema.
  6. Defuncting only allows you to reuse ldapDisplayName, schemaIdGuid, OID and mapiID values of the defunct schema element.
  7. Defuncting a class or attribute does not affect existing instances of the class or attribute, it only prevents new instances from being generated.
  8. You cannot defunct an attribute if it is included in any class that has not been disabled.
  9. When making schema changes, OIDs and LinkID pairs must be unique.

Note:    Schema changes can actually be reversed, after all AD is based on LDAP.  However, Microsoft prevents schema changes from being reversed.  While, you could modify some permission in Windows 2000 and hack away, Microsoft corrected that issue in SP2 or SP3.  I just simply don't remember.

Anyhow, I'm providing this list to illustrate some very critical concepts when it comes to the AD schema in relation to changes that may be imposed upon it.  My goal by doing this is to hopefully, help people understand why a proper change control process should be in place for AD schema changes (hey here is one - Link).  In other words, be wary, of requests to make changes on the fly.  So, next time some developer at your company asks to be dropped into the Schema Admins group.  You might want to ask some questions or at last review what changes will be made.  Chances are, they don't even know and are just hacking their way through whatever project they are trying to complete.

If I haven't conceived you yet, let me try to make a better argument.  Microsoft has tons of code samples on MSDN.  There was one particular code sample that walked developers through making their very first LDF file to extend AD's or ADAM's schema (for some reason I can't find the link right now).  In the example were some OIDs.  What do you think most people that saw this example did?  Yes, copy, paste, modify and away they went without changing the OIDs.  At some point MS decided to use one of those OIDs (I believe it was the Windows Server 2003 schema update, again my memory is failing me tonight), and some people then had a hard time updating their schema.

Want another example?  Ok, one of our clients recently ran into a problem attempting to test the OCS schema update (yes, notice I used the word test).  While performing the test, in a lab environment, the update failed with a conflicting LinkID error.  After researching the issue, we found that another previous schema update (from a well known software vendor whose name I shall not mention) used a LinkID that was reserved for Microsoft (or maybe it was the other way around, we are still looking into this).  In other words, I would even scrutinize schema updates that come from well known sources, this includes Microsoft.

Hopefully, this post has been helpful...

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:
Must read: 10 new UI features coming to Windows 10