Exchange Extension Attributes – A Cautionary Tale

I had always been under the impression that the custom attributes introduced by the Exchange schema extensions were handy for all sorts of things.  Earlier this week I discovered that there are hidden dangers when using them for anything other than Exchange-related purposes.

When you prepare the schema for Exchange you will see, amongst others, 15 new attributes named extensionattribute1 to extensionAttribute15 (common name ms-Exch-Extension-Attribute-n).  These attributes are exposed via the UI tools, which makes them user-friendly to administrators and support staff.

These custom attributes have a Unicode string syntax, so you can store just about any information you might need in them.  They also form part of attribute set replicated via the Global Catalog and are indexed in AD.  All of these things make the attributes useful as generic “bucket” to store user or group-related information without the hassle of developing your own schema extensions.

As an example, Quest Migration Manager defaults to using two extension attributes (14 and 15) when it detects that the required Exchange schema extensions are in place.  QMM uses these as service attributes to support synchronisation and migration. 

Sounds perfect right?  Well I thought so until I discovered the other day the attribute values are blown away when mailbox-enabling or mailbox-disabling a user account.  For example, when you disable a mailbox it disconnects it from the parent AD user object and at the same time strips the user object of all its Exchange-related attribute value, including the extension attributes.  The Disable-Mailbox cmdlet does this silently and without warning – like a thief in the night!

It would be nice if Exchange could just leave these attributes alone.  The fact that they are subject to being summarily cleared means that (for me at least) they shouldn’t be used to store anything other than Exchange-related information.