Microsoft

Configure IT Quick: Avoid problems associated with merging Exchange 2000 organizations

Find out why merging Exchange 2000 organizations can be problematic and how the Microsoft Metadirectory Services can help you out.


Exchange 2000 is a very scalable product, designed to service your entire organization while interacting with every domain in your entire forest. But there are situations—such as merging two different Exchange organizations' Active Directory (AD) forests—in which Exchange 2000 alone may not be scalable enough to get the job done. In such a situation, the Microsoft Metadirectory Services can give Exchange a helping hand. This service, which allows communications between otherwise unrelated AD forests, can save you a lot of manual labor. In this Daily Drill Down, I’ll show you some of the reasons why merging Exchange 2000 organizations can be problematic and how the Microsoft Metadirectory Services can help you out.

Why can't I just merge Exchange organizations?
Imagine for a moment that you manage the network for a really big company. Your AD forest probably contains several domain trees, each containing even more domains. Because Exchange 2000 relies so heavily on AD, you’d probably also configure an Exchange organization that mimics the structure of your AD. If this sounds absolutely perfect, you’re right. That is, until your company merges with another company also running Exchange 2000.

In such a situation, your first instinct might be to make the new company’s Exchange servers part of your Exchange organization. However, that isn’t really an option. Exchange 2000 is totally dependant on the AD. Because of this, your company and the newly acquired company would already have ADs established. The problem lies in the fact that the forest is the highest level of AD. And because there’s no way to merge forests, the two organizations' ADs can’t be merged.

Why can’t you merge two forests, or at least establish a trust relationship between them? Because of the way that AD works. Remember that AD is more than just a repository for user accounts; it’s an entire relational database. Like any other database, it has a schema associated with it that's maintained by the organization’s global catalog servers.

Theoretically, if two forests consisted entirely of Windows 2000 servers with absolutely no modifications, the AD schema would be uniform, and the merger would be possible. However, applications such as Exchange 2000 modify the AD schema, and administrators can manually modify the AD schema. So there would be no way for Windows to guarantee that the AD schema hadn’t been modified, and therefore it wouldn't even attempt to support a merger between two AD forests.

Some commonsense solutions that won't work
Okay, so a simple merger won’t work. You’re an experienced network administrator. There are other tricks you’ve used in the past that will work in this situation, right? Probably not. Two of the things that network administrators quickly think of include configuring the new organization as a foreign mail system or reformatting and reinstalling servers in one of the organizations to fit into the new organization. These solutions won’t help, so don’t bother. Why?

Let’s start by discussing what happens if you treat the newly acquired company’s network as a foreign mail system. You might remember that Exchange 5.5 allowed you to establish connectors to foreign mail systems, such as Lotus Notes. After doing so, you could use foreign mail connectors to add remote mailboxes to the global address list.

But you can’t do this with Exchange 2000 because of its AD integration. Exchange 5.5 used its own built-in directory that functioned completely independently of the Windows operating system. However, in an Exchange 2000 environment, AD provides the directory information to Exchange. Therefore, if you were to input information on a foreign mailbox, the entry would be placed in the AD, which could potentially cause conflicts and data loss.

Another solution would be to start reformatting servers and reloading them as a part of the original organization. However, this method is tedious, risky, chaotic, and can be expensive in terms of lost productivity and training costs. In large organizations, this method can be especially risky because any time you reformat servers, you risk losing data. You would also still encounter problems with access control lists that would still point to user and group objects in the old AD forest. Therefore, you’d have to manually re-create all of the newly acquired organization’s AD objects in the original AD forest. As you do, you might run into problems of user accounts from the two organizations having duplicate names or servers and workstations with duplicate names. The reformat/reload solution also disrupts workflow. While you’re in the process of reloading the servers, they are unavailable to the users.

The best solution
Okay. So you can’t easily merge the trees, and most of the other solutions cause more problems than they fix. Now what? You can make the forests acknowledge each other’s existence by using the Microsoft Metadirectory Services, which allows communications between otherwise unrelated AD forests.

To understand how that works, you must know a few things about metadirectories. A metadirectory is a directory composed of information from dissimilar sources. The idea behind it is that applications should be able to share directory information.

Consider the type of information management that goes on in most companies. In many companies, information on employees exists in several places. First, the AD contains a user object for each employee. Each user object may have information such as address, phone number, and department associated with it. The human resources department probably also has an employee database that contains most of the same information but with a few extra bits of data, such as hire date and salary. Finally, the finance department probably has yet another employee database containing much of the same information as the AD and the human resources databases, along with information on payroll withholding.

The fictitious company I’ve described has at least three, possibly more, databases with information on the same set of employees. Now, suppose the company merges with another company. The new company probably has its own set of databases duplicating information in the old company’s databases but in different places (i.e. in payroll or human resource programs). If an employee moves from one company to the other, the information must also move, but it may have to be changed in a dozen more databases than before the merger.

A metadirectory could make these databases more efficient by establishing links between them. Once the links are set up and a sort of trust relationship is established, you can update a single set of data rather than having to update three different databases. The metadirectory would then make the changes in the individual databases.

However, the methodology I just used is very general. Most metadirectories are custom created for each company because each database to which the metadirectory is connected usually has its own security system. Therefore, it’s important to tailor the metadirectory so security will be preserved but also so each database will recognize users of the other databases and can assign them the appropriate security permissions.

So what does all of this have to do with Exchange 2000 and Windows 2000? Remember, Exchange 2000 relies on the AD, which is a database. If you need to make users in two different Exchange 2000 organizations aware of each other, then installing a metadirectory is a good method to use. Sure, the users can still send SMTP messages back and forth, even if the two organizations haven’t been associated with each other. The benefit of using the metadirectory is to make the two AD forests truly aware of each other. By doing so, you can assign permissions to resources in one forest to a user in another.

Microsoft Metadirectory Services
Naturally, the best metadirectory for a Microsoft network is going to come from Microsoft. Microsoft provides the Microsoft Metadirectory Services (MMS) to help link all of these different databases together. It can link more than just different AD trees. You can also use it to link information from places including:
  • Novell NDS
  • iPlanet Directory
  • Banyan VINES
  • Novell GroupWise
  • Lotus Notes
  • PeopleSoft
  • SAP

MMS is a centralized service that stores and integrates identity information from multiple directories in an organization. It runs on top of Windows 2000 Advanced Server or Windows 2000 Datacenter Server.

Microsoft doesn’t charge directly for MMS. However, that doesn’t mean you can just go to Microsoft’s Web site and download it. Instead, you must talk to Microsoft Consulting Services or a Microsoft partner to obtain and install it. Although that’s probably to make sure you don’t install MMS and do major damage to your network. However, you can probably assume that such consultations aren’t going to be free. You can find out how to reach Microsoft Consulting Services and some of Microsoft’s partners who can help you implement MMS by visiting the Microsoft Metadirectory Services Web site.

Because MMS allows you to link information from so many different sources, as you can probably guess, it would easily allow you to link information in two different Exchange 2000 organizations. You can use MMS to transfer information between organizations without having to worry about redoing the infrastructure of either of them.

Conclusion
When organizations merge, things can get complicated. It’s usually up to someone like you to straighten out all of the details, such as making various databases talk to each other. If you’re running Exchange 2000, one of the hardest things to do is merge Exchange 2000 organizations. Fortunately, MMS can help.

Editor's Picks