When Companies Merge, Part 3

When we last left our merger scenario, we were in the thick of working through the project's five business requirements. In last week's column, we looked at requirements A and B (private mail routing and Global Address List—GAL—synchronization). This week, we look at providing free/busy service across the organizations (requirement C) and creating ABC.COM proxy addresses for users in XYZ.COM (requirement D). We finish the series next week with discussions about total integration ("you will be assimilated") of XYZ.COM into ABC.COM.

When approaching the problem of inter-organization calendar access, you must remember that free/busy information in Exchange is simply a special public folder. Because we can replicate public folders, we can use a lesser-known tool to solve our problem. That tool is the Exchange InterOrg Replication Utility, and it lets two separate organizations share public folder and free/busy information. The InterOrg Replication Utility requires that directory information be exchanged beforehand (We accomplished this for requirement B via the Active Directory Connector—ADC). To share free/busy data, users on both sides must be able to match SMTP addresses across organizations, which we can accomplish with a synchronization mechanism or via a straight directory import. The tool uses a Messaging API (MAPI) connection so the network link must be able to handle this replication traffic. The InterOrg Replication Utility is available in the Exchange Resource Kit and requires some setup, configuration, and management. The tool works via a publisher/subscriber arrangement and requires setup on both ends. If you want more information about the InterOrg Replication Utility, see Microsoft Support Online article Q238573. This tool provides just what we need to accomplish requirement C.

Requirement D for our merger/migration scenario is for users at XYZ.COM to get ABC.COM email addresses to put on their business cards. This requirement has several ramifications. First, ABC.COM will have to receive email addressed to XYZ.COM users with ABC.COM addresses and route for delivery to mailboxes in the XYZ.COM organization. Second, we need to apply these addresses to accounts within the XYZ.COM organization. On the ABC.COM side, we need to apply the target addresses (in XYZ.COM) to the accounts so that when inbound mail for XYZ.COM enters the ABC.COM organization, the system routes the mail to XYZ.COM. Obviously, this will require a bit of coordination between both organizations' Exchange administrators to apply the proxy addresses on both sides and assign addresses for XYZ.COM users that don't conflict with existing users at ABC.COM. In addition, the private mail routing (discussed in requirement A last week) must be functioning properly so that mail can be routed internally between the two organizations. The last decision that needs to be made relates to which address (ABC.COM or XYZ.COM) will be the primary proxy for XYZ.COM. This address will appear as the reply address for mail sent by users in XYZ.COM. In the case of this project, the project team decided that users at XYZ.COM would immediately cut over to using [email protected] as their primary address.

Of course, many other questions must be asked and answered. For example, can the mail gateways handle the extra load? What are the security consequences? Because users are now sending as ABC.COM, are their security measures (including antivirus) up to snuff? On the road to accomplishing the business requirements, we don't want to bypass any standard policies and practices for the sake of quick integration.

We've now discussed requirements A through D for our merger/migration scenario, and we've achieved the essential Phase 1 goals for the integration of the two organizations. They have a high degree of cross-organizational communication capability (private email routing, GAL access, free/busy access) and users at XYZ.COM can put ABC.COM email addresses on their new business cards and still receive mail in their XYZ.COM inboxes. Next week, we'll close our discussions about this project with the mini-series finale: Total Messaging Integration (requirement E).