Tuesday, January 22, 2008

On Active Directory's Schema

I read an interesting comment today by Tyson Kopczynski over at Network World. A couple of highlights and my opinions:

Schema changes can actually be reversed, after all AD is based on LDAP. However, Microsoft prevents schema changes from being reversed.

Yes, how true and how silly. There are some architectural decisions that were made by some (now) Microsoft millionaires that never made sense to me. This is one of the biggies.

...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.

Definitely a best practice - test your schema update even if it is from Microsoft before updating your production forest.

I've seen so many customers our there run into schema problems. Worse, you still find many customers out there that are just simply afraid to extend their schema. Either way, test your schema, read Microsoft's guidance on the topic and consider a product like "Recovery Manager for Active Directory Forest Edition" which can protect you from that potential career limiting mistake.

Technorati Tags:
, ,


Gavin Henry said...

See AD/ADAM vs. LDAP (OpenLDAP and others)


TPS said...

This is why I encourage people NOT TO TRY THIS AT HOME (or in this case at work). It's disruptive and can have some serious side-effects. Use the existing schema in a virtual directory, extend the schema there. Then you don't have to worry about these issues.

I've posted some more comments here and like Gavin Henry suggested, read the white paper from the LDAP guys he refers to in his comment.

* Tim