I know I've kept you in suspense over the past week, while you waited for me to continue with my story of merging two Exchange Server organizations. In fact, several of you asked whether I could just write the whole story in one edition of Exchange and Outlook UPDATE. I'm afraid that would be difficult within the limits of one newsletter. This week, I'll address the first two requirements of our merger scenario ( please refer to last week's column for the complete details.
Requirement A for the two companies (ABC.COM and XYZ.COM) was to begin routing email privately as soon as the acquisition deal closes. To do this, we must reroute mail traffic from a public Internet-based SMTP connection to a private connection. Obviously, the prerequisite for the reroute would be a private WAN connection between the two organizations, which we'll complete before the closing date (in this case, other requirements called for a full 25Mbps asynchronous transfer mode—ATM—circuit, which should suffice). On the Exchange side, we simply need to set up Exchange 2000 SMTP virtual servers on both ends to act as gateways. One additional point is that ABC.COM will front-end its SMTP gateway with a virus wall ( see related discussion in the February 16, 2001, edition of Exchange and Outlook UPDATE) because ABC.COM wants to be able to isolate virus outbreaks between the two organizations. From a configuration point of view, only the SMTP connection settings at both ends and the DNS Address (A) and Mail Exchanger (MX) records need to change. Usually, when ABC.COM sends mail to XYZ.COM over the public Internet, the SMTP gateways rely on the Internet DNS services to locate the mail server for XYZ.COM (i.e., mail.xyz.com) and route messages. Because the two organizations will now have a private connection, they'll both add the necessary DNS records so that the system can locate the SMTP servers and route mail over the private connection. This setup will accomplish requirement A and let mail flow between ABC.COM and XYZ.COM quickly, efficiently, and securely.
Requirement B is more challenging. Both companies want replicated/synchronized Global Address List (GAL) access, meaning that when users from XYZ.COM open their GAL in Outlook, they want to be able to view and select recipients at ABC.COM and vice versa. The fact that you can accomplish this requirement in several ways makes it more complex. The key is to select the method that best meets the current requirements but also enables future requirements to be met with the least amount of work. The easiest path is to simply create contacts/custom recipients in both ABC.COM's and XYZ.COM's Active Directory (AD). We can script and complete this process via a simple directory import. The end result would still provide GAL access, but synchronization is more of a challenge. Several excellent tools are available that can address this need, but they are pure Lightweight Directory Access Protocol (LDAP) directory replication and synchronization tools and require a significant amount of work to configure, deploy, and manage.
In this case, the project team has decided to use Microsoft's Active Directory Connector (ADC) to accomplish the objectives. We chose ADC because it's easy to set up and manage, and it can populate and synchronize InterOrg directories with simple connection agreements. We'll deploy the ADC at both ABC.COM and XYZ.COM and implement connection agreements to replicate accounts from XYZ.COM to ABC.COM and create contacts (the ADC in InterOrg mode doesn't support AD account creation) in ABC.COM's AD. We'll replicate ABC.COM accounts to XYZ.COM but create only AD contacts; XYZ.COM will eventually fully merge into ABC.COM, and the creation of accounts for ABC.COM users in XYZ.COM's AD isn't necessary. This setup achieves some other nonmessaging requirements, such as XYZ.COM users gaining access to resources on the ABC.COM network (creating accounts with the ADC makes this access easier). In addition, using the ADC to create disabled user accounts will make full migration of XYZ.COM accounts and mailboxes easier in the future (requirement E).
At this point, the project team has met the first two messaging business requirements, and when the acquisition deal closes, ABC.COM and XYZ.COM will be able to see each other in their respective GALs, and mail between the two organizations will be routed privately and securely. Next week, I'll address requirements C and D (Free/Busy and ABC.COM proxy addresses) as we continue our discussions about "When Companies Merge" (kind of like watching "Survivor," huh?).
End of Article
Register
