Deep dive into rich coexistence between Exchange Forests (Part 3)

If you would like to read the other parts in this article series please go to:

 

 

 

Introduction

 

In part 2, we first established trust relationships between each forest th

 

en we configured cross-forest connectors in order to get mail flow working between each forest.

 

In this part 3 of this articles series, we’ll take things a step further. I’ll first take you through a walk down memory lane when it comes to Microsoft identity solutions supported by each version of Exchange server. Then I’ll show you the GALSync synchronization flow planned for this specific scenario.

 

Lastly, we’ll prepare each Exchange forest for global address list synchronization (GALSync) by creating a GALSync organizational unit (OU) in the root of the domain partition.

 

GALSync – A Walk Down Memory Lane

 

So in order to set up an automated unified GAL between two or more Exchange forests, it usually involved using a synchronization solution such as Forefront Identity Manager 2010 (FIM 2010) provided by Microsoft. FIM 2010 is the latest version of their synchronization solution which has had many names (MIIS, IIFP, ILM and now FIM) over the years.

 

It’s no surprise that a lot of Exchange administrators/consultants have become quite confused/frustrated, when it came to which Microsoft identity management solution they should use for their specific Exchange scenario.

 

Back with Exchange 2003, it was much easier. Back then, we had Microsoft Identity Integration Server 2003 (MIIS 2003) and then we had what many people referred to as a light version of MIIS 2003. This light version was called Identity Integration Feature Pack 2003 (IIFP 2003) and was a scoped down version of MIIS 2003. Since IIFP 2003 included the GalSync Management Agent (GALMA) that were used to synchronize Exchange objects as contact objects to another Exchange forest and it was free (no license requirements), IIFP was usually the preferred solution among Exchange administrators/consultants that had to provide a unified GAL experience for multiple Exchange forests.

 

When Exchange 2007 RTM was released things changed. Now we could use MIIS 2003, IIFP 2003, and ILM 2007 to synchronize Exchange mailbox users from an Exchange legacy organization to an Exchange 2007 organization as contact objects, but actually none of these solutions had native support for Exchange 2007 provisioning. You could use one of these versions for synchronizing Exchange 2007 users as mail-enabled contacts, but it required that you either customized the GALSync MA or performed a semi-manual post step when users had been synchronized. This was because these versions depended on the recipient update service (RUS) to perform two required tasks. RUS was responsible for setting the “LegacyExchangeDN” and “ShowInAddressBook” attributes on the mail-enabled contacts in the target organization. But since Exchange 2007 no longer uses RUS, you had to run the Set-MailContact cmdlet against the synchronized contact objects in the Exchange 2007 organization. See this KB article for a detailed explanation on this topic.

 

Then ILM 2007 FP1 was released and brought native support for Exchange 2007 provisioning to the ILM 2007 product (with ILM 2007 FP1 you could even provision Exchange 2007 Mailboxes if you wanted). This basically worked by installing the 32-bit version of the Exchange 2007 Management tools on the ILM server, and GalSync would then call the Update-Recipient cmdlet as part of the provisioning process.

 


Figure 1: GALSync configuration for management agent connected to an Exchange 2007 forest

 

When Exchange 2010 RTM released, we faced a new issue. Yes correct! We no longer had a 32-bit version of Exchange 2010 Management tools at our disposal, which means we couldn’t install the Exchange 2010 Management tools on an ILM 2007 FP1 server since ILM 2007 only existed in a 32-bit version.

 

Fortunately the next generation of ILM now under the Forefront umbrella and therefore renamed Forefront Identify Management 2010 (FIM 2010) fixed this issue by eliminating the requirement of having to install the Exchange Management tools on the synchronization server itself, and instead take advantage of the new remoting features included with PowerShell 2.0. More specifically, it would connect to a remote Exchange 2010 server and run the Update-Recipients cmdlet directly on the specified Exchange 2010 server. About a month before FIM 2010 RTM was released, the Microsoft Identify Management team also released a hotfix for ILM 2007 Feature Pack 1 that added this functionality to the ILM 2007 version.

 


Figure 2: GALSync configuration for management agent connected to an Exchange 2010 forest

 

It’s important to note though that Exchange 2007 cannot take advantage of the remoting features in Windows PowerShell 2.0. So if you have to synchronize Exchange recipients as contact objects to an Exchange 2007 forest, you still need to install Exchange 2007 Management tools on the synchronization server itself.

 

Note:
For detailed information around which Microsoft Identity Management solution is supported by Exchange 2003, Exchange 2007 and Exchange 2010, see this article that I maintain over on the Microsoft TechNet Wiki.

 

Configuring a Unified Global Address List (GAL)

 

So as you read back in part 1 of this articles series, we have a FIM 2010 server deployed in Exchange forest 1 (Exchange 2010 forest). It’s configured based on the instructions in the FIM 2010 documentation on Microsoft TechNet.

 

Only the FIM Synchronization service has been installed on the server, since we don’t require any of the features provided by the FIM service or FIM portals. Since we’re synchronizing mailbox user objects to an Exchange 2007 forest as mail-enabled user objects, the Exchange 2007 Management tools must also be installed on the FIM server. Exchange 2010 uses the remoting features in Windows PowerShell 2.0 and there only need Windows PowerShell 2.0 on the FIM server. Exchange 2003 uses the recipient update service (RUS) and therefore doesn’t have any requirements for a tool installed locally on the FIM server.

 

A conceptual diagram of the synchronization follow can be seen in Figure 3 below.

 


Figure 3: Conceptual diagram of the planned GALSync flow

 

As you can see we’re going to synchronize mailbox user objects as mail (Exchange 2003) and mail-user (Exchange 2010 and 2007) objects between Exchange 2010 and the two legacy Exchange forests. As mentioned earlier in this article, synchronization between Exchange 2003 and Exchange 2007 is not a requirement in this specific scenario and the configuration steps on how to do so are there outside the scope of this articles series.

 

Preparing Active Directory for Synchronization

 

Before be begin to create the FIM management agents, we need to prepare each Exchange forest by creating the organizational unit (OU) to which the contact objects from the FIM server should be synchronized.

 

To keep things simple, we will create an OU named “GALSync” in the root of each AD partition as shown in Figure 4, 5 and 6.

 

As you can see, we also have OU’s created based on departments within the company. These OU’s contains the mailbox users we wish to synchronize as contact objects to the other Exchange forests.

 


Figure 4: GALSync OU created in Exchange forest 1 (Exchange 2010 forest)

 


Figure 5: GALSync OU created in Exchange forest 2 (Exchange 2007 forest)

 


Figure 6: GALSync OU created in Exchange forest 3 (Exchange 2003 forest)

 

Okay the three Exchange forests are now ready for GALSync configuration.

 

This is the end of part 3. Until next time, have a good one.

 

If you would like to read the other parts in this article series please go to:

 

 

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top