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 have existed in every version of Exchange since the product was first released in 1996, but they haven't really evolved until now. What are these custom attributes, 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. Different organizations required different things from the directory, and providing a set of custom attributes seemed like a good solution. In addition, when Microsoft launched Exchange, the new product needed to offer the same features as competing products, such as Digital Equipment's ALL-IN-1 Office system, 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 and attributes. But in practice, few companies extend AD, largely because they don't want to run the risk that Microsoft will overwrite or otherwise nullify their extensions in a future Windows release. Therefore, custom attributes are as valuable today as they were 16 years ago, even if the technology 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 its developers, and Exchange boasted its own DS. The Exchange DS was modeled on the X.500 international standard and provided the basis for the eventual implementation 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 between Exchange 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 that were required to support Exchange included the addition of the custom attributes. These attributes are simple text fields, each of which can store as many as 1,024 characters. All versions of Exchange since Exchange 2000, including Exchange Online as deployed in Microsoft Office 365, support the same set of 15 attributes for mailboxes, Distribution Groups (DGs-including dynamic DGs), mail-enabled users, and contacts. The current release of Exchange Online 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:
- Storing organization-specific information about users, such as badge numbers or location codes.
- Storing other important information that's associated with employees. Social Security numbers and other national taxation identification data are a bad choice; that kind of data should be secured properly and not made available to Exchange administrators. Some companies use these attributes to indicate whether an employee is a manager or occupies some other grade, whereas others use the attributes to store training information.
- Storing information to connect Exchange and other applications. Badge numbers or other employee identifiers are often used to provide a link between Exchange and other applications (e.g., HR systems) and are populated when a mailbox is set up for a new employee.
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 the Exchange Management Console (EMC) or its predecessor. Brave individuals could also use a directory-centric utility such as LDP or ADSIEdit (as Figure 2 shows) 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 then clicking 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. The EMS is also the only way that Office 365 administrators can access the custom attributes. The Exchange Control Panel (ECP) doesn't currently support viewing 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 MCSE certifications 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 a whole, such as creating a report about the objects. For instance, after I fetch the collection of mailbox objects that have MCSE stored in CustomAttribute15, 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 multiple values in a field. For example, "MCSE" is a pretty generic way to describe the accreditation; it's possible to be certified in many different Microsoft technologies. It might be better to store values such as "Exchange", "SQL", "Windows", and so on. This was possible with the existing custom attributes, but adding a new value to an existing list through code is problematic because you essentially must fetch the existing list, add the new value, 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 install before 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 through the 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,300 values in a comma-separated list and is available for mailboxes, groups, and contacts. You manipulate the values by using a syntax that's been supported 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 supported multivalued custom attributes well before the release of Exchange 2010 SP2. The change was introduced as part of the Microsoft approach of pushing frequent 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 of everything for you. If you want to remove multiple values, simply express them in a comma-separated list. Exchange doesn't support the ability to update 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 then updating 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 lists of 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 is available 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 the underlying data is maintained in AD. As the name implies, each time someone sends a message to the group, Exchange dynamically resolves the recipient set 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 in the 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 add mailboxes 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 the recipient 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 in ExtensionCustomAttribute1." Recipient filters are stated in OPATH format and can be much more complex than the query that's used in this example. (For more 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 very efficient. I use the "-like" operator here to catch values such as "Exchange" and "exchange". You can use the "-eq" operator (a little more efficient than "-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's relatively easy to check. First, we store the recipient filter in a variable; then we feed the filter into the Get-Recipient cmdlet to see what Exchange 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 to manage 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 as the basis for dynamic DGs.
