Q. I have users in another forest who I want to have Exchange mailboxes in my Exchange organization. What are my options?

A. With many companies merging, many companies find themselves with multiple Active Directory (AD) forests. While consolidation is a goal, there can be a huge amount of work to consolidate AD forests when looking at all the computers, applications, and services that may be present. Often, consolidation is staged, with email one of the first services that's consolidated.

Once the decision to consolidate to Exchange in a single forest is made, there are always questions about how to achieve a single Exchange organization being accessed by users in multiple forests and what type of trusts are required between the forests. You have a number of options, but I'll look at a new one first that, while seemingly attractive initially, actually has very limited applications in the real world.

Exchange 2010 will support the use of Active Directory Federation Services (ADFS) for access to Exchange mailboxes. This means no trust relationships are required between the two forests. You still have to create a local AD user for each mailbox, but then you can use the federation to grant users access to the mailbox. Each forest would require one or more ADFS servers, but because ADFS is predominantly web-based today, users would only be able to access their mailboxes using Outlook Web Access. This is, therefore, not practical for most organization that want full client access.

Your second option is the more traditional trust-based scenario. The most typical arrangement is for the Exchange forest to trust all the account forests. Users have duplicate accounts in the Exchange forest that own the mailbox and the users' main accounts are given permissions on the mailbox, as shown below. While this does require a uni-directional trust, this is accepted in most organizations because the owners of the account forests aren't having to trust the Exchange forest—only the Exchange forest is doing the trusting. In this arrangement, the users in all the account forests connect to the mailboxes using their own accounts and passwords, so it has the least overhead. This is a commonly-used scenario and is widely battle tested as the best solution.

The above scenario raises a question: How do you create the duplicate accounts in the Exchange forest? In small environments, you can manually create a duplicate account and then set the permissions, but this won't scale for large environments. Imagine there are 50 account forests—how will the process work to manually alert you when accounts are created in all these different forests by different administrator groups? The solution is to use Identity Lifecycle Manager (ILM) or another identity management solution.

You would install ILM in the Exchange forest and then configure connectors to each of the account forests, specifying an account that had been delegated permissions to read agreed information from the account forests. Because you're specifying an account for each account forest, there are no additional trusts required, and the owners of each account forest can control the attributes that can be read by ILM. You would then use ILM to poll for new account creations in a source account forest and automatically create a matching account in the Exchange forest, create a mailbox and set the permissions appropriately. You could even have it fire off an email to the user's manager or IT representative letting them know the provisioning is complete. You can set up processes to de-provision and handle modifications, but at the most basic level, you can handle the mailbox account and mailbox creations.

One additional optional step is to place a DC from each account forest domain at the Exchange location. Doing this improves performance when looking at the token passing required when a user from one domain accesses a resource in another domain and also protects you from network connection failure between the Exchange forest location and the account forest locations. Because a local DC is present at the Exchange location, users would still be able to authenticate, even if the Exchange forest location loses connectivity with other locations.

There is a third option for consolidating, but it quickly becomes unworkable in most scenarios. Some organizations don't want any trust, which means you have to create an account for the user in the Exchange forest (as you do anyway). But then you set its password to be the same as the user's normal password (unless you want the user to have to handle multiple passwords, which quickly becomes an ugly user experience). As I discussed in a previous FAQ, ILM can perform password synchronization using the Password Change Notification Service (PCNS) that runs on each domain controller where passwords would be changed. The PCNS has to be in the same forest as the ILM server or there has to be a forest trust between the forests running PCNS and the forest where ILM is installed. Because you're trying to avoid trusts, you would actually have to install ILM into every account forest and then have those ILM instances create the accounts in the Exchange forest and push the passwords. In the scenario of 50 account forests, that means 50 ILM installations—which is hideous, as shown here.

The solution would be to implement forest trusts between the account forests and the Exchange forest, so ILM can be installed in the Exchange forest, for only one ILM instance. However, at that point why bother with PCNS? You have a trust, so just grant the users' main accounts permission to the mailbox and you don't need to worry about synchronizing passwords.

You'll probably also want to have the ability for ILM to populate the email information back into the users' main accounts in the account forest, so items like SMTP address are populated for the user. Permissions only to update mail related attributes in the account forest would be required, not complete administrator rights.

Don't forget that DNS forwarding will need to be in place ineach account forest so the Global Catalogs in the Exchange forest can be located and queried. You don't need to worry about creating contacts for all users in each account forest because the users are all accessing the same Exchange forest and therefore generating the GAL from the same GCs. If you want autodiscover to work for Outlook, you would also need to create the Service Connection Point (SCP) information manually in the Account forests AD to help post to the Client Access Servers.

Related Reading:

Check out hundreds more useful Q&As like this in John Savill's FAQ for Windows. Also, watch instructional videos made by John at ITTV.net.