Scheduled maintenance and downtime have been on my mind a lot lately. I recently moved about 600 miles, and one of the most crucial aspects of the planning process was ensuring as little downtime as possible for my Exchange Server system. Subtracting out the time required to physically move the server from point A to point B, the server was down for only about 45 minutes, and I didn't lose any email during the move. Even if you aren't planning to relocate an Exchange server, you might find some of the techniques I used worth investigating.
The first step in planning a physical hardware move is to develop a timeline. Begin at the end: When does the server need to be back up in its new location? (Depending on when and why you're moving, this deadline might be the time when the system must be in place or the earliest possible time that you can move the system to its new quarters.) Knowing this fact lets you work backwards, determining the time needed for each interim step—how much time you'll need to set up the server in the new location, how much time you'll need to physically move the equipment—so that you can decide when to take down the first Exchange server and the date and time when the move will begin (i.e., when you'll remove the first component, whether it's an Exchange server, some other computer, or a network device). That way, you can keep the server running as long as possible in its original location.
Next, make a list of preconditions for the move. A little double-checking at this stage of the game can save you a lot of grief later. Confirm that you'll have building access, electrical service, and network access when you need it—especially if you're moving to a building or facility that your organization doesn't own. Consider all the resources that need to be in place at the new location. Make sure that the relocated server will have adequate access to domain controllers (DCs), Global Catalog (GC) servers, DNS servers, and the other support systems that Exchange depends on. For example, to simplify my move, I used Dcpromo to promote my Exchange server to a DC, then used the Microsoft Management Console (MMC) Active Directory Sites and Services snap-in to make the system a GC server. Although colocating these services isn't something I'd do permanently in a production network, it let me bring up one machine instead of two—a worthwhile simplification.
Next, make contingency plans in case one or more of your preconditions can't be met. What if the network connection at the new location isn't ready when it's supposed to be? What if you can't turn on the power at the new facility on the day you plan to install the servers? You can do little to control certain situations (e.g., you can't make the telephone company move your order along any faster), so plan what you'll do in the event that something isn't ready on time.
Of course, none of your support systems will do any good if you don't have network connectivity to your LAN and (if necessary) to the Internet. Because Internet connectivity usually comes from outside providers, make sure you have up-to-date information about when the providers will cut off your old service and start your new service. Whenever possible, make sure that the new service is up and tested before you cut off the old one. This practice can let you keep running in the old location if you need to delay your move.
The physical aspects of the move are worth thinking about, too. Make sure your server has adequate physical protection; don't just toss it in the back of a truck. A special note for rack-mounted servers: Be sure that whoever is moving them secures the rack or its carrying case so that it doesn't tip over. I once lost a four-node cluster to an impatient truck driver who forgot to strap down the shipping case before driving off. Fortunately, insurance covered that loss—which brings up another point. Make sure your insurance policy covers damage or loss of equipment in transit.
If you're already in the habit of making regular backups, you'll be well prepared for this next piece of advice: Make a complete online backup of your Exchange server and its system state, using whatever backup tool you like. Don't forget to update the Emergency Repair Disk (ERD). And if you're running Windows 2000, now would be a good time to install the Win2K Recovery Console (RC), if you haven't already done so (simply run Windows Setup with the /cmdcons switch). These measures will help ensure that you can recover your server if something happens to it en route.
Next week, I'll discuss how to ensure that your SMTP mail isn't lost during the move. This knowledge is valuable even if you aren't moving because you can apply it to keep mail flowing when your SMTP server isn't accepting calls.
