In many organizations, Exchange has become one of the most, if not the most, critical applications. People depend very heavily on their e-mail, calendars, contact lists, etc. Of course, all of the power that Exchange offers comes at a price. If you’ve been working with Exchange for any length of time, you’ve probably found out just how complex it can be. With that in mind, imagine the task at hand: migrating all mailboxes and other groupware objects to an entirely new platform without losing a single message or other type of object along the way. The thought is frightening, to say the least. In this Daily Drill Down, I’ll discuss some of the details behind the migration process. As I give you an overview of how the migration process works, I’ll also discuss in detail some key concepts that you’ll need to know about Exchange 2000.
A word about the Directory Service
Before you can truly understand the challenges ahead, it’s necessary to understand a little bit about the way that Exchange works. As you may know, Exchange 5.5 depends on a service called the Directory Service. The Directory Service is a database that stores information on each object within Exchange. For example, every mailbox has certain properties associated with it. These properties store information such as a user’s full name, address, phone number, and primary Windows NT account name. Many companies have populated these various database fields and use them as a business tool. For example, if a user needs to call another user, he can use the Exchange directory to locate the user by e-mail address and then view the user’s phone number.
Now, consider the way that Windows 2000 works. Windows 2000 uses a database called Active Directory. Active Directory functions similarly to the Exchange Directory Service, with a few exceptions. Because of this, Exchange 2000 doesn’t use the Directory Service. Instead, it simply relies on Active Directory for information. Obviously, you don’t want to just throw away all of the information that you’ve compiled into the Exchange Directory Service. Therefore, you’ll want to migrate this information into Active Directory.
Right now, you may be thinking that this task sounds simple enough. After all, there’s probably some sort of utility that can perform such a task automatically. In actuality, there is such a utility. However, there’s still a little more to consider before jumping in with both feet.
Consider for a moment that larger organizations tend to have multiple Exchange servers. Usually, these servers are linked together through site connectors or some other type of connector and are set to replicate all of their directory information among each other. In such organizations, there probably aren’t enough hours and support people available in one night or even one weekend to migrate all of the servers at once. This means that you’ll have a period of time when your Exchange servers will be operating in a mixed-mode environment.
If this is the case with you, relax. Working in a mixed-mode environment isn’t a problem; you’ll simply have to change your management techniques a little. When you migrate Exchange 5.5 to Exchange 2000, you’ll be using the Active Directory Connector. This is the component that helps to actually move the database contents from the Exchange Directory Service into Active Directory. Fortunately, the Active Directory Connector is completely backward compatible with the Exchange 5.5 Directory Service database.
If you find yourself working in a mixed-mode environment, you’ll have to change the way that you do the majority of your management. You’ll need to begin managing Exchange through either Active Directory or from the Exchange Directory Service (using the Exchange Microsoft Management Console snap in). Any changes that you make in either place will then be replicated to the legacy Exchange servers. According to our sources, there are a couple of situations in which you may still have to use the Exchange Administrator program. However, at the time that this article was written, Exchange 2000 was still in beta testing and that information was undocumented.
In really large environments where various groups manage their own Exchange server, you’ll always find some groups who are hesitant to make the transition. You’ll hear excuses like, “It works fine the way that it is, why should we change it?” However, there are some serious benefits to migrating all of your Exchange servers. One such benefit is that replication works much better in Exchange 2000. In Exchange 5.5, server objects could only be modified within the site where you created them.
However, in Exchange 2000, as long as a server contains a full replica of the site that you want to modify, you can modify the server objects. As you can see, Exchange 2000 is much more flexible from a management standpoint than Exchange 5.5 was. Another difference in the way replication works is that when you made a change to a Directory Service object in Exchange 5.5, the entire object had to be replicated throughout the entire organization before the change would take effect. In contrast, however, Exchange 2000 uses the same Active Directory as Windows 2000.
As you may know, Active Directory supports property-level replication. This means that only the specific property that has changed must be replicated. Therefore, Exchange 2000 takes less time than Exchange 5.5 does to replicate objects, and there’s no confusion if two people try to modify different properties of the same object simultaneously.
Exchange 2000 and Windows 2000—working hand in hand
As you might have guessed, Exchange 2000 and Windows 2000 are very closely related. This means that if you have separate staff for administering the two environments, they will have to work together to make the migration possible. To give you an idea of how Exchange 2000 depends on Windows 2000 (beyond the obvious), consider the following:
We mentioned that Exchange 2000 and Windows 2000 share a common Active Directory. This means that if a field is added to or removed from the Active Directory schema, it will impact both Windows and Exchange.
Another way that the two environments work together is with communications protocols. As you probably know, Exchange 5.5 depended on remote procedure calls, or RPCs, for internal communications. However, this isn’t the case with Exchange 2000. Exchange 2000 uses protocols such as SMTP and NNTP for its primary communications mechanism. RPC still exists but is used primarily for backward compatibility. The SMTP, NNTP, and other protocols that may be in use are installed at the Windows 2000 level. Exchange 2000 adds a few extra commands to the protocols and provides some of the routing functionality, but it depends heavily on Windows 2000 to provide the basic protocols. We should also point out that Exchange 2000 also relies on DNS for some of the name resolution services. As you may know, this is because Active Directory also depends on DNS, and of course DNS resides at the Windows level.
More on the Active Directory Connector
We mentioned earlier that the Active Directory Connector was the mechanism used to migrate database fields from the Exchange 5.5 environment to the Exchange 2000 environment. With the Active Directory Connector being such a crucial part of the migration process, it seems appropriate to talk some more about it and how it works.
To get a feel for how the Active Directory Connector works, remember that after the migration is complete, the Windows 2000 Active Directory is also the Exchange 2000 directory. The two share a common database and are one and the same. Therefore, before you can migrate mailboxes and other objects from Exchange 5.5 to Exchange 2000, the mailboxes and other objects that exist under Exchange 5.5 must exist within the Windows 2000 Active Directory. This task is the responsibility of the Active Directory Connector. When you go to upgrade the first Exchange server in your organization to Exchange 2000, the Setup program installs the Active Directory Connector. This connector migrates the schema from the Exchange 5.5 Directory Service into the Active Directory, providing an empty container within the Active Directory to hold all of the objects contained within the Directory Service.
After the server has been upgraded, the Active Directory Connector performs a check to see if there are other servers in the organization that haven’t been upgraded yet. If Exchange 5.5 servers still exist, the Active Directory Connector will remain loaded on the server. At this point, the Active Directory Connector’s purpose shifts from a migratory function to a compatibility function. It’s responsible for keeping Active Directory and the Directory Service synchronized.
Because of this synchronization, users with mailboxes residing on Exchange 5.5 servers will still be able to send messages to and receive messages from users whose mailboxes reside on Exchange 2000 servers, and vice versa. Sure, it might be possible to do this without the Active Directory Connector if the servers were configured in a certain way and the messages were sent across the Internet. However, the Active Directory Connector makes it possible to send messages between the two versions of Exchange without the messages ever having to enter the outside world.
Once you upgrade the last server to Exchange 2000 (or permanently remove it from the organization), the Active Directory Connector will detect that you’re running a pure Exchange 2000 environment. At this point, the Active Directory Connector’s job is done. The Active Directory Connector will now be removed.
More on the directory migration process
When the Active Directory Connector gets ready to migrate the Directory Service objects into Active Directory, it works with two main types of objects in the Directory Service database. These objects are recipients and configuration objects. Recipients include things like mailboxes, distribution lists, and custom recipients. Configuration objects, on the other hand, include objects such as connectors, protocols, and monitors.
In Exchange 2000, a mailbox is actually migrated to what’s called a mail-enabled user account. This means that the appropriate database fields and information have been appended to an existing user account (or a completely new user account has been created with these attributes) to allow the account to be e-mail accessible. Distribution lists are actually very similar to normal Windows 2000 groups. The main difference is that Exchange makes the group mail-enabled. This concept applies to both security and distribution groups. In actuality, just about any object in the entire Active Directory can be mail-enabled.
Because of the diversity of objects that can be made mail-enabled, it’s easy to fit a custom recipient into Active Directory. In Exchange 2000, a custom recipient is actually nothing more than a contact in Active Directory that has been mail-enabled.
In this Daily Drill Down, I discussed some of the preliminary work that needs to be completed before the migration to Exchange 2000. I also gave you an overview of the migration process and discussed some of the key concepts in detail.
Brien M. Posey is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense. If you’d like to contact Brien, send him an e-mail. (Because of the large volume of e-mail he receives, it's impossible for him to respond to every message. However, he does read them all.)The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.