In my previous post on this topic I discussed at a high level how the Inter-Organizational Replication tool works to synchronize Free/Busy information between Exchange Organizations and then discussed some of the problems that could occur at a later date if a migration was then attempted to consolidate the Exchange Organizations.

In this post I will discus how to resolve this problem so that a tool such as Quest Migration Manager for Exchange (QMM-EX) can be implemented and continue to synchronize Free/Busy information as it is not supported to run the two tools in parallel.

The first problem that we have to do is remove any Free/Busy messages from the Exchange Organization in Domain A for objects from the Exchange Organization in Domain B and vice-versa.

One way of doing this is to use the utility MFCMAPI to open up the relevant section of the Schedule+ Free/Busy Public Folder and simply delete the Free/Busy messages. This is fairly straight forward and quick to do but does lead to an unavailability of Free/Busy information within the Exchange Organization.

If we were now to enable the calendaring agents within QMM-EX again now we would hit upon another problem that can badly effect Exchange migrations if it is not carefully considered not just within Calendar Migration but also within Public Folder migrations. Within the log files we would see SYNC_E_OBJECT_DELETED errors.

Basically what is happening here is that QMM-EX is trying to re-create the Free/Busy message in the target Public Folder Database but it can’t as the PR_SOURCE_KEY already exists. But did we not delete it?

The problem here is that when objects are deleted in the Public Folder database they are not actually deleted. Similar to other components of Microsoft systems the objects in the Public Folder tree are actually tombstoned to be permanently removed after the tombstone expiration interval. As such QMM-EX is unable to create another object with the same PR_SOURCE_KEY.

So what are the options? We could reduce the tombstone expiration interval to 1 day which would may be fine in a small environment, but there is another consideration here in that only 500 tombstoned objects are removed per day. So if there are thousands of Free/Busy messages there would be a waiting game while the objects clear out of the database, all the time remember though users are being impacted as Free/Busy information has been removed.

The only way of speeding this up is to change the PR_SOURCE_KEY of the Free/Busy messages in their relevant source Exchange environments but we can’t just go and change the value of the PR_SOURCE_KEY.

The solution is in the use of a utility that is only available from Microsoft Support. The GUI version is called UpdateFB.exe and there is a command line version called CPPCDO.exe. These utilities can be used to rebuild Free/Busy information based on the content of mailbox calendars but before running through this process we have to delete the remaining Free/Busy messages for users using MFCMAPI as we did earlier in each Exchange Organization for the users from the source Exchange Organizations.

Figure 1 – GUI Version of UpdateFB.exe

We now have in the example described in Part 1 of this article two Exchange Organizations with no Free/Busy information. The first task when using UpdateFB.Exe is to generate an import file for the mailboxes we want the utility to process, the import file needs to contain the alias of each mailbox and the NetBIOS name of the Exchange server where the mailbox is homed. When we run the UpdateFB.Exe utility with a suitable service account it will go through all of the mailboxes specified in it’s import file and rebuild the Free/Busy information based on mailbox calendars and the Free/Busy messages will be recreated with a new PR_SOURCE_KEY which means that when QMM tries to synchronize these messages it will be successful.

Figure2 – Sample UpdateFB,exe import file.

Once UpdateFB.exe has completed it would then be possible to start the calendar synchronization jobs within QMM as all of the Free/Busy messages would have new PR_SOURCE_KEY values that can be synchronized and correctly associated with the migrating users in the target domain.

This process needs to be carefully considered with other QMM associated processes and the sequence of events carefully worked out and tested to ensure that the disruption to users is reduced to the minimum possible time.

I would like to stress at this point that this is a disruptive process that must be tested and have valid backups of the Exchange environment before you try to implement this in a live environment. When you get to a live environment with this type of process you need to know that there is a good chance that everything will be ok with the process and the use of consultancy is advised.