Software

Get IT Done: Documentation inconsistencies disrupt Microsoft Exchange 2000 upgrade

Inconsistencies in Microsoft Exchange Server 2000 are exposed


A couple of network administrators recently ran into a documentation buzz saw as they prepared to upgrade an Exchange 5.5 environment to Exchange 2000 at a medium-size company. When they got ready to begin the process, they discovered they had conflicting information on how to proceed.

In this week's From the Trenches, we'll follow these admins (we'll call them Sheldon and Serge) through their upgrade on a test network to the point where they had to stop and call in Microsoft to help them out.

Get insights From the Trenches
You can learn quite a bit by reading about the methods other administrators and engineers use to resolve challenging technology issues. Our hope is that this column will provide you with unique solutions and valuable techniques that can help you become a better IT professional. If you have an experience that would be a good candidate for a future From the Trenches column, please e-mail us. All administrators and their companies remain anonymous in this column so that no sensitive company or network information is revealed.

The testing plan
Sheldon and Serge's company has offices in Europe, Asia, California, New York, and in a number of other East Coast and Midwest cities. When the company decided to upgrade its Exchange 5.5 servers to Exchange 2000, the plan was to upgrade its various Windows NT 4.0 networks to Windows 2000 first (since Exchange 2000 requires Windows 2000 with Active Directory). With Active Directory in place, the entire network could then be switched from Mixed Mode to Native Mode and all of the Exchange 5.5 servers could be upgraded to Exchange 2000.

A test network reflecting the company's new network profile was built for testing the upgrade to Exchange 2000 while the production networks were being upgraded to Win2K. The test network was set up to include machines at nearly all of its major offices. This was necessary for several reasons, Sheldon said. One of the main reasons was to determine how Exchange 2000 would work in the current distributed environment.

During the transition, Serge said they would use a bridge server and Active Directory Connector (ADC) between the unconverted Exchange 5.5 servers and the AD network running Exchange 2000 to exchange information between the two systems. They also planned to distribute Exchange routing functions throughout the network to speed e-mails to the appropriate Exchange 2000 mailbox sites.

A fork in the documentation road
Sheldon, Serge, and the rest of their working group of admins had the test network functioning just like they wanted, so they began the first Exchange 5.5 to 2000 upgrade. However, each of the admins had read an assortment of materials about the upgrade process, and it soon became apparent that their instructions varied quite a bit. Sheldon said there was a lot of inconsistency between Microsoft white papers, and Serge noted that the upgrade documentation seemed to be designed for specific operational and organizational implementations.

Unfortunately, as Serge pointed out, "There are a vast number of environments that are unique." And his company's environment definitely didn’t fit into the procedures outlined by Microsoft.

The admins were having particular trouble with the relationships between installation and service accounts. The IT group came to an impasse on how to resolve the questions, and the Exchange 2000 test network upgrade came to a halt.

They came to the conclusion that they could try each of the scenarios described in the conflicting documentation and that each would probably work fine, but none of these scenarios would result in a solution that would work for their production network.

"There will be more than 1,800 changes to AD on the production network, and they are all irrevocable," Sheldon said. As a result, they didn't want to rush headlong into the unknown and risk eventually making damaging changes to parts of their Exchange infrastructure.

Paying the man
Sheldon and Serge's company decided to purchase a Microsoft Premier Support agreement, which was originally budgeted into the implementation plan anyway. The agreement would allow the company to have a number of consulting hours by a Microsoft Exchange insider, Sheldon said.

"The Microsoft TAM [technical account manager] comes in, gathers information and interviews people, and comes up with a recommendation for where we go next," he said.

So now, the IT group is waiting to see what the TAM will decide is the best course of action. Meanwhile, Sheldon and Serge are trying to decide how to deal with some organizational issues that will become important for their division of the company when they migrate to the upgrade. For example, that division uses several special characters to denote certain accounts on their Exchange 5.5 server, and those characters are not supported in Exchange 2000. Their concern is that it is going to involve end-user training they hadn't budgeted for.

At least they have something to do while they wait. We'll hear more from Sheldon and Serge as their Exchange 2000 migration progresses.

Editor's Picks

Free Newsletters, In your Inbox