Control the domain controller choice during deployment

Since Exchange 2000 Server and Exchange Server 2003 are dependant on the Active Directory, the Setup program must be in near constant communication with a domain controller during the deployment of an Exchange Server.

The problem is that you never really know which domain controller Setup will choose to communicate with. As you may know, Windows 2000 Server and Windows Server 2003 use a multi-master domain model. This means that domain updates can be written to any domain controller in the entire domain. Once the changes have been written to a domain controller, the updated domain controller sends a notification to the other domain controllers indicating that updates have occurred. The other domain controllers then contact the domain controller that has been updated and request copies of the updated information.

At first this entire process sounds neat, orderly and non-problematic. However, this architecture can cause some really interesting problems during Exchange Server deployments.

One potential problem is that the network's performance could really be diminished during the deployment. For example, suppose that you have a single domain that spans multiple facilities. If Exchange just happens to choose a domain controller that is located in a different office, then the Setup program may try to send an overabundance of information across a slow WAN link. This would result in a slow deployment and in the WAN link being congested until the deployment is complete and the updates have been written to all remaining domain controllers.

Microsoft has designed the Active Directory in a way that allows you to define site objects as a way of preventing this problem. When updates to the Active Directory occur, those updates are automatically written to a domain controller within the same site as the person making the updates. The problem is that I have seen several networks such as the one that I described above in which sites simply weren't defined. If you have such a network, you may be able to greatly improve performance by taking a little time and segmenting your domain into various sites.

Performance problems can also occur even if all of the domain controllers are located in a single facility. For example, on my own network I have one server that really needs to be replaced because it is so old. As luck would have it, this server is one of three domain controllers for a particular domain. Active Directory updates work great as long as they are not written directly to this server. If an update is written directly to that server though, the process is slower than Christmas.

Poor performance isn't the only problem that can result from random domain controller selection. Much more serious problems can occur if you are simultaneously deploying multiple Exchange Servers. Imagine that you are installing three different Exchange Servers and that each server happened to choose a different domain controller to communicate with.

Although this situation sounds feasible, problems sometimes occur when the Exchange Server's name is added to the Exchange Domain Servers group. If this group is created separately on different servers, then replication conflicts will occur. The process for resolving a replication conflict is complex, but basically the newest copy of the contradictory entry takes precedence. This means that in this situation, Exchange will install successfully, but that on two of the three servers, there is a really good chance that some of the Exchange-related services will fail to start.

There are a couple of different ways that you can fix this problem. In an Exchange 2000 Server environment, you will have the best results if you avoid deploying multiple Exchange Servers simultaneously. If you do choose to deploy multiple Exchange 2000 Servers simultaneously, you might get lucky and not have any problems. If you do have problems, you will have to update the Exchange Domain Servers group manually so that it includes an entry for each Exchange server.

If you are deploying Exchange Server 2003, there is a better solution to the problem. Microsoft has added a switch to the Setup program called /CHOOSEDC. This switch allows you to specify which domain controller the server should communicate with during the Exchange deployment.

You can avoid the problems that I have described by setting each server to communicate with the same domain controller. The syntax for the command is: SETUP.EXE /CHOOSEDC server_name. If you would like to read more about this command, you can get more information from the Microsoft Web site here