Currently Reading

I’ve been reading a great book on practical IT Management ‘things’ called The Windows Administration Resource kit (Amazon link here).  It provides a very practical look into some of the things you can do to your systems to bring additional value.  One of the things that has me intrigued is extending the AD schema to allow computers to be ‘assigned’ to people.  Now, before you roll your eyes and say ‘don’t ever touch the schema!!!’ let’s take a step back and consider for a second a few things.  1) The AD schema is just a database – albeit an important one to be sure.  2) Yes, once things are created they cannot be deleted – inactivated yes, but not deleted.  So why on earth would you muck around with it?  Well, for starters, that’s what it is for!  Consider:  only about 5% or something along that line of the schema is actually visible to AD Computers and Users – which is where most people live.  Open up ADSI Edit and there is a veritable TREASURE of additional ‘stuff’ in there that can help you do your job better.  It’s unfortunate that MS hasn’t made the interfacing to the schema easier, but I do understand the reason – it isn’t something for the faint of heart.  I suggest getting certified in AD before messing around with it – the potential to do damage is certainly real.

This leads me to today’s encounter with AD.  In Exchange 2010, there is an ability to uplift those pictures that you can see in the contacts card of Outlook directly into the GAL.  This is a great user experience aid.  This allows control over those pictures instead of just relying on, say, Facebook to bring those in for you with it’s contact importer.  Better in a corporate environment to have those centralized.  To do that requires mucking around with the schema, however.  If you aren’t immediately turned off by the idea, you can catch a great read on the Exchange Team blog on how to set this up here.  One common comment on the blog entry is that it is too hard for HR to manage this.  So, write a program that does it for you.  I’ve not yet done this but it can be described conceptually in this way:

1. Make sure you have delegated security of that object to the appropriate group, say EX-GAL-Pic-Updaters.  They will need at least edit permissions of the content of that object.
2. Write up a .Net tool that interfaces with that attribute using either the AD SDK stuff or I suspect you could get their with an authoritative bind.
3. Use the client credential cache to pass the credentials up to the AD when accessing the object.
4. Integrate your .Net tool with other HR LOB systems that hopefully you already have created to provision your users.

Another reasonable request would be to integrate this sucker with SharePoint.  This is even easier!  You’ll need to make sure that the users have the appropriate permissions to edit that field on their own object in the AD.  Then, go get yourself a tool (or build one using the Profile store in SharePoint).  An example tool can be found here or here.  Or you can build your own.  One way to do it would be to create an extension of Profile that allowed updating the AD property you just created to store the picture (making it a two way ‘synch’).  Another way to do it would be to write a custom web part that allowed the user to update the picture in AD directly and then the picture would flow back down to the profile store (if it’s mapped) during the next incremental import.  To make them both happen at the same time, your web part would just update both with the same image.  Easy as that!

Don’t be afraid of the schema.  Learn about its power and understand the risks, but it’s a great database.  Use it!