Ex2007SP2 – step towards virtual directory … sort of

There are number of things in which my current employer managed to succeed. Among greatest success I think  one can count way in which Microsoft managed to scare people with Active Directory schema extension. Probably it has started somewhere down the road with Windows 2000 shipped, some communication, talks … but the fact is … people are scared to extend the schema in most part and some former communication from Microsoft has its part in this process.

There are several different implications of a fact that organizations are not willing to extend or modify its directories schema. One part is that sometimes it keeps consultant like myself busy ;). Other side of this equation is that some changes instead of being made in schema definition are hard coded in OS (example – SIDHistory preserved on a tombstone introduced with SP1).

After some discussion on my Polish blog we have extracted another problem with this attitude towards schema modification. Because customers are not very eager to extend the schema it slows down adoption of software which is doing this so developers are abandoning directory as a place where they can store data. Of course directory is not a dumpster and You should not keep all information in it but sometimes it does makes sense indeed.

But getting back on track with title of this post. I had some thoughts about it when I read description of new feature which is being introduced in Exchange 2007 SP2 (and consequently in later Exchange editions). It is called Dynamic Active Directory Schema Update and Validation and described on Exchange Team blog in this way:

The dynamic AD schema update and validation feature allows for future schema updates to be dynamic deployed as well as proactively preventing conflicts whenever a new property is added to the AD schema. Once this capability is deployed it will enable easier management of future schema updates and will prevent support issues when adding properties that don't exist in the AD schema

(cc) origamidon

Rather short description but today I read some communication which put some more light on it and I thought I will share my understanding of this feature here. So it looks like this new Exchange feature will do as follows:

• it will enable Exchange with knowledge that particular attribute in Active Directory is “dynamic” which from logical point of view will be closer to “optional” 
• If Exchange will try to read such attribute from directory where schema was not extended with it, driver used to read data from AD will just provide information as this attribute would exist with no value set for given object (<not set>)
• If Exchange will try to write to such attribute it will fail with some specific exception being returned.

What does it mean (or at least can) in practice. Potentially it will allow Exchange team to develop new features, released in hot fixes or rollups which might require schema extension which will also be provided. But customer will have a choice of deploying these extensions or not. Without it being deployed the feature will be inactive or will behave for given user as it would have some “defaults” set. But it will not prevent organization from deploying such update if schema extension would be what would hold it. Potential win-win situation from Exchange team and customer. Customer will be able to enable this feature later after extending the schema and starting to use it.

If this will be used in this way  … will see, maybe Exchange team has other purpose for this feature in minds.

From my perspective I think that this will increase a need for organization to take care about schema and its governance more carefully (what was deployed, what not etc).

But what this all has to do with virtual directory from this post title. Well not much, but this feature is very basic and simplified implementation of something which most of such virtual directories provides – dynamic schema extension. Of course virtual directories are not limited only to validation of schema upon reads and writes but this is something similar. I doubt that Exchange is about implementing such full blown solution but will see what will happen (at the end they have implemented RBAC for AD in Ex 2010 in some limited scope).

At the end it is not that bad. I would like to see such features to be developed and placed at directory service level or at least in Web Service for AD. This will be more coherent way of developing and deploying features around directory, but I’m not in charge to change this :). Will see in which direction such changes will go … one of my friends made a joke lately that soon we will have three OSs from Microsoft: Windows OS, Exchange OS and MOSS OS :).

PS. I’m wondering how many of you have my dear readers have in your organizations some procedures \ regulations around schema governance for AD? Comments are open.