Some organizations that are going through a merger or looking to consolidate Exchange organizations may choose to quickly install the Inter-Organizational replication tool so that Free/busy and Public Folder replication can be provided between the Exchange Organizations and then look to migrate one organization into the other at a later date using a product such as Quest Migration Manager for Exchange (QMM-EX).

The inter-organizational replication tool may be set up as shown in the following diagram where contacts are created to create a GAL in the opposing Exchange organizations and then the inter-organizational replication tool associates Free/Busy information with the contacts.

In order to understand the problem when it comes to QMM we also need to understand a bit further about how Free/Busy information is stored in Exchange Server and also how the inter-organizational replication tool synchronizes these messages.

Free/Busy information in all current versions of Exchange is stored in a System Public Folder called the Schedule+ Free/Busy. I am assuming here that Exchange 2007 is in a mixed environment with a Public Folder store and that it is appropriately configured.

If you use a utility such as MFCMAPI to open up the Schedule+ Free/Busy once the inter-organizational replication tool is in place you would see something similar to this.

If you went on to open one of the EX: folders under the Schedule+ FREE BUSY folder with MFCMAPI you would see a list of all of the Free/Busy messages related to that Exchange Organization/Administrative Group.

Without going into an in depth technical discussion over Free/Busy all we need to know at this point is that each Free/Busy message is associated with an Mail Enabled object using the LegacyExchangeDN attribute which is an internal and unique identifier which is used internally by Exchange Server. We also need to understand that objects stored within the Exchange Server databases have a property called PR_SOURCE_KEY. The PR_SOURCE_KEY is a Globally Unique IDentifier within the Exchange Organization.

The inter-organizational replication tool uses the LegacyExchangeDN attribute to associate Free/Busy messages with the contacts that are created in the opposing environments and then uses the PR_SOURCE_KEY attribute to find and synchronize the actual Free/Busy data.

A period of time can now go by where the inter-organizational replication tool quite happily synchronizes Free/Busy information before a migration project starts in order to consolidate Exchange Organizations.

I am now going to talk about the impact that this has on QMM-EX although it probably applies to similar tools from other vendors as well.

QMM-EX had has Calendar and Free/Busy synchronization built in but I need to take a small step back first at this point and actually talk about Quest Migration Manager for AD (QMM-AD). In this sort of scenario, if we say we wish to merge mailboxes from Domain B into Domain A we would use QMM-AD to migrate the user object from Domain B to Domain A. During this process QMM-AD would detect that there is an existing contact for the user from Domain B in Domain A and as such QMM-AD would create the new user account and then merge the relevant details from the contact onto the user account in Domain A before deleting the contact. The LegacyExchangeDN from the contact is turned into an X500 address and added to the new Domain A users email addresses to allow Exchange users to continue to reply-to this user. I am not going to touch any further on the email routing technicalities here as it is outside the scope of this article.

As Quest do not support synchronization products that provide similar functionality running alongside QMM we are also having to replace the contacts and Free/Busy information that is currently synchronized into Domain B and the graphic below shows how the domains look after the accounts have been migrated with QMM-AD and the contacts deleted.

The problem we have now though as we mentioned earlier is that Free/Busy messages held within Public Folders are associated with a LegacyExchangeDN, and what we have done with the QMM-AD migration is deleted the contact and its LegacyExchangeDN attribute from the Exchange organization and effectively orphaned the Free/Busy objects from any mail enabled objects in Exchange.

If were now to proceed down the route of implementing the calendaring agents within QMM-EX, they would quite happily synchronize the Free/Busy information as they work in a similar way to the inter-organizational replication tool by using the PR_SOURCE_KEY attribute to identify objects in the Exchange Stores. In this scenario the only problem is that the Free/Busy messages are still not associated with any mail enabled objects and as such users would not see any Free/Busy information.

So how do we fix this problem?

In the next part we will discuss how to resolve this problem with Free/Busy messages that have been generated by the inter-organizational replication tool but where we now wish to implement QMM.