I've always believed that maintaining up-to-date Emergency Repair Disks (ERDs) is a vital part of a comprehensive disaster-recovery plan. However, regularly creating or updating ERDs on each server and workstation was tedious and time-consuming. Inevitably, keeping my ERD library current fell by the wayside in favor of more urgent tasks. Most administrators are familiar with this story and its unfortunate ending: Eventually, a critical server went down with a corrupted Registry, and I was stuck without an ERD. Reinstalling the OS, reapplying the correct service pack, and restoring system data from backup tapes took 2 hours of my time (not to mention the costly server downtime). If I'd had an ERD, I probably could have had the server up in fewer than 10 minutes. After that experience, I was more diligent about creating and updating ERDs, but no matter how I tried to automate the process, it was still an administrative headache.
Fortunately, several software vendors have developed ERD utilities that simplify and automate the process of keeping emergency repair information for Windows 2000 and Windows NT workstations and servers up-to-date. I tested Aelita's ERDisk 5.0 and Raxco's RepairDisk Manager and compare them here. But an examination of ERD utilities should begin with a look at the ERD capabilities Microsoft provides with Windows.
Windows' ERD Solutions
You maintain an ERD so that you have a means of quickly restoring a PC to a bootable state if critical system files are damaged or deleted. An ERD isn't a substitute for regular backups.
During the installation of Win2K or NT, the Windows Setup process copies nine files that contain Emergency Repair information to the \%system root%\repair folder. Five of these files, which Setup saves in compressed format, represent the Win2K or NT Registry hives; two files initialize the default DOS environment; and one file contains the default user profile information. The last file, setup.log, is a log of all the Win2K or NT system files copied to the disk during installation and always has the read-only, system, and hidden attributes.
If you choose to create an ERD during a manual installation of NT 4.0, Setup compresses the nine files and saves them to a disk, which you should label and store in a safe place. If you create an ERD for Win2K, only the two DOS initialization files and setup.log are copied to a disk because the default Registry information for Win2K exceeds 1.44MB. In either OS, the Emergency Repair information that the installation stored in the \%systemroot%\repair folder remains there, whether you create an ERD or not. As long as the hard disk in which the \%systemroot%\repair folder resides is accessible, the files in the repair folder can usually (but not always) help you restore the system to base functionality if you launch Windows Setup and choose the Repair option.
Microsoft recommends that you update the Emergency Repair information and your ERD after making any significant hardware, software, or configuration changes to the system. In NT 4.0, you run the Repair disk utility to update the information. Type
rdisk
at the command line to launch the utility and display options for updating the information in the \%systemroot%repair folder as well as on your ERD. Type
rdisk /s
to also back up the SECURITY and SAM Registry hives to the repair folder and ERD. On a domain controller, the SAM and SECURITY hives are usually too large to include on the ERD, which is limited to one disk.
In Win2K, you use the Backup application to access the utility for creating an ERD. By default, this utility updates the DOS initialization files and the setup log, but as Figure 1 shows, the utility can also back up Registry hives. When you select the Registry-backup check box, the utility automatically saves the hives to the \%systemroot%\ repair\regback folder but not to your ERD. If your Registry is corrupted or erased, you can use the files in this folder to restore just your Registry and avoid a lengthier restoration of the Win2K System State data, which typically occupies a minimum of 200MB of storage. To restore System State data, you need to use the Win2K Recovery Console. (For more information, see Zubair Ahmad, "The Windows 2000 Recovery Console," http://www.win2000mag.com/, InstantDoc ID 7250. For more information about System State, see Zubair Ahmad, "Backing Up and Restoring the System State," http://www.win2000mag.com/, InstantDoc ID 7664.)
Most administrators are familiar with the NT 4.0 Emergency Repair process. You run NT Setup from the CD-ROM or startup disks and choose the Repair option. Then, you can select from options that let you restore individual Registry files, repair the startup files in the system partition, repair NT 4.0 system files, or repair the partition boot sector. The repair process will ask you for your ERD. After the repair is done, you must reapply the most current service pack to bring your system back into working order.
The Win2K Emergency Repair process is similar in that you run Win2K Setup from the CD-ROM or startup disks and choose the Repair option. You then can choose Fast Repair or Manual Repair. Fast Repair tries to repair system files (using the checksum method and setup.log), the boot sector on your system disk, and your startup environment. Fast Repair also checks the Registry files. If a Registry hive has a problem, Fast Repair automatically copies the hives backed up in the \%systemroot%\repair folder.
Manual Repair, an interactive subset of Fast Repair, doesn't check the Registry hives. It does let you perform one or all of the other three Fast Repair options above: verifying system files, inspecting the boot sector, and checking the startup environment.
Assessing Windows' Solutions
Using the Win2K and NT 4.0 ERD utilities Microsoft provides is straightforward but not without certain pitfalls. First, after you restore Registry hives, you can't reverse the process unless you've saved different versions of the ERD.
A second hitch in the Windows repair process is that you can't save Emergency Repair information across disks. You can save any amount of ERD data to the \%systemroot%\repair folder, but if you can't access the repair folder, you might need to reinstall the OS and restore the entire system from tape.
A third and significant problem is that Microsoft didn't design its ERD-creation utilities to be automated or centrally managed. You can use a combination of scripts, At commands, and Win2K's or NT 4.0's scheduling service to automate most tasks, but creating and administering the scripts and following through on their success or failure can be a nightmare in large environments. Finally, although the Win2K Task Scheduler has improved security features, many organizations that run NT 4.0 disable NT 4.0 Schedule Service as a standard security measure. In addition, some IT shops don't like the idea of storing their servers' security hives on relatively insecure disks.
All in all, using Win2K's and NT 4.0's ERD utilities is easy on a machine-by-machine basis. The Emergency Repair process has worked for me on many occasions, although it has failed me in at least as many situations. Win2K's additional recovery tools, such as the Recovery Console and the enhanced startup options, somewhat overshadow the features of the Backup and Repair processes, but the ERD still has a niche in providing quick recovery of a damaged system.
ERDisk 5.0
Aelita and Raxco offer products that attempt to address the limitations of Windows' ERD utilities. I tested the two vendors' products on a small network with a mixture of Win2K and NT 4.0 servers and workstations.
I began with Aelita's ERDisk 5.0. I installed it on a Dell Precision Workstation 410 with dual 500MHz processors, 128MB of RAM, and Win2K. ERDisk's wizard-based installation was quick and painless, requiring no reboot. I also installed ERDisk on an identical Dell workstation running NT Server 4.0 Service Pack 5 (SP5). ERDisk documentation is available in online HTML Help files.
ERDisk is a fairly simple product that consists of the core ERDisk product, the Agent, and the Emergency Repair Console. The core ERDisk product requires a Pentium machine with 64MB of RAM and enough disk space to accommodate Emergency Repair files. The core product's main function is to provide a graphical interface for configuring and scheduling ERD creation and storage. Several wizards built into the GUI facilitate these tasks.
The Agent is a temporary service that ERDisk installs on systems that it collects ERD files from. The Agent compresses the ERD files, then directs them to a designated repository on your network. When the Agent is finished, ERDisk deletes it from the local system. Localizing the processor-intensive ERD-file compression lets ERDisk perform multiple scheduled ERD-creation tasks in parallel.
The Emergency Repair Console is a command-line interface that you can boot from disks. You create the disks using the ERDisk GUI. The ERDisk Emergency Repair Console is similar in many ways to the Win2K Recovery Console. The main difference is that the ERDisk console provides access to all the folders and files on an NTFS disk, whereas the Win2K console allows access only to the \%systemroot% and \%windir% folders and their subfolders. In addition, unlike the Win2K console, the ERDisk console doesn't require logon credentials to access a hard disk. This easy access can be an advantage if damaged SAM and SECURITY hives make logging on impossible. At the same time, the ability to bypass NT security with bootable disks can make administrators nervous. You should store ERDisk bootable disks in a secure location. Like the Win2K Recovery Console, the ERDisk Emergency Repair Console offers a variety of familiar commands that you can use to manipulate files and folders on a drive as well as perform specific repair tasks.
The ERDisk GUI, which Figure 2 shows, resembles a Microsoft Management Console (MMC) snap-in. The left-hand pane shows Computer Collections (you can assign computers to a collection and perform a task for all the computers in the collection at one time), Network domains and workgroups, and Sessions (a list of ERD creations and their success or failure).
My first task was to manually create an ERD for one of the computers on my test network. I highlighted the computer in the right-hand pane and clicked Create ERD to launch the process. The window that appeared gave me the option of running the task immediately or scheduling it and let me select logging options, a location for saved files, whether to use the Agent for the process, and what Registry hives to save. I chose to create the ERD immediately and clicked OK. ERDisk provided a status window that gave me updates about the creation process. When the process finished, I checked the file storage location I had specified and found all the ERD data there. I also checked the system I backed up and saw that the ERD information in the \%systemroot%\repair folder had been updated as well. I found no trace of the Agent on the client system.
I tested this particular process several times, and the only potential difficulty I discovered is that manually initiated backups run under the user account you use to log on. As a domain administrator, I had no trouble creating ERDs for systems in the same domain, but on systems that didn't belong to the domain and had different administrator account credentials, ERDisk reported an Access Denied error message. I then looked up the error number in the Help file and logged on with an account that had adequate permissions in each domain.
Scheduling ERD jobs is similar to manually creating ERDs, but scheduled jobs run in a different account context, depending on whether you use NT 4.0's Schedule Service (atsvc.exe) or Win2K's Task Scheduler (mstask.exe). If you use the older Schedule Service, you must change its default logon as account credential from the Local System account to a domain account that has network access. If you use Schedule Service to run tasks on your ERDisk system, this requirement can be disruptive. Not using the Local System account means you can use Schedule Service to run only jobs that don't require a GUI.
You can upgrade to Task Scheduler to work around this problem. Under this newer service, each scheduled task uses the credentials you provide to run in its own security context. In testing ERDisk, I used both services on a Win2K system and an NT 4.0 system. As long as I provided the correct credential, all scheduled jobs launched on time and without errors.
Configuring ERD jobs is flexible and fairly straightforward. ERDisk lets you use your own naming conventions along with various environment variables to name a destination folder and path for ERD files and to set a file-retention policy. Figure 3 shows the Properties Operation tab (the job-configuration interface) with a specified folder name. In Figure 3, the folder name consists of the ERDisk software installation path followed by the computer name. But you can choose other expressions from the Operation tab's list. For example, you could schedule daily ERD backups for a computer and store each day's backup files in a folder identified by the computer name and the day of the week (i.e., a folder with a name in the format \%computername%\%AA%). This backup scheme would result in retention of six backups before one is overwritten. Or you could choose to save daily backups for a month before they are overwritten. The Operation tab also lets you choose the Registry hives to save.
Another option available when creating ERDs is to use the ERDisk Agent. The Agent compresses ERD files before sending them across the network, so you should use the Agent if you want to create ERDs for several systems at the same time and conserve network bandwidth. However, compressing the ERD files can briefly consume all the available CPU cycles on single-processor machines, so you should opt for an agentless process if you want to minimize the overall impact of ERD creation on the source system. You can't realistically run multiple concurrent agentless ERD tasks because they would consume too much network bandwidth and impose too great a processor load on the ERDisk system.
I tested both Agent and agentless ERDisk procedures. On a 300MHz Pentium II PC with 128MB of RAM, using the Agent to save a small (1.64MB) Registry required all available CPU cycles for 21 seconds. Without using the Agent, the same machine took 11 seconds to complete the ERD process. On a 166MHz Pentium system with a 6.43MB Registry, the ERD process took 2 minutes and 34 seconds with the Agent and 49 seconds without the Agent. I recorded 50 percent CPU utilization on the dual 500MHz processor workstation running ERDisk when it took on the job of file compression during the agentless ERD processes.
After I finished testing the ERD creation process, I moved on to ERDisk's recovery features. ERDisk employs the Repair Wizard to step you through several repair options. The wizard first lets you select the systems you want to repair. Then, you select the version of the ERD files you want to restore and the specific files from within that saved version. The wizard then recommends a method for restoring the files. If the system that needs repair is accessible on the network, ERDisk recommends remote repair (i.e., copying the selected files to the target system across the network). If the system isn't accessible from the network and the ERD files you want to restore will fit on one disk, ERDisk recommends using the Windows Emergency Repair procedure. If the ERD files together exceed 1.44MB, ERDisk recommends using Advanced Aelita ERD, which employs ERDisk's Emergency Repair Console. You can override any recommendation.
I tested each repair method that ERDisk provides. Doing remote repairs was easy, requiring only a couple of mouse clicks. Using the Windows Emergency Repair method was also easy. ERDisk created a standard Windows ERD from the ERD files I selected. I took the disk to the machine to be repaired and went through the Windows Emergency Repair process.
The Advanced Aelita ERD method was more involved because before I could begin, I had to create Aelita boot disks. A wizard stepped me through this task, which uses the standard Windows method for creating Windows Setup disks but adds proprietary modifications. The interesting thing about this method is that it lets you span multiple disks or even use a CD-Recordable (CD-R) disc to contain ERD files that are too large for one disk. After you load the files onto the disks or CD-R disc, you use the Aelita boot disks to boot the system you want to repair, then press any key to start the repair process. To go to a command prompt, press the Esc key. When I started the repair process, ERDisk prompted me to insert an Aelita repair disk, then proceeded without further prompts (except for prompts to insert additional disks). The repair process replaces only the Registry hives; it doesn't inspect system files or the partition boot sector.
Overall, I was satisfied with ERDisk's usability and functionality. You could be using this product within 15 minutes of installing it, although you would need to do some planning to determine backup schedules, retention periods, and storage needs for the ERD data. You would also need to decide whether you would use the ERDisk agent for ERD creation. But after you've made those choices, ERDisk would be fairly maintenance-free and could play a valuable part in your disaster-recovery plan.
| ERDisk 5.0 |
|
Contact: Aelita Software * 614-336-9223 or 800-263-0036 Web: http://www.aelita.net/ Price: Starts at $99 per server license or $10 per workstation license Decision Summary: Pros: Easy to use; flexible configuration options; optional agent lets you shift Emergency Repair Disk file compression to client or server; can save Emergency Repair Disk files across multiple disks or on a CD-Recordable disc Cons: Use of the Windows NT Schedule Service might interfere with existing schedules typically run under the Local System account |
RepairDisk Manager
I installed Raxco's RepairDisk Manager on the same hardware platforms I used to test Aelita's ERDisk. The installation wizard guided me through a quick and simple installation of RepairDisk Manager and didn't ask me to reboot. RepairDisk Manager provides documentation online in HTML Help files.
Three main components contain RepairDisk Manager's functionality: RDM Console, RDM Agent, and RDM Scheduler. RDM Console provides an administrative GUI for centrally configuring and launching ERD tasks. The minimum requirements for running RDM Console are a modest 16MB of RAM and Win2K or NT 4.0.
The RDM Agent is similar to ERDisk Agent in that it's a service that RepairDisk Manager installs on target systems to compress ERD files and direct them to a centralized storage area on the network. Unlike ERDisk, RepairDisk Manager lets you leave the agent installed on a system rather than delete it after ERD files are collected. Leaving the agent permanently installed eliminates the need to delete the agent files and service entries in the Registry at the end of each backup, thus slightly reducing the overhead on the client system.
RDM Scheduler, which runs on the RDM Console system, is the service that actually launches scheduled ERD jobs. Raxco claims that using RDM Scheduler rather than Schedule Service provides two advantages. First, you can continue to use Schedule Service in the context of the Local System account rather than a domain account with network privileges. If you use Schedule Service to launch jobs that require a GUI, this feature is important. Second, by not forcing you to use a domain account with network access for Schedule Service, RepairDisk Manager adds an extra layer of security against misuse of Schedule Service. Both of Raxco's arguments have some merit, but security-conscious administrators who like to disable Schedule Service will be disappointed to find out that they need Schedule Service to activate RDM Scheduler.
RepairDisk Manager also provides a recovery console similar in function to the Win2K Recovery Console and ERDisk Emergency Repair Console. The main difference is that RDM Recovery Console provides only a command-line interface for full access to an NTFS drive, whereas the other two consoles provide additional features.
Like the ERDisk main console, RDM Console resembles an MMC snap-in. As Figure 4 shows, the left-hand pane lists domains, workgroups, and schedules, and the right-hand pane lists details about group members. RDM Console has all the functionality of ERDisk's GUI, but it is a little slow, taking too much time to perform tasks such as refreshing the screen, enumerating domain members, and displaying property sheets. This sluggishness became more annoying the longer I worked with the console.
Following the same procedure I used with ERDisk, I began testing RepairDisk Manager by manually launching an ERD creation task for a system on my test network. I simply selected the computer I wanted to back up and clicked the Run RDM button on the RDM Console toolbar. After I launched the task, a status window showed the progress of the operation, which was completed without any errors.
I was surprised I didn't have to configure any options on my first run, so I checked to see what settings I could manipulate. I found that if you right-click any selected computer or group of computers, you can specify a destination path and retention policy for the ERD files. Within the destination folder you specify, RepairDisk Manager creates another folder for each backup. The RepairDisk Manager-generated folder name includes the system name and the date and time when the backup was finished. Compared with ERDisk, RepairDisk Manager's retention options are limited: You can save all ERD sessions or any number of sessions from 2 to 10.
RepairDisk Manager doesn't provide an option for agentless operation. When I timed RepairDisk Manager's agent-based ERD creation and measured CPU utilization, the results were almost identical to ERDisk's agent-based operation. To summarize my performance findings for both ERDisk and RepairDisk Manager, you can expect a spike in CPU utilization on any system (workstation or server) while ERDisk or RepairDisk Manager is compressing ERD files before sending them to their destination. This spike is relatively brief (30 to 75 seconds on member servers and longer for domain controllers) but might be noticeable on heavily used mission-critical servers.
One feature specific to RepairDisk Manager is the option to retain the original SAM and SECURITY hives. The original hives are small because they contain only basic information such as the local administrator account password. If you retain the original hives and you need to perform a repair on a system, you might be able to fit all the ERD files on one disk. Although this is a valid approach, it doesn't compare favorably to ERDisk's ability to save across disks and exploit CD-R discs.
To test RepairDisk Manager's ERD scheduling, I clicked the Schedule button on the RepairDisk Manager toolbar. I provided an account that could access all the computers on the network and gave that account the rights to log on as a service and to back up and restore files and directories. After that, setting a schedule was a simple task of selecting network computers from a list and selecting scheduling options from the dialog box, as Figure 5 shows. I used all the computers in my test network to set up several test schedules. I didn't run into any problems except that a PC in another domain didn't recognize the account credentials I provided for the RDM Scheduler service. Otherwise, all scheduled jobs completed normally.
To begin testing the recovery process for RepairDisk Manager, I clicked the Apply ERD toolbar button. This button launched a wizard that gave me the option of creating an ERD from the previously saved ERD files or applying Registry hives to the remote machine. I could select a PC to repair and the version of ERD files I wanted to restore. I could create a standard Windows ERD or apply the files remotely across the network. When I chose a remote restore, the wizard let me launch the process regardless of the target machine's availability. For machines that were up on the network, the remote restore worked flawlessly. If a target machine wasn't available, I had to restart the wizard and create a standard Windows ERD. For machines requiring an ERD, RepairDisk Manager dutifully created disks that I then successfully used with the Windows Emergency Repair process.
Finally, I tested RDM Recovery Console. RepairDisk Manager provides a wizard for creating the RDM Recovery Console boot disks. The process was identical to ERDisk's and successfully generated the boot disks. I created one set of disks for Win2K and another set for NT and tested each. RDM Recovery Console provides a simple command-line interface for accessing NTFS disks. Commands let you perform tasks such as copying and deleting files and creating directories. These features compare favorably with those of ERDisk's Emergency Repair Console, but ERDisk also has an automatic repair option that supports ERD files on multiple disks and CD-R discs.
ERDisk Has the Edge
Both Aelita's ERDisk and Raxco's RepairDisk Manager are easy to use, perform well, and provide the services they advertise. But ERDisk provides extra functions and configuration options that busy administrators will appreciate. In addition, Aelita's aggressive pricing makes deploying ERDisk much easier on your budget.
A comprehensive disaster-recovery plan is imperative for all organizations, regardless of size. Having ERDs on hand is an integral part of that plan. If you don't have time to maintain ERDs, ERDisk can help—and it's definitely worth the modest cost.
| RepairDisk Manager |
|
Contact: Raxco Software * 301-527-0803 or 800-546-9728 Web: http://www.raxco.com/ Price: $149 for a 5-pack Workstation version, $299 for a 2-pack Server version Decision Summary: Pros: Easy to use; employs own scheduler service Cons: Sluggish GUI; can't save large Emergency Repair Disk files across disks or on CD-ROM |
