New in Exchange 2010 SP2: Address Book Policies

In Exchange 2010 Service Pack 2 a new feature will be available called Address Book Policies which makes it possible to use multiple Address Books in Exchange 2010, completely separated from each other. It is sometimes referred to as multi-tenancy for Exchange 2010 although this is not entirely true. In this article I’d like to explain a bit more.

Address List Segregation

For Exchange 2007 Microsoft has a whitepaper available that describes how to implementAddress List Segregation to achieve multiple Address Lists completely invisible from each other. In other words, users in the Contoso.com Address List don’t see other Address Lists and users, like the Fabrikam Address List or the Tailspintoys Address List. In Exchange 2007 this is implemented using Access Control Lists (ACL’s) to set permissions for specific Address Lists. This works fine for Exchange 2007 but Exchange 2010 uses a different technique called the Address Book Service running on the Client Access Server. Therefore, if using (or trying to use) the Address List Segregation whitepaper on Exchange 2010 things will horribly break.

Address Book Policies

In Exchange Server 2010 Service Pack 2 the Address Book Policies (ABP’s) are introduced. Using ABP’s it is again possible to implement Global Address List (GAL) segmentation in Exchange Server 2010. But instead of setting all kinds of ACL’s in Active Directory an APB is an assignment of one or more Address Lists to a specific mailbox. It is now possible to create multiple ‘organizations’ within one Exchange 2010 environment that have independent Address Lists, completely separated from each other. For example, the Contoso and the Inframan company can be using one Exchange 2010 environment and use their own company specific Address Lists, assigned via ABP’s:

Figure 1. Contoso and Inframan using their own Address Lists via ABP’s

Let’s have a look at the following example. In this Exchange environment the following objects are created for Inframan organization:

• Global Address List; 
• Address List containing all Inframan Recipients;
• Address List containing all Inframan Contacts;
• Address List containing all Inframan Distribution Groups;
• Address List containing all Inframan Resource (Room) Mailboxes.

Figure 2. The Inframan company specific Address Lists

Also an Inframan specific Offline Address Book is created containing the earlier created Address Lists:

Figure 3. The Inframan company specific Offline Address Book.

The next step is to create an Address Book Policy containing the company specific Address Lists and Offline Address Book. In Service Pack 2 a new tab is added to the Exchange Management Console (under Mailbox in the Organization Configuration). Create a new ABP and add the various Address Lists that were created earlier:

Figure 4. The Inframan specific Address Book Policy containing the Inframan Address Lists.

When finished the new ABP shows up in the Exchange Management Console:

Figure 5. The new ABP showing up in the Exchange Management Console. Notice the new Address Book Policies tab.

The last step is to add the policy to the inframan Mailboxes. When selecting the Mailbox Settings of a mailbox in Exchange 2010 Service Pack 2 a new option is added for assigning the Address Book Policy. This way the new policy can be added to a particular user:

Figure 6. Adding the new ABP to a particular mailbox.

The user can now only see the Address Lists that are assigned to him using the Address Book Policy. With only one ABP this is not too exciting of course, so multiple Address Lists can be created for specific groups of users. Suppose multiple companies use this Exchange environment (I deliberately do not use the word hosting here, I’ll get back to that later on) and each company has its own Address Lists:

Figure 7. Address Lists for multiple companies in one Exchange organization

These Address Lists can be grouped together in different Address Book Policies:

Figure 8. Each company has its own Address Book Policy

These company specific Address Book Policies are now assigned to users of the individual companies. When logging on as a user for example in the Inframan company only the Inframan specific Address Lists (and thus mailboxes) are visible. None of the other Address Lists and mailboxes available on this particular Exchange environment show up at all:

Figure 9. Only the Inframan mailboxes and address lists are available for the inframan user

Cross organization Address List membership

APB’s are extremely flexible. Since an ABP is only a policy presented to the Address Book Service on the Client Access Service it is possible to manipulate its behavior a little bit. You can use specific attributes in the Address Lists for example to have mailboxes included in multiple Address Book Policies, something that was not possible with earlier solutions for GAL segmentation. So, you can have a manager appear in Address List One of company one, but at the same time this manager can also appear in another Address List from another company. If this is on purpose, for example when this manager works for both companies, than it’s not an issue of course but you have to be aware of this when using Distribution Groups. The Exchange transport service sends e-mail to all members of a Distribution Group and doesn’t use Address Book Policies.

You might end up sending e-mail to Distribution Groups including people you don’t want your message sent to!

Hosting and Multi-Tenancy

Quite a lot of people now think of Exchange Server 2010 Service Pack 2 being native multi-tenant because of the Address Book Polices. That’s not true! ABP is only part of a multi-tenant solution. For a multi-tenant solution, something that can be used by hosting companies a lot more configuration needs to be done. For example, you have to:

• Make sure that users from one tenant can only see and access resources from their own tenant using any tool. Using Outlook or OWA this is not an issue, but think about a hosting solution with Remote Desktop and a user get access to ADSIEdit;
• Routing needs to be consistent between tenants. You don’t want users in one tenant to see the Exchange LegacyDN when sending and resolving messages. Or when a mailbox is deleted from one tenant and a user in another tenant replies to a message that as sent earlier by the deleted mailbox;
• Users from one tenant should not be able to overload the messaging infrastructure, so some kind of throttling need to be available;

Microsoft will work with some hosting System Integrators to write guidance for hosting providers to achieve all this (and more). At the same time Microsoft is working with Control Panel vendors (as mentioned in my blog Exchange /hosting discontinued) to make sure the Control Panel vendors all support these technologies. If the guidance is followed or one of these Control Panel vendors is used a fully supported hosted Exchange 2010 is created.