Read an Excerpt

• Planning for Disaster
• Identifying the Risks
• Identifying the Resources
• Developing the Responses
• Testing the Responses
• Iterating
• Preparing for a Disaster
• Setting Up a Fault-Tolerant System
• Backing Up the System
• Creating Automated System Recovery Disks
• Creating a Boot Disk
• Installing the Recovery Console
• Specifying Recovery Options
• Creating and Using a Recovery Drive
• Summary

Chapter 36  Disaster Planning

Smart bicycle riders wear helmets even though they ride carefully and certainly don’t plan a headfirst landing. Schools and businesses have fire drills even though the vast majority of buildings never burn down. Similarly, system administrators sincerely hope they will never need their verified backups and Automated System Recovery disks. Nevertheless, we keep them because there are only two types of networks: those that have experienced disaster and those that haven’t yet.

Disaster can take many forms, from the self-inflicted pain of a user or administrator doing something really, really unwise to the uncontrollable, unpreventable results of a natural disaster such as a flood or earthquake. In any case, your competence as a system administrator will be judged by how well you were prepared for the disaster and how well you and your team responded to it and recovered from it.

This chapter covers emergency preparedness. It discusses creating a disaster recovery plan, with standardized procedures to follow in the event of a catastrophe. It also describes how to prepare for a disaster, including how to make an Automated System Recovery disk, how to make a boot disk, how to install the Recovery Console, how to specify recovery options in Windows Server 2003, and how to create an external recovery drive.

Planning for Disaster

Some people seem to operate on the assumption that if they don’t think about a disaster, one won’t happen. This is similar to the idea that if you don’t write a will, you’ll never die—and just about as realistic. No system administrators should feel comfortable about their network’s degree of preparedness without a clear disaster recovery plan that has been thoroughly tested. Even then, it’s wise to always look for ways to improve the plan. You also need to understand the limitations of any disaster recovery plan: none of them are perfect, and even the best disaster recovery plan needs to be constantly examined and adjusted or it quickly gets out of date.

Planning for disaster or emergencies is not a single step, but an iterative, ongoing process. Systems are not mountains, but rivers, constantly moving and changing, and your disaster recovery plan needs to change as your environment changes. To put together a good disaster recovery plan, one you can bet your business on, you need to follow these steps:

1. Identify the risks
2. Identify the resources
3. Develop the responses
4. Test the responses
5. Iterate

Identifying the Risks

The first step in creating a disaster recovery plan is to identify the risks to your business and the costs associated with those risks. The risks vary from the simple deletion of a critical file to the total destruction of your place of business and its computers. To properly prepare for a disaster, you need to perform a realistic assessment of the risks, the potential costs and consequences of each disaster scenario, the likelihood of any given disaster scenario, and the resources available to address the risks. Risks that seemed vanishingly remote a few years ago are now part of our everyday life.

Identifying risks is not a job for only one person. As with all of the tasks associated with a disaster recovery plan, all concerned parties must participate. There are two important reasons for this: you want to make sure that you have commitment and buy-in from the parties concerned, and you also want to make sure you don’t miss anything important.

No matter how carefully and thoroughly you try to identify the risks, you’ll miss at least one. You should always account for that missing risk by including an "unknown risk" item in your list. Treat it just like any other risk: identify the resources available to address it and develop countermeasures to take should it occur. The difference with this risk, of course, is that your resources and countermeasures are somewhat more generic, and you can’t really test your response to the risk, because you don’t yet know what it is.

Start by trying to list all of the possible ways that your system could fail. If you have a team of people responsible for supporting the network, solicit everyone’s help in the process. The more people involved in the brainstorming, the more ideas you’ll get and the more prevention and recovery procedures you can develop and practice.

Next, look at all of the ways that some external event could affect your system. The team of people responsible for identifying possible external problems is probably similar to a team looking at internal failures, but with some important differences. In a large industrial plant, for example, when you start to look at external failures and disasters, you’ll want to involve the security and facilities groups, because they will need to understand your needs as well as provide input on how well the plant is protected from these disasters.

An important part of this risk assessment phase is to understand and quantify just how likely a particular risk is. If you’re located in a flood plain, for example, you’re much more likely to think flood insurance is a good investment.

Identifying the Resources

Once you’ve identified the risks to your network, you need to identify what the resources are to address those risks. These resources can be internal or external, people or systems, hardware or software.

When you’re identifying the resources available to deal with a specific risk, be as complete as you can, but also be specific. Identifying everyone in the IT group as a resource to solve a crashed server might look good, but realistically only one or two key people are likely to actually rebuild the server. Make sure you identify those key people for each risk, as well as what more general secondary resources they have to call on. So, for example, the primary resources available to recover a crashed Microsoft Exchange server might consist of one or two staff members who can recover the failed hardware and another one or two staff members who can restore the software and database. General secondary resources would include everyone in the IT group as well as the hardware vendor and Microsoft Premier Support.

An important step in identifying resources in your disaster recovery plan is to specify both the first-line responsibility and the back-end or supervisory responsibility. Make sure everyone knows who to go to when the problem is more than they can handle or when they need additional resources. Also, clearly define when they should do that. The best disaster recovery plans include clear, unambiguous escalation policies. This takes the burden off individuals to decide when and who to notify and makes it simply part of the procedure.

Developing the Responses

An old but relevant adage comes to mind when discussing disaster recovery scenarios: when you’re up to your elbows in alligators, it’s difficult to remember that your original objective was to drain the swamp. This is another way of saying that people lose track of what’s important when they are overloaded by too many problems that require immediate attention. To ensure that your swamp is drained and your network gets back online, you need to take those carefully researched risks and resources and develop a disaster recovery plan. There are two important parts of any good disaster recovery plan:

• Standard operating procedures (SOPs)
• Standard escalation procedures (SEPs)

Making sure these procedures are in place and clearly understood by all before a disaster strikes puts you in a far better position to recover gracefully and with a minimum of lost productivity and data.

Standard Operating Procedures

Emergencies bring out both the best and worst in people. If you’re prepared for the emergency, you can be one of those who come out smelling like a rose, but if you’re not prepared and let yourself get flustered or lose track of what you’re trying to accomplish, you can make the whole situation worse than it needs to be.

Although no one is ever as prepared for a system emergency as they’d like to be, careful planning and preparation can give you an edge in recovering expeditiously and with a minimal loss of data. It is much easier to deal with the situation calmly when you know you’ve prepared for this problem and you have a well-organized, tested standard operating procedure (SOP) to follow.

Because the very nature of emergencies is that you can’t predict exactly which one is going to strike, you need to plan and prepare for as many possibilities as you can. The time to decide how to recover from a disaster is before the disaster happens, not in the middle of it when users are screaming and bosses are standing around looking serious and concerned.

Your risk assessment phase involved identifying as many possible disaster scenarios as you could, and in your resource assessment phase you identified the resources that are available and responsible for each of those risks. Now you need to write up SOPs for recovering the system from each of the scenarios. Even the most level-headed system administrator can get flustered when the system has crashed, users are calling every 10 seconds to see what the problem is, the boss is asking every 5 minutes when you’ll have it fixed, and your server won’t boot. And that’s the easy case compared to the mess that can be caused by an external disaster.

Reduce your stress and prevent mistakes by planning for disasters before they occur. Practice recovering from each of your disaster scenarios. Write down each of the steps, and work through questionable or unclear areas until you can identify exactly what it takes to recover from the problem. This is like a fire drill, and you should do it for the same reasons—not because a fire is inevitable, but because fires do happen, and the statistics demonstrate irrefutably that those who have prepared for a fire and practiced what to do in a fire are far more likely to survive it.

Your job as a system administrator is to prepare for disasters and practice what to do in those disasters, not because you expect the disaster, but because if you do have one, you want to be the hero, not the goat. After all, it isn’t often that the system administrator gets to be a hero, so be ready when your time comes.

The first step in developing any SOP is to outline the overall steps you want to accomplish. Keep it general at this point—you’re looking for the big picture here. Again, you want everyone to be involved in the process. What you’re really trying to do is make sure you don’t forget any critical steps, and that’s much easier when you get the overall plan down first. There will be plenty of opportunity later to cover the specific details.

Once you have a broad, high-level outline for a given procedure, the people you identified as the actual resources during the resource assessment phase should start to flesh in the outline. You don’t need every detail at this point, but you should get down to at least a level below the original outline. This will help you identify missing resources that are important to a timely resolution of the problem. Again, don’t get too bogged down in the details at this point. You’re not actually writing the SOP, just trying to make sure that you’ve identified all of its pieces.

When you feel confident that the outline is ready, get the larger group back together again. Go over the procedure and smooth out the rough edges, refining the outline and listening to make sure you haven’t missed anything critical. When everyone agrees that the outline is complete, you’re ready to add the final details to it.

The people who are responsible for each procedure should now work through all of the details of the disaster recovery plan and document the steps thoroughly. They should keep in mind that the people who actually perform the recovery might not be who they expect. It’s great to have an SOP for recovering from a failed router, but if the only person who understands the procedure is the network engineer, and she’s on vacation in Bora Bora that week, your disaster recovery plan has a big hole in it.

When you create the documentation, write down everything. What seems obvious to you now, while you’re devising the procedure, will not seem at all obvious in six months or a year when you suddenly have to use it under stress.

REAL WORLD:
Multiple Copies, Multiple Locations

It’s tempting to centralize your SOPs into a single, easily accessible database. You should do that, making sure everyone understands how to use it. But you’ll also want to have alternative locations and formats for your procedures. Not only do you not want to keep the only copy in a single database, you also don’t want to have only an electronic version. Always maintain hard copy versions as well. The one thing you don’t want to do is create a single point of failure in your disaster recovery plan!

Every good server room should have a large binder, prominently visible and clearly identified, that contains all of the SOPs. Each responsible person should also have one or more copies of at least the procedures he or she is either a resource for or likely to become a resource for. We like to keep copies of all our procedures in several places so that we can get at them no matter what the source of the emergency or where we happen to be when one of our pagers goes off.

Once you have created the SOPs, your job has only begun. You need to keep them up to date and make sure that they don’t become stale. It’s no good having an SOP to recover your ISDN connection to a branch office when you ripped the ISDN line out a year ago and put in a DSL line with three times the bandwidth at half the cost.

You also need to make sure that all of your copies of an SOP are updated. Electronic ones should probably be stored in a replicated database. However, hard copy documents are notoriously tricky to maintain. A good method is to make yet another SOP that details who updates what SOPs and who gets fresh copies whenever a change is made. Then put a version control system into place and make sure everyone understands his or her role in the process. Build rewards into the system for timely and consistent updating of SOPs—if 10 or 20 percent of your staff’s bonus is dependent on keeping those SOPs up to date and distributed, you can be sure they’ll be done as often as the review process.

Standard Escalation Procedures

No matter how carefully you’ve identified potential risks, and how detailed your procedures to recover from them, you’re still likely to have situations you didn’t anticipate. An important part of any disaster recovery plan is a standardized escalation procedure. Not only should each individual SOP have its own procedure-specific SEP, but you should also have an overall escalation procedure that covers everything you haven’t thought of—because it is certain that you haven’t thought of everything.

An escalation procedure has two functions—resource escalation and notification escalation. Both have the same purpose: to make sure that everyone who needs to know about the problem is up to date and involved as appropriate, and to keep the overall noise level down so that the work of resolving the problem can go forward as quickly as possible. The resource escalation procedure details the resources that are available to the people who are trying to recover from the current disaster, so that they don’t have to try to guess who (or what) the appropriate resource might be when they run into something they can’t handle or something doesn’t go as it is supposed to. This helps them stay calm and focused. They know that if they run into a problem, they aren’t on their own, and they know exactly who to call when they do need help.

The notification escalation procedure details who is to be notified of serious problems. Even more important, it should provide specifics regarding when notification is to be made. If your print server crashes but comes right back up, you might want to send a general message only to the users of that particular server letting them know what happened. However, if your mail server has been down for more than half an hour, a lot of folks are going to be concerned. The SEP for that mail server should detail who needs to be notified if the server is unavailable for longer than some specified time, and it should probably detail what happens and who gets notified when it’s still down some significant amount of time after that.

This notification has two purposes: to make sure that the necessary resources are made available as required and to keep everyone informed and aware of the situation. If you let people know that you’ve had a server hardware failure and that the vendor has been called and will be on site within an hour, you’ll cut down the number of phone calls exponentially, freeing you to do whatever you need to do to ensure that you’re ready when the vendor arrives.

Testing the Responses

A disaster recovery plan is nice to have, but it really isn’t worth a whole lot until it has actually been tested. Needless to say, the time to test the plan is at your convenience and under controlled conditions, rather than in the midst of an actual disaster. It’s a nuisance to discover that your detailed disaster recovery plan has a fatal flaw in it when you’re testing it under controlled conditions. It’s a bit more than a nuisance to discover it when every second counts.

You won’t be able to test all aspects of all disaster recovery plans. Few organizations have the resources to create fully realistic simulated natural disasters and test their response to each of them under controlled conditions. Nevertheless, there are things you can do to test your response plans. The details of how you test them depend on your environment, but they should include as realistic a test as feasible and should, as much as possible, cover all aspects of the response plan. The other reason to test the disaster recovery plan is that it provides a valuable training ground. If you’ve identified primary and backup resources, as you should, chances are that the people you’ve identified as backup resources are not as skilled or knowledgeable in a particular area as the primary resource. Testing the procedures gives you a chance to train the backup resources at the same time.

You should also consider using the testing to cross-train people who are not necessarily in the primary response group. Not only will they get valuable training, but you’ll also create a knowledgeable pool of people who might not be directly needed when the procedure has to be used for real, but who can act as key communicators with the rest of the community.

Iterating

When you finish a particular disaster recovery plan, you might think your job is done, but in fact your work is just beginning. Standardizing a process is actually just the first step. You also need to improve it.

You should make a regular, scheduled practice of pulling out your disaster recovery plan with your group and making sure it’s up to date. Use the occasion to actually look at it and see how you can improve on it. Take the opportunity to examine your environment. What’s changed since you last looked at the plan? What servers have been retired, and what new ones have been added? What software is different? Are all of the people on your notification and escalation lists still working at the company in the same roles? Are the phone numbers up to date?

Another way to iterate your disaster recovery plan is to use every disaster as a learning experience. Once the disaster or emergency is over, get everyone together as soon as possible to talk about what happened. Find out what they think worked and what didn’t in the plan. Actively solicit suggestions for how the process could be improved. Then make the changes and test them. You’ll not only improve your responsiveness to this particular type of disaster, but you’ll improve your overall responsiveness by getting people involved in the process and enabling them to be part of the solution.

Preparing for a Disaster

As Ben Franklin was known to say, "Failure to prepare is preparing to fail." This is truer than ever with modern operating systems, and although Windows Server 2003 includes a number of exceptionally useful recovery modes and tools, you still need to prepare for potential problems. Some of these techniques are covered in detail in other chapters and are discussed here only briefly, whereas others are covered here at length.

Setting Up a Fault-Tolerant System

A fault-tolerant system is one that is prepared to continue operating in the event of key component failures. This technique is very useful for servers running critical applications. Here are a few of the many ways to ensure fault tolerance in a system:

• Use one or more RAID arrays for system and data storage, protecting you from hard disk failure. If a hard disk in the array fails, only that disk needs to be replaced—and no data is lost. See Chapter 17 for information about using Windows Server 2003 to implement software RAID.
• Use multiple SCSI adapters to provide redundancy if a SCSI controller fails.
• Use an uninterruptible power supply (UPS) to allow the server to shut down gracefully in the event of a power failure.
• Use multiple network cards to provide redundancy in case a network card fails.
• Use multiples of everything that is likely to fail, including power supplies and so on.
• Use clusters to provide redundancy and failover in the event of a server failure. See Chapter 18 for information about implementing clusters in Windows Server 2003.

Backing Up the System

Back up the system and system state regularly using a good Windows Server 2003 backup program. If a hard disk fails and must be replaced and you’re not using some sort of RAID array, the data and system can be restored from backup. (If you lose the system entirely, you’ll need to install Windows Server 2003 on it before restoring the original system.) See Chapter 37 for details on using the Windows Server 2003 backup program.

Creating Automated System Recovery Disks

Whereas Microsoft Windows NT and Microsoft Windows 2000 created an emergency repair disk (ERD) to help rescue the system in the event of a disaster, the Windows Server 2003 family creates an Automated System Recovery (ASR) disk. The ASR disk contains important information that can be used to fix system files, the boot sector, and the startup environment. The ASR disk is easy to make, and it is very useful in the event of a disaster.

TIP:
In Windows Server 2003, you might have noticed that you didn’t get prompted to create an ERD during installation, as you do during Windows NT setup. In fact, the entire procedure has changed. Now, instead of an ERD, you run the Backup program in Windows Server 2003 to create an ASR disk and backup. To make a fresh ASR disk, you need a floppy disk that you don’t mind being formatted and a fresh tape for your tape drive (or fresh Zip disk, or other applicable media, for your target backup device). Always use a freshly formatted floppy disk to create an ASR disk. It’s also a good idea to have a backup of your ASR disk, so always keep at least one generation back. We also like to keep an original ASR disk created immediately after the installation process as a kind of ultimate fallback position.

To make an ASR disk, follow these steps:

1. Open the Windows Server 2003 Backup program from the Start menu by pointing to Programs, Accessories, and System Tools and then choosing Backup.
2. Switch to the Advanced Mode if you get a wizard prompt.
3. Click Automated System Recovery, as shown in Figure 36-1 to open the Automated System Recovery Preparation Wizard, shown in Figure 36-2. Click Next.

Figure 36-1.  The Windows Server 2003 Backup Utility window. (Image unavailable)

Figure 36-2.  The Automated System Recovery Preparation Wizard. (Image unavailable)

4. In the Backup Destination screen shown in Figure 36-3, select the backup type and destination you’ll be using. Windows Server 2003 doesn’t support directly writing to CD or DVD, but you can write to any device that is supported by the Windows Backup program. Click Next.

Figure 36-3.  The Backup Destination screen. (Image unavailable)

5. Click Finish to complete the wizard. The backup starts automatically when you exit the wizard, as shown in Figure 36-4.

Figure 36-4.  The Backup Progress dialog box. (Image unavailable)

6. Once the backup has completed, you’ll be prompted to insert a blank floppy disk to create the ASR disk, as shown in Figure 36-5.

Figure 36-5.  Insert a formatted, blank floppy disk for ASR to use. (Image unavailable)

7. Insert a blank floppy disk in drive A, and click OK.
8. Backup writes the necessary files to the floppy disk and confirms that the process has been successful, as shown in Figure 36-6. Label the disk and the backup media used as requested and store them in a safe place.

Figure 36-6.  The Windows Backup utility confirms the successful creation of the ASR disk. (Image unavailable)

NOTE:
The ASR disk is not bootable; it must be used in conjunction with the Windows Server 2003 installation media. REAL WORLD:
Using the ASR Set Effectively

What, exactly, is on the ASR disk? Well, certainly not all the stuff that used to be there in Windows NT. Instead of trying to fit all of the files necessary to recover your system onto a single floppy disk, a task that had become more than a little problematic, Windows Server 2003 now copies only three files to the floppy:

• Setup.log Points to the location of system files on your server
• Asr.sif Contains information on disk, partitions and volumes on the system, and the location of the backup media used
• Asrpnp.sif Contains information on the various plug and play devices on the system

With this change, it’s easy to maintain multiple generations of repair information, because each ASR disk points to a specific system backup. You should always keep the ASR disk with the specific backup that it was made with.

Whenever you make a major change to your system, it’s a good idea to make a fresh ASR set before you make the change. This gives you a fallback position if something goes wrong. If something doesn’t work right, you can quickly restore the previous configuration. Once you’ve confirmed that the new configuration is stable and working, then and only then should you update your ASR set for that server.

What constitutes a major change? Adding, removing, or otherwise modifying the hard disks or their partitions, formats, configurations, and so on, for one. Any time you make a change to the hard disk configuration, you’ll definitely want to make a fresh ASR set just before you make the change. Another major change would be the addition of a new component to the server, such as adding Microsoft Exchange Server or Microsoft SQL Server. Any changes made from Control Panel are candidates for redoing the ASR set as well.

Creating a Boot Disk

With Windows Server 2003, you can still create a useful boot disk that can help with recovery in the event something corrupts a critical file on your hard disk. Although this is less important these days, because you can add the recovery console to your boot menu, or run it from the Windows Server 2003 installation CD-ROM, we’re the cautious type; we like to have every possible way to recover available. Although a Windows Server 2003 boot disk doesn’t get you to a command prompt, as a Microsoft Windows 95 or Microsoft Windows 98 boot disk does, it does permit you to boot the system under the following circumstances (provided that your actual Windows Server 2003 installation isn’t damaged in any other way):

• Corrupted boot sector
• Corrupted master boot record (MBR)
• Virus infections of the MBR
• Missing or corrupt Ntldr or Ntdetect.com files

The boot disk can also be used to boot from the shadow drive of a broken mirror set, although you might need to edit the Boot.ini file on the boot disk.

REAL WORLD:
Why MS-DOS Boot Disks Won’t Help

More than one person new to Windows Server 2003 has accidentally deleted or corrupted a key file required to boot the system and tried to recover by digging out an old MS-DOS or Windows boot floppy disk. Alas, it doesn’t work.

The files you need to get your hard disk back to booting condition aren’t even on an MS-DOS floppy disk. When you install Windows Server 2003, it modifies the system’s boot sector to look for and run a file called Ntldr. When you format a floppy disk under MS-DOS, even when you make it a system disk, this file doesn’t get created, because MS-DOS doesn’t know anything about Windows Server 2003.

As such, a boot disk is occasionally useful, and because it’s easy to make and floppy disks grow on trees (although these trees are rarely seen outside of the Microsoft campus), you might as well make one. The boot disk is not generic for every Windows Server 2003 machine. However, if you have a standard configuration across several machines, this disk will work for all of the machines that use the same partition and disk controller as their Windows Server 2003 boot partition. Follow these steps to create a boot disk:

1. Insert a blank floppy disk into your floppy drive.
2. At a command prompt, type the command format a: /u.
3. Copy the Ntdetect.com and Ntldr files from the \i386 folder on the Windows Server 2003 CD-ROM to the floppy disk.
4. Create a Boot.ini file, or copy the file from the boot drive to the floppy disk.

REAL WORLD:
ARC Naming Conventions

Understanding how the hard disks and partitions are named on your system is not a trivial task, unfortunately. To provide a uniform naming convention across multiple platforms, Microsoft uses a fairly arcane designation for all of the disks and partitions on your computer. Called ARC—short for Advanced RISC Computing—this is a generic naming convention that can be used in the same way for both Intel-based and RISC-based computers.

The convention describes the adapter type and number, the disk number, the rdisk number, and finally the partition number. The format is as follows:

<adaptertype>(x)disk(y)rdisk(z)partition(n)

where <adaptertype> can be either SCSI, multi, or signature. Use multi for all non-SCSI adapters and for SCSI adapters that use a BIOS—as most adapters used with Intel-based processors do. The (x) is the adapter number, starting at zero. If <adaptertype> is signature, (x) is an 8-character drive signature.

The value for (y) is the SCSI ID of the disk for SCSI adapters. For multi this is always zero. The number for (z) is zero for SCSI, and is the ordinal number of the disk for multi, starting with zero. Finally, the partition number (n) is the number of the partition on the target disk. Here the partitions start at one, with zero reserved for unused space.

Installing the Recovery Console

One of the most useful recovery features in Windows Server 2003 is the Recovery Console. This is basically an enhanced, NTFS-enabled, secure command prompt that can be used to copy files, start and stop services, and perform other recovery actions if you can’t boot the system using Windows Server 2003’s safe mode. The Recovery Console is always available for use through the Windows Server 2003 CD-ROM; however, you can also install it as an option on the Boot menu for use in those instances when you can’t boot using Windows Server 2003 safe mode. You’ll still need to use the boot disk if you can’t get to the Boot menu or if the Recovery Console is damaged. To install the Recovery Console, follow these steps:

1. While in Windows Server 2003, insert the Windows Server 2003 CD-ROM.
2. Close the Autorun dialog box.
3. At a command prompt or in the Run dialog box, type the command d:\i386\winnt32 /cmdcons, replacing d with the drive letter of the Windows Server 2003 CD-ROM or network share.
4. Click Yes to install the Recovery Console, as shown in Figure 36-7.

Figure 36-7.  The Windows Server 2003 Setup window. (Image unavailable)

Specifying Recovery Options

You can specify how you want Windows Server 2003 to deal with system crashes by changing a few options in the System tool in Control Panel. To do so, follow these steps:

1. Open the System tool from Control Panel, and click the Advanced tab.
2. Click Settings in the Startup And Recovery box to display the Startup And Recovery dialog box, shown in Figure 36-8.

Figure 36-8.  The Startup And Recovery dialog box. (Image unavailable)

3. If you have multiple operating systems on the machine, select the operating system you want to have boot by default from the Default Operating System list box.
4. If you want to boot the default operating system automatically, without waiting, clear the Time To Display List Of Operating Systems check box. Otherwise, specify how long you want to display a list of options in the box provided.
5. If you want recovery options automatically displayed in the event of problems, select the Time To Display Recovery Options When Needed check box, and set the time for it.
6. Select the Write An Event To The System Log check box, if available, to record an entry in the event log when the system experiences a crash.
7. Select the Send An Administrative Alert check box to send an alert to administrators over the network when the system crashes.
8. Select the Automatically Restart option to instruct Windows Server 2003 to reboot the system in the event of a crash. Otherwise the system remains at a blue screen until an administrator manually reboots it.
9. Select how much debugging information you want to record from the Write Debugging Information list box. Note that if you have a large amount of RAM you need the same amount of free disk space if you want to use the Complete Memory Dump option.
10. Enter the filename for the dump file in the Dump File text box, and select the Overwrite Any Existing File check box to maintain only a single dump file.

Creating and Using a Recovery Drive

An excellent way to recycle an old, small drive that’s not good for much else is to use it as an external recovery drive. This drive needs to be only about 2 GB or so, smaller than you could even buy today. The recovery drive can even be used for several servers if you set it up as a portable device. Using a recovery drive in this way offers a somewhat cheaper alternative to mirroring the drive.

To create the recovery drive, perform a minimal install of Windows Server 2003 on the drive, configuring your swap file to be on that drive. Make sure that the installation includes the tape driver you will be using for tape backup. Create a bootable Windows Server 2003 floppy disk, following the procedure outlined earlier in the section entitled "Creating a Boot Disk," and edit the Boot.ini file on it to point to the SCSI address of the recovery drive.

When a system failure occurs, simply cable the recovery drive to the server and boot from the boot disk that points to the recovery drive. If the recovery drive has sufficient user accounts and software to keep your system running, you can run off the recovery drive until you can schedule a full-scale repair or replacement of the failed drive. When you are able to take the system down and replace the failed drive, all you need to do is restore your backup tape to it and restart the server. You can even do the restore in the background while you continue to run off the recovery drive if necessary.

Summary

Assume that disaster will eventually occur, and plan accordingly. Create standardized recovery procedures and keep them up to date. When there’s a lot of turmoil, as always happens in the case of a major failure, people forget important steps and can make poor decisions. Standardized procedures provide a course of action without the need for on-the-spot decisions. The next chapter describes how to use the Windows Server 2003 Backup utility.