By now, Exchange 2000 has been out for a few months, and you might be considering upgrading your existing mail system. Before you jump right into an upgrade, however, you should take a look around the Internet. The Web is filled with reports from people complaining of disastrous upgrades. Likewise, many people who’ve upgraded from Exchange 5.5 have experienced trouble working with Exchange 2000 after the upgrade because the two versions are so different from each other.
I recommend that, to avoid these and other upgrade-related nightmares, you create a test environment before rolling Exchange 2000 out on your production network. In this Daily Drill Down, I’ll explain the best way to build a test network and some ways you can get used to Exchange 2000.
Why is testing important?
Right now, you may be wondering if testing is really that important. After all, building a test network is a lot of work. Besides that, if you don’t already have some hardware to spare, building a test network can be expensive. Testing, however, is an extremely important part of the upgrade process for several reasons.
For starters, as I mentioned earlier, many people have had really bad luck upgrading from Exchange 5.5 to Exchange 2000. I’ve personally upgraded two Exchange 5.5 servers, and the process went smoothly both times, but from everything I’ve heard, I was lucky. Building a test network can give you the chance to find out how the upgrade process will go—but in a safe environment where there’s no risk of compromising your data. If the upgrade does get messy, having a test lab gives you the chance to simply start over and find a better upgrade method.
Testing is also important from a usability standpoint. For example, you’ll want to find out what the end-user experience will be like. Will the existing client software work with Exchange 2000? If so, what will it look like? Will the users have to do anything differently? Building a test lab can help you to answer these questions before the first user ever sees the new client software. Believe me, it’s no fun getting phone calls from a thousand confused users after an upgrade.
In addition, building a test lab will give you some time to become familiar with the process of interacting with Exchange 2000. Remember that the Exchange Administrator program doesn’t exist in Exchange 2000. Instead, all the administrative tasks are performed through the Microsoft Management Console. This, in itself, wouldn’t be a big deal except that the way you perform many common tasks has changed significantly.
Suppose for a moment that you upgraded your Exchange 5.5 servers to Exchange 2000. Now imagine that at first everything seemed to go well, but then there was a problem. You’ve seen the problem before and realize the problem may be related to the Internet Mail Connector. Unfortunately, you have no idea how to check the Internet Mail Connector under the new interface—or whether the Internet Mail Connector even exists in Exchange 2000, for that matter. In the meantime, while you’re fumbling around through an unfamiliar interface looking for something you’re not even sure exists, the phone is ringing off the hook with calls from hundreds of irate users. Your boss is also banging on the door every few minutes wanting to know how long until the problem is fixed.
If this real-life situation doesn’t help you to understand the importance of testing, don’t even bother reading the rest of this Daily Drill Down. If you’d rather avoid these and other potential problems, though, then it’s time to talk about how to set up a test environment.
Building a test lab
Before I delve into the issues involved in building a test lab, the first thing you need to know is that for the test lab to work well, it must be taken seriously by you and by upper management. The test lab is much more than just a place to see whether Exchange 2000 is going to work on your network. Instead, it’s a place where just about anything can be tested. For example, suppose a new Windows 2000 service pack was released. You could try out the service pack on the test network to make sure that it’s stable before you install it on the production network.
The reason I say both you and upper management must take the test lab seriously is because I’ve seen big problems caused by either the administrators or the managers not seeing the test lab for what it really was. In fact, until I started my own business, no company I had ever worked for was able to successfully maintain a test lab.
For a test lab to work, you must gain the support of upper management. To do so, I’ve found you have to convince them that although building a test lab is expensive, the benefits far outweigh the costs. For example, suppose a glitch in a new service pack was found to corrupt all the Exchange databases. It would be very costly for this to happen in a production environment. The Exchange servers would be unavailable for some time, there could be tremendous data loss, and the IT staff would be working overtime to fix the problem. However, if you found out about this problem in a test lab first, then you’d know not to install the service pack on the production network.
As I mentioned, building a test network can be expensive. You’ll need servers, workstations, hubs, and all of the other networking hardware that’s typical for such networks. You’ll also have to find a suitable room in the building. Once you’ve found a room to use, you’ll need desks, chairs, bookshelves, and other types of furniture. The idea is to make the test network into a miniature version of your company’s server room.
In my own personal experience, I’ve seen upper management shell out the money for this type of project but still not take it seriously. At one company I worked for, one of the managers decided that the test network room would make a good storage closet. The room quickly became a high-traffic room that was accessible by everyone in the building and was cluttered with junk. Even the desks containing the servers quickly became buried under boxes and stacks of paper.
At a different company, after a few months, the president of the company decided it would be a good idea to “borrow” things from the test room. One day, he came to me and said that a certain user wanted a faster PC, so he had given that user one of the test servers. Another day, he told me that someone needed another chair and he was giving that person one of our chairs. Within the course of a year, the test lab was unusable because the president of the company didn’t understand the importance of it and had taken most of our equipment.
On the flip side, though, I’ve also seen administrators not take the test lab seriously. Remember that for the test lab to be effective, it has to mimic the real network. This means it must be maintained like the real network. I’m not just talking about applying service packs when they come out because you’d put those on the test network first anyway. I’m talking about keeping the test environment consistent.
It’s easy to go into a test network and say, “Wonder what would happen if I made this change?” You may not document the change, and it may soon be forgotten. However, this configuration change may affect the outcome of some test later on down the road. I’ve seen test labs that had so many undocumented changes made that it didn’t even resemble the production network after a while.
I strongly recommend that after you make a change to anything on your test network, you document the change. After a specified test period, either undo the change or implement it on the production network. If it’s impossible to undo the change and it’s something you don’t want to do on the production network, go ahead and bite the bullet and restore a backup or reformat the test server so that the test environment can remain consistent with the production environment.
Building the test network
Now that you have some general guidelines on how to use a test network—and a few horror stories to back them up—let’s look at the process of building a test network. The most important thing about a test network is that it should be completely isolated from your production network. That way, there’s no danger of an experiment that’s gone wrong affecting the traffic flow on the production network. If you absolutely have to, you can get away with sharing an Internet connection between the two networks, but I strongly recommend using a separate Internet connection.
The next thing I recommend is to try to mimic the same type of servers you use in your production network. After all, how will you know if that new software package will bog down the servers if your test servers are considerably faster or slower than the production servers? Likewise, the test servers should use the same hard disk configuration as the real servers. Remember that Exchange has some fairly stringent recommendations on where to put the various files. Having a similar hard disk configuration will help you be able to reproduce the configuration that’s used in the real environment.
I also strongly recommend using the same type of backup device used in the production environment. There are two reasons for this. First, as I mentioned earlier, there will be times when you’ll need to completely reload the test servers. It’s easier to restore a backup than to reload everything from scratch. The other reason is that in the event of a major failure on the production network, you may be able to restore a production backup to a test machine and temporarily use your test machine to take the place of the production machine that has died.
As I stated earlier, your test network should mimic the production network in every way possible. Data is no exception. If you’re starting out with Exchange 5.5 servers and looking to test an upgrade to Exchange 2000, you don’t want to simply run the test against an empty Exchange database. The results would be unreliable. Instead, why not borrow a copy of the Priv.edb, Pub.edb, and Dir.edb files from a few production Exchange boxes? By doing so, you’ll have a copy of all the user accounts and mailboxes on the test servers. Because no one will actually be using these servers for production purposes, you don’t have to worry about keeping the data up-to-date, but having a copy of the Exchange databases (even if it’s an old copy) will give you something to play with.
Now for the last piece of the test network: workstations. I recommend setting up a few workstations that mimic the typical machines the end users use. This will give you a chance to see how the different desktop operating systems react to changes you make on your test network. It will also give you a chance to test desktop applications before making the new applications available to your users.
In this Daily Drill Down, I explained the importance of testing Exchange 2000 before rolling it out on your production network. As I did, I walked you through the process of creating a test environment.
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.