Background

I’ve been working with a customer to prepare for the consolidation of two AD Forests into a single forest.  This involves the migration of all objects from one forest into the other and includes Exchange migration.  Due to a restricted budget we decided to opt for the Microsoft toolset to assist with the migration, rather than look at expensive 3rd party options.  Without going into too much detail, here’s the basic setup:

Migration Toolset

• ADMT v3 – for AD object migration
• Exchange Migration Wizard – for Exchange mailbox migration
• Identity Integration Feature Pack (IIFP) – for GAL Synchronisation
• Inter-Organization Replication tool – for public folder and free/busy replication.

The SMTP Address Space Issue

Only one Exchange Organisation can be authoritative for an SMTP address space (e.g. north.com).   This has both a limitation and a benefit.  The limitation is that it makes it difficult for users to maintain their SMTP addresses in a migration scenario.  On the plus side, having an authoritative destination means that the SMTP servers know where to route messages for correct delivery.  For the migration of north.com mailbox-enabled users it became an issue as we need to maintain existing @north.com addresses for all mailbox-enabled users and to ensure message routing works correctly.

 The SMTP address space issue is described in more detail in this article:

http://www.windowsconnected.com/blogs/aubrey/archive/2006/11/30/migrating-exchange-2003-from-one-forest-to-another.aspx

Based on this article, I looked into SMTP address re-writing using my customer's Tumbleweed email firewall product.  While this provided the required functionality, the re-writing of message header (RFC2822) information required a manual, per-recipient configuration.  This was unfeasible for us given the number of mailbox-enabled users to migrated (approx 2500).

The solution we arrived at is actually a lot simpler than address re-writing, as described below.

Solution

The starting point is to ensure migrated mailbox-enabled users are configured with two SMTP addresses:

     <user>@north.com (Primary)
     <user>@north.local (Secondary)

These addresses are actually assigned by the Recipient Update Service (RUS) after the mailbox is successfully migrated, based on recipient policy.  When configuring the required recipient policy, the checkbox next to This Exchange Organization is responsible for all mail delivery to this address must be cleared for the north.com address space.  This indicates that south.com’s Exchange organisation is not authoritative for the address space north.com.  In contrast, the north.local address space must have the checkbox enabled.

As soon as the IIFP GAL Sync process detects a new mailbox-enabled user in south.com’s Exchange organisation, it creates a corresponding Contact object in north.com’s Exchange organisation with the same SMTP addresses as above.   Normally, the fact that the Contact object has a primary address of @north.com would present a routing problem (because of the shared SMTP address space issue).  In other words, emails sent from the north.com’s Exchange organisation would have no route to the migrated users. However (and this is where the magic happens), the IIFP GAL Sync process additionally stamps an attribute onto the Contact object called targetAddress.   The value of the targetAddress attribute is <user>@north.local and this is the one that Exchange uses when routing email.  

An SMTP Connector is required to allow emails addressed to <anything>@north.local to be routed through from north.com’s Exchange organisation to south.com’s Exchange organisation.  In other words any emails sent to <user>@north.com are correctly routed through the Connector to <user>@north.local.

Emails sent from both migrated and non-migrated users correctly show the reply address as @north.com.  This is true, regardless of whether the emails are sent between the two Exchange organisations or between Exchange and Internet recipients.

Now, you are probably wondering how IIFP knows to stamp the Contact objects with a targetAddress attribute value of <user>@north.local instead of north.com.  The answer is that it comes from the configuration of the south.com Management Agent (MA).  The north.local address space needs to be configured as one of the SMTP mail suffixes in south.com’s MA properties.  The list of SMTP mail suffixes must obviously not include north.com.

Note that it is important that the migrated mailbox-enabled users from north.com do not acquire <user>@south.com secondary SMTP addresses as part of their recipient policy.  The reason for this is that this address space is also configured as one of the SMTP mail suffixes in south.com’s MA properties and may be set as the targetAddress for new Contact objects.  The MA is not very sophisticated in this respect and simply picks the first match (i.e. either north.local or south.com).

Further Reading

How to share an SMTP address space in Exchange 2000 Server or in Exchange Server 2003

http://support.microsoft.com/?kbid=321721