How To (and how not to) access Custom Attributes using GetExchangeUser

The content of this blog stands true as of 13th of June, 2012. The behavior described towards the end of the article may be corrected through a subsequent product update.

Out-of-the-box Custom Attributes were introduced starting Exchange Server 2007 to save you the trouble of having to modify your Active Directory Schema, as you had to in Exchange 2003 and earlier, to store custom information against AD users, such as EmployeeID etc. that Exchange doesn’t already provide for.

Usage of these in-built Custom Attributes over ones added by extending the AD Schema come with many advantages, all of which are documented here: https://technet.microsoft.com/en-us/library/ee423541.aspx

You might come across many a situation where you need to fetch information stored in one of the Custom Attributes in your code that uses the Outlook Object Model or the Outlook Interop Assemblies.

Values of custom attributes (among other extended properties) can be easily be read through the PropertyAccessor member (https://msdn.microsoft.com/en-us/library/bb147680%28v=office.12%29) of the ExchangeUser object.

You would need to specify the Schema Names for each of the Custom Attributes, which would be of the format:

https://schemas.microsoft.com/mapi/proptag/\<Property Tag>

The property tags for ExtensionAttribute1 to ExtensionAttribute10 can be found here: https://support.microsoft.com/kb/178553 but I’ve provided a code excerpt for you that fetches the values of all 15 custom attributes associated with the logged on user, below:

               Outlook.Recipient curUser = this.Application.Session.CurrentUser;
               ExchangeUser exchUserObj = curUser.AddressEntry.GetExchangeUser();
               String[] propNames = new String[] { "**https://schemas.microsoft.com/mapi/proptag/0x802D001F**",
                                                "**https://schemas.microsoft.com/mapi/proptag/0x802E001F**",
                                                "https://schemas.microsoft.com/mapi/proptag/0x802F001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8030001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8031001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8032001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8033001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8034001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8035001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8036001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8C57001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8C58001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8C59001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8C60001E",
                                                "https://schemas.microsoft.com/mapi/proptag/0x8C61001E" };

                           object resultCustomAttributes; //An array to retrieve the values stored in each of the 15 Custom Attributes
                           resultCustomAttributes = exchUserObj.PropertyAccessor.GetProperties(propNames);

Unfortunately, it isn’t a mere gaffe on my part that I’ve marked the first 2 schema names corresponding to ExtensionAttribute1 and ExtensionAttribute2. It so happens that the values of these 2 specific attributes seem to be inaccessible via OOM at the moment. I’ve tested this behavior against the latest patched builds of Exchange Server 2007 and 2010.

The issue seems to be confined to OOM alone, since the values of the 2 attributes can be read successfully using Extended MAPI (which can be verified using tools that make Extended MAPI calls such as MFCMapi).

If you happen to be using such an implementation and you’re observing the issue, I’d recommend that you avoid using ExtensionAttribute1 and ExtensionAttribute2, until the issue is resolved.

Cheers!