Microsoft

Step-By-Step: Automate your Emergency Repair Disk

Use these recommendations to automatically create a Windows NT Emergency Repair Disk

erd,rdisk,microsoft,backup,registry,
You can never have enough insurance—especially when you’re a Windows NT administrator. But you don’t have to pay an arm and a leg for coverage. Just set up an automatic emergency repair disk (ERD).

What exactly do I need a repair disk for, anyway?
Windows NT stores a number of important settings on your repair disk. A typical repair disk contains a copy of your registry. Optionally, it can also hold a backup copy of user accounts.

When a Windows NT system becomes unbootable, sometimes the last resort is to try to repair the existing installation. If you run through the setup process on a computer system that already has Windows NT installed, Microsoft provides a mechanism for attempting a repair. Some critical areas, such as system settings, installed software settings, user profiles, security policy, and the account database, can all be located on your repair disk.
The default repair disk will contain only information relating to the Administrator account. All other account information is not saved on a normal ERD.
How do I make an emergency repair disk?
The traditional method for ensuring you have a repair disk is to log onto your Windows NT system and run RDISK from a command prompt. The first step is always to Update Repair Info, followed by writing the information to a floppy disk. While the Create Repair Disk option is available, it does not update your disk with new copies of your system settings—it will just make a copy of the last repair disk created.



But what do you do when you have more than one computer, or dozens? RDISK has a few hidden “features” that are not found in any supplied documentation. It can be run without user intervention and made to automatically skip the floppy disk creation in favor of a network location.

Try the following: Open up a command prompt and then run the following command:
RDISK /S-

You’ll see the following pop up:



No prompts, no interaction… and no floppy?

The S switch instructs RDISK to include a full copy of the SAM database, the file that holds all information relating to user accounts on your Windows NT machine. Remember that by default, RDISK backs up only the local Administrator account and password!
On domain controllers with a large number of accounts, this file can get large.
The “-“ option further instructs RDISK to skip writing the ERD files to a floppy disk. Instead, all files created reside in %SystemRoot%\repair.

Of course, now you need to make sure those files are available when you need them. What is the obvious solution? Copy them to another computer!

Why would I want to do this?
How difficult is it to maintain accurate information on your ERD? Changes to a Windows NT system’s registry occur all the time. In larger organizations, accounts are added daily, and maintaining accurate ERD information for multiple systems becomes an unmanageable nightmare. As a result, many just opt to make the occasional repair disk when time permits.

But with a little creative batch file programming, you can automate the process entirely. After local creation of the necessary repair disk files, you can copy those files to a centralized server. Tape backup kicks in after the copy process, and bingo: You have a tape backup of your repair disks—for all of your computers.

How? The technical details
Three steps are required to implement this approach:
  • Set up a network location and associated share name for storage of the ERD information
  • Create the script to update and upload the ERD files
  • Set a schedule for these updates to occur

Step 1: Setting up the share
Pick a centralized location for your repair information. Generally, the Primary Domain Controller is a good choice. Set a location and a share name. For our example, we’ll use PDC as the computer name and RDISKS$ as the share name. (Since we're creating this share name for a specific purpose, I’ve chosen to hide it from browse lists by ending the name with “$”.)

The share will be accessed by Windows NT’s built-in schedule service, described in step three. Depending on which option you select, there will be an additional configuration change on your network share.

Step 2: Writing the script
Writing the script is probably the easiest portion of the process. Place the following batch file in the directory you created in step one, and name it MAKEERD.CMD:
rdisk /S-
xcopy /I %SystemRoot%\Repair\*.* \\PDC\RDISKS$\%COMPUTERNAME%

Note that you must substitute your own share names for PDC and RDISKS$.

The batch file performs two tasks. First, it creates the ERD and keeps those files local. Second, it creates a new directory name in your RDISKS$ share location by using the computer’s name as the directory name and copies the ERD files to that new directory. Since each computer must have its own directory, due to the requirement that ERD files possess the same name, this method allows for dynamic directory names to be automatically created based on the computer running the script.

Step 3: Automating the process
The easiest way to automate the process is to use Windows NT’s built-in schedule service, which allows you to schedule daily, weekly, or monthly events. The process itself must create the ERD information locally and then copy it to a remote location.

There is one slight caveat in using the schedule service across a network: Unless the schedule service is changed in the control panel, it runs under the Windows NT system account, which has little-to-no network access. There are two solutions, each of which I will briefly explain:
  • Enable the schedule service to run under a specific user account, generally an administrative account
  • Enable the remote shared location to be connected as a Null System Share (required modification to the registry)

The first option is easiest to implement. Giving the schedule service administrative access allows maximum flexibility on capabilities but involves some risk, since the service now has access to multiple computers across a network. Using the Services control panel, modify the Schedule Service to log on as a specific user. If this is going to be the standard procedure across multiple systems, it might be best to implement a separate user account to be used only for the schedule service. If the schedule service is already running, you must stop and restart the service for the change to take effect.

The second option is most secure but requires a change to the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\NullSessionShares

There may be several entries already there, such as COMCFG and DFS$. Add the name of your newly created share, RDISKS$ in my example. This will allow non-user accounts access to the share.

In both cases, the schedule service must be set to Automatic startup in the Services control panel. Windows NT defaults to manual startup.

To add the scheduled repair disk information, you can run the AT command from a command prompt. Again, using my example names above, I have my own workstation set to update every night, Monday through Friday at 3:00 A.M.:
at 3:00 /every:m,t,w,th,f \\pdc\rdisks$\makeerd.cmd

You'll find more details on the AT command in the Windows NT online help.
The Windows NT Resource Kit includes a graphical interface to the AT command called WinAT.
Some notes on directory security
Setting up the minimum permissions while still allowing the program to function properly presents an interesting challenge. If you opt to use the schedule service under a system account, you can modify the directory and file permissions (NTFS only) to allow full write access but prevent anyone from reading the files.

On your RDISKS directory, set up the directory permissions for the “Everyone” group to be Read, Write, and Execute (RWX). Also change file permissions to be Write and Execute (WX). Don’t forget to add your local Administrators group with Full Control!

After you’ve made those changes, you have to change the permissions on MAKEERD.CMD such that it is readable. On that one file, change permissions for the Everyone group to Read.





Remember to leave the share-level access to Full Control. Use NTFS security to fine-tune the access permissions.

ERD: Your “cheap” insurance policy
Having a repair disk available will not save you from a failed hard drive, but it will let you keep a most recent copy of your entire registry—something that can get the system back up and running in the event of a serious problem. Combined with Microsoft’s system repair option during the Windows NT setup program, you might just be able to get that system back up again in record time. Best of all, it’s free!
  • Microsoft Help on RDISK

  • “The repair information on your hard disk or your Emergency Repair Disk can be used to reconstruct your Windows NT system files, system configuration, and startup environment variables if they become damaged. The Repair Disk utility should not be used as a backup tool.”
  • Q122857 RDISK /S and RDISK /S- Options in Windows NT
  • If you'd like to share your opinion, please post a comment below.

    Editor's Picks

    Free Newsletters, In your Inbox