Exchange 2010 SP2: The Value of Custom Attributes

If you browse the Microsoft article that lists the new features in Microsoft Exchange Server 2010 SP2 (What's New in Exchange 2010 SP2"), you'll find information about five new multivalued custom attributes. Custom attributes haveexisted in every version of Exchange since the product was first released in 1996, but they haven't really evolved until now. What are these customattributes, how are they used, and why has Microsoft chosen to update them now?

Microsoft originally designed custom attributes for use in the Exchange Directory Store (DS) because customers couldn't modify the DS. Differentorganizations required different things from the directory, and providing a set of custom attributes seemed like a good solution. In addition, whenMicrosoft launched Exchange, the new product needed to offer the same features as competing products, such as Digital Equipment's ALL-IN-1 Officesystem, which was the first email server to support customizable attributes in its directory.

Active Directory (AD) somewhat reduced this necessity by supporting a mechanism by which companies can extend the AD schema to add objects andattributes. But in practice, few companies extend AD, largely because they don't want to run the risk that Microsoft will overwrite or otherwisenullify their extensions in a future Windows release. Therefore, custom attributes are as valuable today as they were 16 years ago, even if thetechnology environment has changed dramatically.

Many Moons Ago

Figure 1 shows the first implementation of custom attributes in Exchange Server 4.0. Of course, 16 years ago, AD was still a blink in the eye of itsdevelopers, and Exchange boasted its own DS. The Exchange DS was modeled on the X.500 international standard and provided the basis for the eventualimplementation of AD in Windows 2000.

Figure 1: Exchange Server 4.0 custom attributes 

As you can see, Exchange originally allowed administrators to populate as many as 10 custom attributes for a mailbox. This limit existed betweenExchange 4.0 and Exchange 5.5 and was increased to 15 custom attributes when Exchange Server 2000 switched over to use AD. The AD schema updates thatwere required to support Exchange included the addition of the custom attributes. These attributes are simple text fields, each of which can store asmany as 1,024 characters. All versions of Exchange since Exchange 2000, including Exchange Online as deployed in Microsoft Office 365, support the sameset of 15 attributes for mailboxes, Distribution Groups (DGs-including dynamic DGs), mail-enabled users, and contacts. The current release of ExchangeOnline in Office 365 supports the new multivalued attributes as well.

Many Varied Uses

Over the years, administrators have found many varied and interesting uses for custom attributes. Common uses include the following:

All this data is essentially single-valued and is typically updated by being overwritten with a new value.

Accessing Custom Attributes

Before the advent of Windows PowerShell in Exchange Server 2007, the typical way for administrators to access custom attributes was through theExchange Management Console (EMC) or its predecessor. Brave individuals could also use a directory-centric utility such as LDP or ADSIEdit (as Figure 2shows) to manipulate custom attributes just like any other piece of AD data.

Figure 2: Custom attributes as viewed through ADSIEdit 

With the Exchange 2010 or Exchange 2007 EMC, you can view custom attributes for an object by selecting the object, viewing its properties, and thenclicking the Custom Attributes button to reveal the view that Figure 3 shows.

Figure 3: Viewing custom attributes with the Exchange Server 2010 EMC 

The Exchange Management Shell (EMS) makes custom attributes more powerful by making it easier to use these attributes to group and filter objects. TheEMS is also the only way that Office 365 administrators can access the custom attributes. The Exchange Control Panel (ECP) doesn't currently supportviewing or editing the custom attributes.

When you access mailboxes, groups, and contacts through the EMS, the custom attributes are available as CustomAttribute1 through CustomAttribute15.Thus, to get information about the value of all custom attributes for my mailbox, I can run this command:

Get-Mailbox -Identity "Tony Redmond" | Format-List CustomAttribute* 

As a more useful example, let's assume that we want to fetch information about all the employees who hold an MCSE qualification. For this example,we'll use CustomAttribute15 to store Microsoft accreditations, and we'll assume that someone has dutifully updated mailboxes with data about MCSEcertifications as certification holders have successfully passed exams. To find all the mailboxes, we can run this command:

Get-Mailbox -Filter {CustomAttribute15 -eq "MCSE"} 

Obviously, the ability to select a group of objects with one command is much better because it provides the basis to further process that group as awhole, such as creating a report about the objects. For instance, after I fetch the collection of mailbox objects that have MCSE stored inCustomAttribute15, I can create a report that lists all the names of the people who are MCSE-qualified in the organization.

New in Exchange Server 2010 SP2

Custom attributes have been a wonderful servant in many situations. However, their single-valued nature is a limitation when you want to store multiplevalues in a field. For example, "MCSE" is a pretty generic way to describe the accreditation; it's possible to be certified in many different Microsofttechnologies. It might be better to store values such as "Exchange", "SQL", "Windows", and so on. This was possible with the existing customattributes, but adding a new value to an existing list through code is problematic because you essentially must fetch the existing list, add the newvalue, and then write the new list back into the custom attribute.

The Microsoft solution is a set of five new multivalued attributes. These attributes are included in the AD schema extension that you need to installbefore deploying Exchange 2010 SP2. The EMC UI hasn't been updated to display the new attributes, so the only way that you can access them is throughthe EMS. Figure 4 shows how the new attributes appear when the EMS lists them with other mailbox attributes.

Figure 4: New custom attributes listed for a mailbox 

As you can see, the new attributes are named ExtensionCustomAttribute1 through ExtensionCustomAttribute5. Each attribute can store as many as 1,300values in a comma-separated list and is available for mailboxes, groups, and contacts. You manipulate the values by using a syntax that's beensupported since Exchange 2010 SP1. (See David Strome's blog  for further details.)

Let's see what happens in some examples. The same code works with both Exchange 2010 SP2 and Exchange Online. In fact, Exchange Online supportedmultivalued custom attributes well before the release of Exchange 2010 SP2. The change was introduced as part of the Microsoft approach of pushingfrequent incremental updates to its Office 365 platform.

Set-Mailbox -Identity "Tony Redmond" -ExtensionCustomAttribute1 @("Exchange", "SQL", "Windows 2008", "Windows 7")

I forgot that the user is a Microsoft IIS guru, too. Let's add that value:

Set-Mailbox -Identity "Tony Redmond" -ExtensionCustomAttribute1 @{add="IIS"}

Note that there's no need to specify the position of the value within the list or to remove the complete list and rewrite it. PowerShell takes care ofeverything for you. If you want to remove multiple values, simply express them in a comma-separated list. Exchange doesn't support the ability toupdate position-dependent data in place or to insert a new value into a list in a specific place, so if a value is position-dependent within a list,your code needs to follow the old approach of extracting the previous list, formulating the list with the new data in the correct location, and thenupdating the attribute with the list of values.

Although I used MCSE qualifications in this example, businesses can apply the same approach to use the new multivalued custom attributes to store listsof items. For example, you can use one attribute to store the ticket numbers of user-reported problems, using values such as Outlook/05-Jan-2012/15154.In this instance, the ticket number is 15154 and the problem was logged with Outlook on January 5, 2012. (Of course, ticket-tracking software isavailable for this purpose, so you probably won't use the attributes for this specific purpose-but it shows the possibilities.)

Putting Multivalued Attributes to Work

Inputting data is one thing. Using that data in an intelligent fashion is much more interesting.

Dynamic DGs are a great feature of Exchange. After being created, they should need a lot less maintenance than standard DGs, providing that theunderlying data is maintained in AD. As the name implies, each time someone sends a message to the group, Exchange dynamically resolves the recipientset by referring to AD. The magic is accomplished by applying a query against AD to generate a set of recipients that match the criteria expressed inthe recipient filter. As long as the data in AD is accurate, dynamic DGs work beautifully and save a heap of administrator time. There's no need to addmailboxes to the recipient list for typical DGs.

The following example creates a new dynamic DG called Exchange Gurus and specifies the recipient filter that Exchange executes to generate therecipient set:

New-DynamicDistributionGroup -Name "Exchange Gurus" -RecipientFilter {(RecipientType -eq "UserMailbox") -and (ExtensionCustomAttribute1 -like "Exchange")} 

The recipient filter in this example is pretty simple. Essentially, this filter says, "Find all user mailboxes that have the value Exchange stored inExtensionCustomAttribute1." Recipient filters are stated in OPATH format and can be much more complex than the query that's used in this example. (Formore information about how to build OPATH queries for use with Exchange, see the Microsoft article "Creating Filters in Recipient Commands."

The interesting thing is that Exchange automatically indexes data that's held in its custom attributes, so queries against these attributes are veryefficient. I use the "-like" operator here to catch values such as "Exchange" and "exchange". You can use the "-eq" operator (a little more efficientthan "-like") if you're positive that everyone who populates AD will use the same value.

To view the full recipient filter for a dynamic DG that Exchange uses to search AD, we can use a command such as this:

(Get-DynamicDistributionGroup "Exchange Gurus").RecipientFilter 

The bad thing about recipient filters is that you're never quite sure which recipient set will be resolved when Exchange queries AD. Fortunately, it'srelatively easy to check. First, we store the recipient filter in a variable; then we feed the filter into the Get-Recipient cmdlet to see whatExchange returns, as the following command shows:

$Set = Get-DynamicDistributionGroup -Identity "Exchange Gurus"Get-Recipient -RecipientPreviewFilter $Set.RecipientFilter 

Figure 6 shows the result. As you can see, we've found two well-known Exchange people who like to think of themselves as gurus.

Figure 6: Checking a recipient filter for a dynamic DG 

Save Time with Dynamic Distribution

Exchange has included custom attributes for a very long time. The changes introduced in Exchange 2010 SP2 make custom attributes a little easier tomanage and a better repository for data that you want to associate with mailboxes. Even better, you can save time by using the new custom attributes asthe basis for dynamic DGs.