When Companies Merge, Part 4

I know it's been a long 4 weeks, and I wish I could have written this entire four-part series in one column. However, I've kept you hooked, haven't I? Over the course of three "episodes," we looked at one example of a merger/migration scenario. Of course, not all such scenarios are created equal or have the same concerns and challenges. Likewise, the solutions and approaches will vary greatly, depending on many factors. In this final week, we look at requirement E, total messaging integration of the two organizations, which is perhaps the most challenging and complicated requirement.

To recap our merger example thus far, ABC.COM and XYZ.COM now have some basic facilities in place on which we can build when finding a solution to our final requirement. A WAN circuit exists between the two organizations that provides ample bandwidth, and we've already provided interorganizational message routing, Global Address List (GAL) synchronization, InterOrg free/busy access, and ABC.COM primary proxy addresses for users at XYZ.COM. Now for the complicated part: deciding how to fully integrate these two companies.

First, we need to review the matter of ABC.COM proxy addresses for XYZ.COM users. Remember from Part 2 that we used the Active Directory Connector (ADC) to create contacts for XYZ.COM users in the ABC.COM Active directory (AD). The ADC doesn't support account creation when in InterOrg mode, so we have to decide what to do with these AD contacts now that we want to fully integrate the two organizations. For requirements A through D, using AD contacts worked fine; however, it creates a problem for this final requirement of total integration. Because contacts are not security principals, they aren't much help for our last requirement. Therefore, we must find a way to create full AD accounts in ABC.COM's AD for XYZ.COM users. One approach is to use the information in these contacts to create user accounts via some sort of bulk import that would populate certain attributes. Another solution is to use third-party tools from companies such as BindView and NetIQ. These tools might let us create or merge the AD contacts into accounts, while preserving information such as the X.500 proxy address of XYZ.COM users (which will be helpful later when users need to reply to old mail from when their mailbox was in the XYZ.COM organization). Most likely, the solution will involve a directory export of contact information and then a scripted method of recreating these accounts in the AD. In hindsight, we could have prevented this extra work by creating security principals in the ABC.COM AD for XYZ.COM users from the start. These XYZ.COM accounts in the ABC.COM AD will let XYZ.COM users have mailboxes in ABC.COM and give those users access to resources on the ABC.COM corporate network.

Now that we have accounts in the AD that are security principals, we can migrate mailboxes from XYZ.COM to ABC.COM. In the past, administrators had to move mailboxes via the EXMERGE utility (mailbox contents exported to a .pst file and imported into the new mailbox). However, Exchange 2000 Service Pack 1 (SP1) will bring this particular project some relief. Exchange 2000 SP1 includes an updated version of the Exchange Migration Wizard. The new version supports a much-needed feature: Inter-org mailbox moves. The one caveat is that the wizard supports mailbox relocation only from Exchange 5.5 servers to Exchange 2000 servers. Luckily, most of XYZ.COM's mailboxes are on Exchange 5.5 servers, and ABC.COM is entirely migrated to Exchange 2000. The latest version of the Exchange 2000 Migration Wizard will make my life much easier for this final requirement. As total integration proceeds, we will gradually relocate XYZ.COM mailboxes to corresponding locations (the distribution of actual locations will be determined geographically) and Exchange 2000 servers at ABC.COM. Although this process is more time consuming and complicated than one paragraph can illustrate, the process is very granular at the mailbox level (which means less user interruption). After we figure out how to move one mailbox, the rest are just repetition.

Well, that's a wrap for our merger/migration project. Certainly, I haven't addressed all possible scenarios that can occur in such a project. In addition, my project had very specific requirements that the project team had to deliver within specific timelines. When you embark on a project like this, the requirements and environment will likely be different. As a result, you'll find different ways to address your specific project needs. I hope that this series helps get your thought processes moving and prepares you to tackle a similar project of your own.

When Companies Merge, A Messaging Solutions Story
When Companies Merge, Part 2
When Companies Merge, Part 3