Direkt zum Hauptbereich

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:
image
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.
image
Figure 2. The Inframan company specific Address Lists
Also an Inframan specific Offline Address Book is created containing the earlier created Address Lists:
image
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:
image
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:
image
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:
image
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:
image
Figure 7. Address Lists for multiple companies in one Exchange organization
These Address Lists can be grouped together in different Address Book Policies:
image
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:
image
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.

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Office 2013 aktivieren via Kommandozeile

Wie man das neue Microsoft Office 2013 aktiviert via Kommandozeile, das werde ich euch in dem folgenden Beitrag Schritt für Schritt erklären. Gerade in grösseren Systemumgebungen in welchen die Clients und Standard Software automatisiert installiert werden, kann das sehr hilfreich sein und erspart einem viel Arbeit nach der Installation des Clients. Das Ziel sollte sein, möglichst viel zu automatisieren und soweit möglich, wenig noch händisch zu konfigurieren. Da kommt dieser Beitrag sicherlich nicht ungelegen. Die folgenden Befehle könnte man beispielsweise ganz einfach in eine MDT (Microsoft Development Toolkit) Umgebung mit einbeziehen oder auch mit anderer Software benutzen. Wichtig zu wissen ist, dass dies nur dann funktioniert, wenn Microsoft Office 2013 über das Internet aktiviert wird. Hat man einen eigenständigen Aktivierungsserver (KMS), funktioniert dies nicht. Zudem müssen die Befehle alle mit Administrator Rechte ausgeführt werden. Normale Benutzerberechtigungen genügen …

Windows Domain Controller: Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar

Zurzeit häuft sich (warum auch immer) das Problem dass nach einem Neustart eines Windows Domain Controllers bei der Anmeldung die Fehlermeldung „Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar“ kommt und eine Anmeldung so nicht möglich ist Das Problem ist hierbei das der Domain Controller im Active Directory Reperatur Modus (Abgesicherter Modus) startet. Am einfachsten lässt sich dieses Problem folgendermaßen beheben: 1) Anmeldung mit dem DSRM (Directory Services Restore Mode) / Verzeichnisdienstwiederherstellungskennwort Falls die Anmeldung nicht funktioniert kann man einen Workaround wie hier beschrieben durchführen. 2) Systemkonfiguration mittels msconfig.exe aufrufen

WSUS won’t uninstall or re-install

Hat heute ein Problem mit WSUS unter Windows Server 2008 R2 bei einem Kunden. Das Problem - die Clients konnten keinen Verbindung zum WSUS Server herstellen. Die Deinstallation wurde unerwartet beenden mit folgender Fehlermeldung: Attempt to un-install Windows Server Update Services failed with error code 0x80070643. Fatal error during installation  Die Lösung: I don’t like Windows Server Update Services (WSUS), but it’s the free alternative many companies select over the higher cost alternatives like Intune or Systems Center. So, today I had to repair a damaged WSUS installation. Turns out someone uninstalled SQL Server 2005 Express not realizing WSUS was using it. Now firing up the WSUS console just yielded an error complaining about the missing SQL database. So like any good troubleshootin IT guy the first thing I tried was to uninstall WSUS…sadly, however the product would not uninstall or re-install. Here’s how I finally got rid of it: [the problem] WSUS 3.0 SP2 is missing SQL serv…