We knew from the beginning that merging two very large Exchange networks was going to take some time. Digital had 200 servers supporting 65,000 employees. Compaq had 200 servers supporting 35,000 employees. With the current state of the tools and the ongoing work with the Transmission Control Protocol/Internet Protocol (TCP/IP) network interconnect, Domain Naming System (DNS), Windows Internet Naming Service (WINS) and the NT domain trusts, we would not be merging these Exchange systems over a weekend.

Instead we decided that an extended period of seamless coexistence leading up to a full merge would be a more pragmatic approach. We would make the interconnect seamless by configuring the Internet Mail Service on each network to achieve the highest level of message fidelity, and by synchronizing the directories so that both systems would include all Digital and Compaq employees as well as selected distribution lists. We would add public folder synchronization as time permitted. We felt that this strategy would relieve the immediate demand for a single Exchange network and buy us some time until the tools and the infrastructure would support a true merge.

We needed flexibility to handle the mapping between one directory and the other. For example, the tool had to re-write display names so that all names appeared consistent in each directory and deal with the other differences.

We wanted a lightweight solution with as few moving parts as possible. We wanted a system that would synchronize quickly with little load on the source and target systems so that we could run it frequently and keep the directories as up to date as possible.

We did not want to introduce additional complex components that would need specialized expertise or that might require constant babysitting. The solution should not require additional head count or expertise that we did not currently have available.

After evaluating several solutions we ruled them out because they did not meet our requirements. In most cases all the products failed to meet two out of three of our criterion and some failed all three.

We knew that Exchange 5.5 supported Lightweight Directory Access Protocol (LDAP) for both read and write operations and so in theory it was possible to interconnect them using LDAP. LDAP specifies a standard protocol and there is some agreement about the Applications Programming Interface (API) and a standard schema. However LDAP does not yet standardize replication or synchronization between directories. We were fortunate to learn that a Digital product that had previously been used to synchronize X.500 directories was about to be released with an update that would allow it to synchronize any two LDAP capable directories. This product is called LDAP Directory Synchronization Utility (LDSU) and it was in late beta at the time we were seeking a solution.

The basic function of LDSU is to use LDAP to query the source directory, calculate the difference in synchronized objects since the last time it ran and propagate the changes to the target directory, again using LDAP. Since only the updates were propagated to the target system, we chose to run two instances of LDSU, one in each network. This way the LDAP extract would be local and only the updates would travel over the Wide Area Network (WAN) connection. We could consolidate this down to a single LDSU instance if we desired.

In about a day we had installed LDSU and configured it for the basic features we needed for mailbox and custom recipient synchronization. Mailboxes and Custom Recipients (representing our Unix and Virtual Memory System (VMS) mail users) from the source system were synchronized as Custom Recipients in the target system, preserving all the attributes we wished to synchronize, and using the Simple Mail Transfer Protocol (SMTP) address to allow message delivery.

We used the LDSU scripting language to implement the display name mapping and the alignment of other attributes where our syntax or semantics was different. The Display Name was particularly interesting because both companies used a convention of appending some descriptive information after the employee name to help disambiguate that person from another with the same name. We needed to preserve that detail as we mapped the Display Name. In addition, to help employees differentiate based on the original company affiliation we also appended the company name to the display name. For example "Mary Jones (Sales)" from Digital had to appear as "Jones, Mary (Digital—Sales)" in the Compaq directory.

LDSU also allowed us to filter out many mailboxes that we did not want to synchronize. In some cases there were test mailboxes, or mailboxes that were used for internal processes that had no meaning in the other company. We used the LDSU script to filter these out using the pattern matching features in the script language.

The initial synchronization went without a hitch and we managed to create the impact we desired by arranging the synchronization to start the second that the legal process had been finalized at the shareholders meeting on June 11. This single act of merging the directories made a great impact on the employees of both companies. We really were one company because all employees were visible in the directory. I have a 45-minute commute home and on June 11th I grinned like an idiot all the way home.

It took several hours to complete this initial synchronization process and several more hours before the Exchange network had fully replicated all the synchronized objects. Within 24 hours all servers worldwide were fully replicated and our directories were now showing over 110,000 entries.

This is how it looked to the employees:

We scheduled the synchronizer to run four times a day every six hours. During each synchronization period we typically see a few hundred transactions (Add, Modify or Delete) as LDSU detects the changes and updates the target system. It typically takes 15 minutes for the full synchronization from the Compaq directory and 25 minutes from Digital. The bulk (95 percent) of the time is the extract and difference calculation. The remaining 5 percent is LDSU performing the updates.

We created a special container in each directory just for the synchronized objects. We created a "Digital" container in the Compaq directory, and a "Compaq" container in the Digital directory. We used permissions to allow the LDSU process to have write-access to only this container. We basically "leased" the container to the other company and let the LDSU process from their side read and write into the special container but nowhere else.

Our next task was to synchronize distribution lists. Our requirements here were that we wanted distribution lists owners to decide if a list should be synchronized or not and we wanted the synchronized copy to appear as natural as possible in the other directory. This meant that the synchronized object should be a distribution list (not just a custom recipient referencing the original list) so that it displayed with the correct icon when viewed by the clients. The synchronized list should also retain the original owner so that an employee in the other system knew whom to contact when a change in the list membership was required.

With these requirements in hand we decided on the following approach. Distribution lists would be synchronized to the target system as hidden custom recipients with the SMTP address of the original list. Then for each synchronized list in the source system we would create a new list with the same name (and with the company affiliation in the Display Name) in the target directory. This synchronized copy would have just one member—the hidden custom recipient representing the original list.

Finally we added the original list owner to the synchronized list by adding the synchronized copy of the owners mailbox as the owner of the synchronized distribution list. So now we had a complete replica of the original list in the target system with the same name and apparently the same owner, displayed in the native format of the target system. We created a special container for the synchronized distribution lists and let LDSU do all the work automatically.

To allow users to select which lists to synchronize we created two empty lists, one in each directory. In the Compaq directory we created a distribution list with no members called "Publish to Digital". In the Digital directory we created a similar empty list called "Publish to Compaq". The instructions to the user community were simple. To synchronize your distribution list, add the "Publish to Digital" (or "Publish To Compaq" for Digital employees) list as a member of your distribution list. LDSU was configured to synchronize only those lists that had the so-called "cookie" list as a member.

This is very efficient from an LDAP perspective because we could find all distribution lists to be synchronized using a single search filter that requests all the objects of type Distribution List that have the "Publish To Compaq" distribution list as a member. Or as LDAP would phrase that: "(&(objectclass=groupofnames)(member=cn=publish-to-compaq, cn=compaq, ou=amexch1, o=digital))"

The "cookie" list has no members so the addition of the "cookie" to the source list does not generate any additional mail traffic.

Since we do not populate the synchronized list with the original members (we only add the hidden custom recipient representing the original lists as the single member), we do not have to worry about frequent changes of the membership causing large amounts of churn in the target directory, or worse, a user of the list in the synchronized domain using out of date membership. The synchronized copy, via the SMTP address in the hidden custom recipient, always sends mail to the source list where it is expanded and delivered.

Confused? Here is a diagram that might help:

In conclusion we are very satisfied with the tools we chose and the end result. The user community is happy, the help desk is not inundated with calls and we met our objective to buy a little time while we wait for the network infrastructure changes to take place and the mailbox/server move tools be mature. Then we can begin the process of truly merging the two large Exchange networks.