During a failure or after a disaster, many organizations figure out that their disaster recovery plans could have been better—a lot better. Organizations not only should plan for different types of failures and disasters, but they also should periodically simulate a failure to ensure that the plans are correct, up-to-date, and complete. If the appropriate level of disaster planning has been performed, as outlined in Chapter 32, “Backing Up a Windows Server 2003 Environment,” organizations can recover from Windows Server 2003 failures. This chapter offers the recommended and practical approach to recovery.
This chapter is intended as a follow-up to Chapter 32, which describes backing up in the Windows Server 2003 environment. However, if you’re reading this chapter to recover from a failure, skip this section and move on to “Isolating Failures” later in this chapter.
After backup strategies are developed for Windows Server 2003 systems, the backup/restore procedures need to be tested to ensure that the documentation is up to date and accurate. Many organizations outsource document creation to consulting firms that create the plan based on their experience with the product and their limited exposure to the organization’s environment. This is why just having the plan often is not good enough. Also, when configurations change, someone should have an electronic, writable copy available and understand how to update the document. For detailed information on Windows Server 2003 documentation, refer to Chapter 24, “Documenting a Windows Server 2003 Environment.”
One important aspect of recovery feasibility is knowing how to recover from a disaster. Just knowing what to back up and what scenarios to plan for is not enough. Restore processes should be created and tested to ensure that a restore can meet service-level agreements (SLAs) and that the staff members understand all the necessary steps.
When a process is figured out, it should be documented, and the documentation should be written to make sense to the desired audience. For example, if a failure occurs in a satellite office that has only marketing employees and one of them is forced to recover a server, the documentation needs to be written so that it can be understood by just about anyone. If the IT staff will be performing the restore, the documentation can be less detailed, but assume a certain level of knowledge and expertise with the server product. The first paragraph of any document related to backup and recovery should be a summary of what the document is used for and the level of skill necessary to perform the task and understand the document.
One of the key elements to having a successful disaster recovery plan is to periodically test the restore procedures to verify accuracy and to test the backup media to ensure that data can actually be recovered. Most organizations or administrators assume that, if the backup software reports “Successful,” the backup is good and data can be recovered. If a special backup consideration is not taken care of, but the files are backed up, the successful backup may not contain everything necessary to restore a server if data loss or software corruption occurs.
Restores of not only file data, but also application data and configurations should be performed as part of a regular maintenance schedule to ensure that the backup method is correct and disaster recovery procedures and documentation are current. Such tests also should verify that the backup media can be read from and used to restore data. Adding periodic test restores to regular maintenance intervals ensures that backups are successful and familiarizes the administrators with the procedures necessary to recover so that when a real disaster occurs, the recovery can be performed correctly and efficiently the first time.
When monitoring software or users report failures or send alerts, the administrator should start troubleshooting by validating that the failure really exists. To do this, the administrator needs a test workstation and test user account and also needs to understand how the particular application or service works.
To test a reported problem, the administrator should use a test workstation. This workstation should be configured to match an end user’s workstation so that tests yield the same results the end user received. User applications should be installed on this workstation with the same settings and permissions. An alternative to having a test workstation is to use remote control software such as Remote Assistance to connect directly to the user’s workstation and witness the reported issue firsthand.
A test user account should be configured and used when troubleshooting user-reported failures or functionality issues. The test account should have the same level of privileges as the end user; otherwise, testing may yield different results.
The actual process for re-creating the failure should be known before the administrator tries to validate the failure. Usually, it’s good to start with the end user who reported the problem. If the error, failure, or issue was reported by monitoring software, the server should be checked to see whether the system appears to be functional and the services or applications are running. If the system, services, and/or applications are still running, connectivity then needs to be tested. If the application is network based, as most are, network connectivity to the server should be tested first, followed by testing the application itself using the appropriate client software.
To isolate failures associated with applications and services, the administrator needs to understand and be aware of any service dependencies. For example, if a report indicates that Internet email has not been received, the problem could be the mail server, or it could be a dependency such as the firewall or DNS server for the email domain. If the Internet DNS server for the email domain is down or offline, the failure is not the mail server but merely the Internet DNS server, because other organizations are dependent on first locating the host record for mail from that DNS server before mail can be delivered.
To determine the network dependencies of a particular network application, refer to the manufacturer’s documentation. If it is a Windows Server 2003 application, refer to Windows Server 2003 Help and Support for detailed information. If a server application runs as a Windows Server 2003 service, using the Services applet from the Administrative Tools menu, you can learn a service’s dependencies on other services or system drivers, as shown in Figure 33.1 for the Windows Server 2003 DNS Server service.
When a site becomes unavailable because of a physical access limitation or a disaster such as a fire or earthquake, steps must be taken to provide any mission-critical applications or business services from a separate location.
Redundant sites are created for a few reasons: First, they can be created for load balancing or providing higher performance to clients accessing the resources from different geographic locations. For example, an organization may have one site in San Francisco, California, and another in Tampa, Florida, both on different coasts of the United States. East coast clients would connect to Florida, and West coast clients would connect to California. Each site would be a mirror of the other, so the data and services provided at each location would be the same.
Another reason for redundant sites is to provide if not all the computer-based services and applications available at the main site, at least all the mission-critical resources. This way, a company can continue to function, perhaps in a limited capacity, but at least it would be able to perform most important business functions.
For more information on deciding what services and applications are most important to a business and whether they should be provided in a failover site, refer to the section “Prioritizing the Environment” in Chapter 32.
Because every organization has different requirements when it comes to designing a failover site and what it takes to fail over and eventually fail back, this section covers the basic necessities for failing over between redundant sites to be successful.
Companyabc.com is a fictitious marketing/graphic design firm headquartered in New York, New York. The company has a secondary failover location in Boston, Massachusetts. The New York site provides virtual private network (VPN) and Terminal Services for the Marketing department employees who rarely make it into the office. Because marketing is the core of Companyabc.com’s business, the VPN and Terminal Services are key to business continuity. For example, as the graphic artists develop new material for the Marketing department, the Marketing department sales force and client teams use the VPN to get the data to the client for approval. Also, the New York location houses the accounting server, which is used by employees to enter daily time sheets, which in turn are used to generate invoices to bill the clients. If the New York site becomes unavailable, VPN, Terminal Services, file servers containing client documentation, and the accounting servers must all be restored at the Boston site within a few hours of a site disaster for business continuity. In this scenario, restoring is a relatively simple task; most organizations are much more complicated than this.
When an organization decides to plan for site failures as part of a disaster recovery solution, there are many areas that need to be addressed and there can be many options to choose from. Using the Companyabc.com scenario, the biggest factors are file data and remote network connectivity through VPN and Terminal Services. This means that network connectivity is a priority, along with spare servers that can accommodate the user load. The spare servers for file data and accounting need to have enough disk space to accommodate a complete restore. As a best practice to ensure a smooth transition, the following list of recommendations provides a starting point:
Allocate the appropriate hardware devices including servers with enough processing power and disk space to accommodate the restored machines’ resources.
Host the organization’s DNS zones and records using primary DNS servers located either at an Internet service provider (ISP) co-location facility or have redundant DNS servers registered for the domain and located at both the physical locations.
Ensure that DNS record-changing procedures are documented and available at the remote site or at an offsite data storage location.
For the VPN and Terminal servers, ensure that the host records in the DNS tables are set to low Time to Live (TTL) values so that DNS changes do not take extended periods to propagate across the Internet. Microsoft Windows Server 2003 default TTL time is one hour.
Ensure that network connectivity is already established and stable between sites and between each site and the Internet.
Replicate file data between the two sites as often as possible.
Create at least two copies of backup media (tapes) that contain backed-up or archived company data. One copy should remain at the headquarters. A second copy should be stored with an offsite data storage company. An optional third copy could be stored at another site location; that copy can be used to restore the file to spare hardware on a regular basis to restore Windows if a site failover is necessary.
Have a copy of all disaster recovery documentation stored at multiple locations as well as at the offsite data storage company. This will provide redundancy should a recovery become necessary.
Allocating hardware and making the site ready to act as a failover site are simple tasks in concept, but the actual failover and fail-back process can be troublesome. Keep in mind that the preceding list applies to failover sites, and not mirrored or redundant sites configured to provide load balancing.
Before failing over between sites can be successful, administrators need to be aware of what services need to fail over and in which order of precedence. For example, before an Exchange Server 2003 server can be restored, Active Directory domain controllers, global catalog servers, and DNS servers must be available.
As a site failure example, at Companyabc.com’s headquarters in New York, a fire in the building leaves the server room soaked in fire retardant chemicals and the servers damaged. Failing services over to the Boston location would be necessary in this case.
To keep such a cutover at a high level, the following tasks need to be executed in a timely manner:
Update Internet DNS records pointing to the VPN and Terminal servers.
Restore any necessary Windows Server 2003 domain controllers, global catalog servers, and internal DNS servers as necessary.
Restore VPN and Terminal servers.
Restore the file and accounting servers and restore the latest available backup tape when restoring data.
Test client connectivity, troubleshoot, and provide remote and local client support as needed.
When the initial site is back online and available to handle client requests and provide access to data and networking services and applications, it is time to consider failing back the services. This can be a controversial subject because fail-back procedures are normally more difficult than the initial failover procedure, but usually only when database servers are involved. Most organizations plan on the failover and have a tested failover plan that may include database log shipping to the disaster recovery site. However, they do not plan how they can get the current data back to the restored servers in the main or preferred site.
Questions to consider for failing back are as follows:
Will downtime be necessary to resynchronize data or databases between the sites?
When is the appropriate time to fail back?
Is the failover site less functional than the preferred site? In other words, are only mission-critical services provided in the failover site or is it a complete copy of the preferred site?
The answers really lie in the complexity of the failed-over environment. If the cutover is simple, there is no reason to wait to fail back.
When failover sites are too expensive and not an option, that does not mean that an organization cannot plan for site failures. Other lower-cost options are available but depend on how and where the employees do their work. For example, remote salespeople in Companyabc.com most likely have laptops with all the necessary applications they need installed locally. On the other hand, the accounting employees probably do not have laptops, and even if they did, they would need to access the accounting server to query the updated time entries and generate customer invoices.
The following are some ways to deal with these issues without renting or buying a separate failover site:
Consider renting racks or cages at a local ISP to co-locate servers that can be accessed during a site failure.
Have users dial in from home to a Terminal server hosted at an ISP to access applications and file data, including the accounting server data.
Configure important folders for remote users with laptops so that they can have offline copies stored on their laptops that will synchronize with the server when the connection becomes available.
Rent temporary office space, printers, networking equipment, and user workstations with common standard software packages such as Microsoft Office and Internet Explorer. You can plan for and execute this option in about one day. If this is an option, be sure to find a computer rental agency first and get pricing before a failure occurs and you have no choice but to pay the rental rates.
While organizations create disaster recovery plans and procedures to protect against a variety of system failures, disk failures tend to be the most common in networking environments. The technology used to create processor chips and memory chips has improved drastically over the past couple of decades, minimizing the failure of system-boards. And although the quality of hard drives has also drastically improved over the years, because hard drives are constantly spinning, they have the most moving parts in a computer system and tend to be the items that fail most often.
Common uses of hardware-based disk arrays for Windows servers include RAID 1 (mirroring) for the operating system and RAID 5 (striped sets with parity) for separate data volumes. Some deployments use a single RAID 5 array for the OS, and data volumes for RAID 0/1 (mirrored striped sets) have been used in more recent deployments.
RAID controllers provide a firmware-based array management interface, which can be accessed during system startup. This interface enables administrators to configure RAID controller options and manage disk arrays. This interface should be used to repair or reconfigure disk arrays if a problem or disk failure should occur.
Many controllers offer Windows-based applications that can be used to manage and create arrays. Of course, this requires that the operating system can be started to access the Windows-based RAID controller application. Follow manufacturer’s procedures on replacing a failed disk within hardware-based RAID arrays.
Note
Many RAID controllers allow an array to be configured with a hot spare disk. This disk automatically joins the array when a single disk failure occurs. If several arrays are created on a single RAID controller card, hot spare disks can be defined as global and can be used to replace a failed disk on any array. As a best practice, hot spare disks should be defined for arrays.
If a system disk failure is encountered, the system can be left in a completely failed state. To prevent this problem from occurring, the administrator should always try to create the system disk on a fault-tolerant disk array such as RAID 1 or RAID 5. If the system disk was mirrored (RAID 1) in a hardware-based array, the operating system will operate and boot normally because the disk and partition referenced in the boot.ini file will remain the same and will be accessible. If the RAID 1 array was created within the operating system using Disk Manager or diskpart.exe, the mirrored disk can be accessed upon bootup by choosing the second option in the boot.ini file during startup. If a disk failure occurs on a software-based RAID 1 array during regular operation, no system disruption should be encountered.
If Windows Server 2003 has been installed on the second or third partition of a disk drive, a separate boot and system partition will be created. Most manufacturers require that for a system to boot up from a volume other than the primary partition, the partition must be marked active prior to functioning. To satisfy this requirement without having to change the active partition, Windows Server 2003 always tries to load the boot files on the first or active partition during installation regardless of which partition or disk the system files will be loaded on. When this drive or volume fails, if the system volume is still intact, a boot disk can be used to boot into the OS and make the necessary modification after changing the drive. Refer to “Creating a Windows Server 2003 Boot Floppy” in Chapter 32 for details on how to create a boot disk.
A data volume is by far the simplest of all types of disks to recover. If an entire disk fails, simply replacing the disk, assigning the previously configured drive letter, and restoring the entire drive from backup will restore the data and permissions.
A few issues to watch out for include the following:
Setting the correct permissions on the root of the drive
Ensuring that file shares still work as desired
Validating that data in the drive does not require a special restore procedure
Occasionally, a Windows Server 2003 system can suffer a service or application startup problem that could leave a server unable to complete a normal bootup sequence. Because the operating system cannot be accessed in this case, the system would remain unavailable until this problem can be resolved.
Windows Server 2003 includes a few alternative bootup options to help administrators restore a server to a working state. Several advanced bootup options can be accessed by pressing the F8 key when the boot loader screen is displayed. If the Recovery Console was previously installed, it is listed as an option in the boot loader screen. The Advanced boot options include:
Safe Mode—. This mode starts the operating system with only the most basic services and hardware drivers and disables networking. This allows administrators to access the operating system in a less functional state to make configuration changes to service startup options, some application configurations, and the System Registry.
Safe Mode with Networking—. This option is the same as Safe Mode, but networking drivers are enabled during operation. This mode also starts many more operating system services upon startup.
Safe Mode with Command Prompt—. This option is similar to the Safe Mode option; however, the Windows Explorer shell is not started by default.
Enable Boot Logging—. This option boots the system normally, but all the services and drivers loaded at startup are recorded in a file named ntbtlog.txt located in the %systemroot% directory. The default location for this file is c:Windows tbtlog.txt. To simplify reading this file, the administrator needs to delete the existing file before a bootup sequence is logged so that only the information from the last bootup is logged.
Enable VGA Mode—. This mode loads the current display driver, but it displays the desktop at the lowest resolution. This mode is handy if a server is plugged in to a different monitor that cannot support the current resolution.
Last Known Good Configuration—. This mode starts the operating system using Registry and driver information saved during the last successful logon.
Directory Services Restore Mode—. This mode is only for domain controllers and allows for maintenance and restore of the Active Directory database or the SYSVOL folder.
Debugging Mode—. This mode sends operating system debugging information to other servers through a serial connection. This requires a server on the receiving end with a logging server that is prepared to accept this data. Most likely, standard administrators will never use this mode.
Start Windows Normally—. As the name states, this mode loads the operating system as it would normally run.
Reboot—. This option reboots the server.
Return to OS Choices Menu—. This option returns the screen back to the boot loader page so the correct operating system can be chosen and started.
The Recovery Console provides an option for administrators to boot up a system using alternate configuration files to perform troubleshooting tasks. Using the Recovery Console, the bootup sequence can be changed, alternate boot options can be specified, volumes can be created or extended, and service startup options can be changed. The Recovery Console has only a limited number of commands that can be used, making it a simple console to learn. If Normal or Safe mode bootup options are not working, the administrator can use the Recovery Console to make system changes or read the information stored in the boot logging file using the type command. The boot logging file is located at C:Windows
tbtlog.txt by default and exists only if someone tried to start the operating system using any of the Safe mode options or the boot logging option.
Because hardware does occasionally fail, and in the real world operating systems do have problems, a server recovery plan is essential, even though it may never be used. The last thing any administrator wants is a server failure to occur and to end up on the phone with Microsoft Technical support telling him to restore the server from backup when he does not have a plan ready. To keep from being caught unprepared, the administrator should have a recovery plan for every possible failure associated with Windows Server 2003 systems.
When a complete system failure occurs, whether it is because of a site outage, a hardware component failure, or a software corruption problem, the method of recovery depends on the major goal the administrator is trying to accomplish. The goal is to get the server up and running, of course, but behind the scenes many more questions should be answered before the restore is started:
How long will it take to restore the server from a full backup?
If the server failed because of software corruption, will restoring the server from backup also restore the corruption that actually caused the failure?
Will reloading the operating system and applications manually followed by restoring the system state be faster than a full restore?
Loading the Windows Server 2003 operating system and applications can be a relatively efficient operation. This ensures that all the correct files and drivers are loaded correctly, and all that needs to follow is a system state restore to recover the server configuration and restore the data. One of the problems that can occur is that, upon installation, some applications generate Registry keys based on the system’s computer name, which can change if a system state restore is performed. Other applications—for example, Exchange Server 2003—can be restored using a /disasterrecovery installation switch and do not need the server’s system state restore, just the original computer name and domain membership, as long as computer and user certificates are not being used.
The key to choosing whether to rebuild or restore from backup is understanding the dependencies of the applications and services to the operating system and having confidence in the server’s stability at the time of the previous backups. The worst situation is attempting a restore from backup that takes several hours, only to find that the problem has been restored as well.
When a complete server system failure is encountered and the state of the operating system or an application is in question, the operating system can be recovered manually. Locating the system’s original configuration settings is the first step. This information is normally stored in a server configuration document or wherever server configuration information is kept.
Because each system is different, as a general guideline for restoring a system manually, perform the following steps:
Install a new operating system on the original system hardware and disk volume, or as close to the original configuration as possible. Be sure to install the same operating system version—for example, Windows Server 2003 Enterprise or Standard Server.
During installation, name the system using the name of the original server but do not join a domain.
Do not install any additional services during installation and proceed by performing a basic installation.
After the operating system completes installation, install any additional hardware drivers as necessary and update the operating system to the latest service pack and security patches. To reduce compatibility problems, install the service packs and updates as outlined in the server configuration document to ensure that any installed applications will function as desired. During a restore is not the time to roll out additional system changes. The goal is to get the system back online, not to upgrade it.
Using the Disk Management console, create and format disk volumes and assign the correct drive letters as recorded in the server build document.
If the server was originally part of a domain, you must first reset the computer account using the AD users and computers console and join the domain afterwards. This will ensure that permissions and group membership previously granted to this computer remain intact.
Install any additional Windows Server 2003 services as defined in the server build document.
Install any Microsoft server applications following any special recovery processes and restore application data immediately following the application restore.
Install any third-party applications and restore configurations and data as necessary.
Test functionality, add this system to the backup schedule, and start a full backup.
When an operating system fails and cannot be started, a restore of the entire server may be necessary. If system volumes and data volumes exist on the same disk, performing an Automated System Recovery (ASR) restore will wipe out the entire disk, and both the system and data will need to be restored. In many cases, an ASR restore is not necessary; recovering only the system volume and system state is necessary.
After this process is complete, restores of the applications and application data should proceed. To recover a system using a clean installation and a previously backed-up system state, follow these steps:
Shut down the original server.
Install a new operating system on the original system hardware and disk volume, or as close to the original configuration as possible. Be sure to install the same operating system version—for example, Windows Server 2003 Enterprise or Standard Server.
During installation, name the system using the name of the original server but do not join a domain.
Do not install any additional services during installation and proceed by performing a basic installation.
After the operating system completes installation, install any additional hardware drivers as necessary and update the operating system to the latest service pack and security patches. To reduce compatibility problems, install the service packs and updates as outlined in the server build document to ensure that any installed applications will function as desired.
Using the Disk Management console, create and format disk volumes and assign the correct drive letters as recorded in the server build document.
After the installation, restore any necessary drivers or updates to match the original configuration. This information should be gathered from a server configuration document (server build document). Then reboot as necessary.
After all the updates are installed, restore the previously backed-up system state data; afterward, restore any additional application or user data.
This section outlines how to restore the system state to a member or stand-alone Windows Server 2003 system. To restore the system state, perform the following steps:
Click Start, All Programs, Accessories, System Tools, Backup.
If this is the first time you’ve run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink.
Click the Restore Wizard (Advanced) button to start the Restore Wizard.
Click Next on the Restore Wizard Welcome screen to continue.
On the What to Restore page, select the appropriate cataloged backup media, expand the catalog selection, and check System State. Click Next to continue.
If the correct tape or file backup media does not appear in this window, cancel the restore process. Then, from the Restore Wizard, locate and catalog the appropriate media and return to the restore process from step 1.
On the Completing the Restore Wizard page, click Finish to start the restore.
When the restore is complete, review the backup log for detailed information and click Close on the Restore Progress window when finished.
Reboot the system as prompted.
When the system restarts, log in using an account with Local and/or Domain Administrator rights as necessary.
After the system state is restored, install any additional applications and data if necessary.
When a system has failed and all other recovery options have been exhausted, an ASR restore can be performed, provided that an ASR backup has been previously performed. The ASR restore will restore all disk and volume configurations, including redefining volumes and formatting them. This means that the data stored on all volumes needs to be restored after the ASR restore is complete. This restore brings a failed system back to complete server operation, except for certain applications that may require special configurations after the restore. For example, the Remote Storage service data needs to be restored separately.
Note
An ASR restore re-creates all disk volumes, but if a new or alternate system is being used, each disk must be of equal or greater size to the disks on the original server. Otherwise, the ASR restore will fail.
To perform an ASR restore, follow these steps:
Locate the ASR floppy created for the failed node or create the floppy from the files saved in the ASR backup media. For information on creating the ASR floppy from the ASR backup media, refer to Help and Support from any Windows Server 2003 Help and Support tool.
Insert the Windows Server 2003 operating system media in the CD-ROM drive of the server you are restoring to and start the installation from this CD.
When prompted, press F6 to install any third-party storage device drivers if necessary. This includes any third-party disks or tape controllers that Windows Server 2003 will not natively recognize.
Press F2 when prompted to perform an Automated System Recovery.
Insert the ASR floppy disk into the floppy drive and press Enter when prompted. If the system does not have a local floppy drive, one must temporarily be added; otherwise, an ASR restore cannot be performed.
The operating system installation proceeds by restoring disk volume information and reformatting the volumes associated with the operating system. When this process is complete, the operating system will restart after a short countdown, the graphic-based OS installation will begin, and the ASR backup will attempt to reconnect to the backup media automatically. If the backup media is on a network drive, the ASR backup reconnection will fail. If it fails, specify the network location of the backup media using a UNC path and enter authentication information if prompted.
When the media is located, open the media and click Next and then Finish to begin recovering the remaining ASR data.
When the ASR restore is complete, if any local disk data was not restored with the ASR restore, restore all local disks.
Click Start, All Programs, Accessories, System Tools, Backup.
If this is the first time you’ve run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink.
Click the Restore Wizard (Advanced) button to start the Restore Wizard.
Click Next on the Restore Wizard Welcome screen to continue.
On the What to Restore page, select the appropriate cataloged backup media, expand the catalog selection, and check desired data on each local drive. Click Next to continue.
On the Completing the Restore Wizard page, click Finish to start the restore. Because you want to restore only what ASR did not, you do not need to make any advanced restore configuration changes.
When the restore is complete, reboot the server if prompted.
After the reboot is complete, log on to the restored server and check server configuration and functionality.
If everything is working properly, perform a full backup and log off the server.
When a Windows Server 2003 system is recovered using an ASR restore, the boot.ini file may not be restored. This file contains the options for booting into different operating systems on multiboot systems and booting into the Recovery Console if it was previously installed. To restore this file, simply restore it from backup to an alternate folder or drive. Delete the boot.ini file from the C: root folder and move the restored file from the alternate location to C: or whichever drive the boot.ini file previously was located on.
Backing up Windows Server 2003 systems requires only a small amount of knowledge to perform the few backup tasks. More information is necessary when it comes to recovery, however, because of two distinct reasons: Several Windows Server 2003 services can be restored to a previous configuration without affecting the entire system, and others have special restore requirements.
When a server running Certificate Services needs to be recovered, the Certificate server and database can normally be recovered using a system state restore. If the server was recovered using a clean installation with the same server name, the system must not join the domain at first. The system state must be restored to recover the computer account SID for the certificate server. If the CA server system state has not been backed up or cannot be restored properly, the CA may not be recoverable. When the CA service is recovered using a system state restore, the certificate database can be recovered if the correct version was not restored already.
To restore the Certification Authority if the database is corrupted or if an issued certificate is deleted by mistake, the administrator should restore the CA database. If the Certification Authority does not start or cannot issue certificates properly, the CA private key and CA certificate should be restored.
Only if the Certification Authority was previously backed up as outlined in Chapter 32 can the CA database be restored independently of a system state restore. The following sections assume that a previous backup was performed and saved to the c:CaBackup directory of the CA server.
To restore the CA private key and CA certificate, perform the following steps:
Log on to the Certification Authority server using an account with Local Administrator rights.
Click Start, All Programs, Administrative Tools, Certification Authority.
Expand the Certification Authority server and select the correct CA.
Select Actions, All Tasks, Restore CA.
A pop-up message appears stating that Certificate Services will need to be stopped during this operation. Click OK to stop the service.
Click Next on the Certification Authority Restore Wizard Welcome screen.
On the Items to Restore page, check the Private Key and CA Certificate boxes, type in the path of the backup folder, and click Next.
Enter the password previously specified during the CA private key and certificate backup process.
On the Completing the Certification Authority Restore Wizard page, click Finish to restore the private key and certificate and restart the Certification Authority service.
In the Certification Authority window, right-click Certification Authority and select Properties.
On the General tab of the CA’s property page, verify that the correct certificate was restored. Then click OK to close the CA property pages, close the Certification Authority console, and log off the server.
The CA database will be restored more often than the CA private key and certificate will be restored, although it may not be necessary very often. The CA database may need to be restored if a user’s or machine’s certificate was revoked mistakenly and needs to be recovered. Also, if the certificate database is corrupted, the database could be recovered to a previous state. When a database is recovered, any new certificates that were issued after the backup was performed will become invalid. Users and computers issued these certificates may need to request new certificates and may not be able to recover encrypted data. To avoid this problem, the administrator needs to back up the certificate database frequently using a system state backup. As a best practice, CA servers should be deployed on member servers to simplify the restore process.
To restore the CA database from a previous backup, perform the following steps:
Log on to the Certification Authority server using an account with Local Administrator rights.
Click Start, All Programs, Administrative Tools, Certification Authority.
Expand the Certification Authority server and select the correct CA.
Select Actions, All Tasks, Restore CA.
A pop-up message appears stating that Certificate Services will need to be stopped during this operation. Click OK to stop the service.
Click Next on the Certification Authority Restore Wizard Welcome screen.
On the Items to Restore page, check the Certificate Database and Certificate Database Log box and type in the path of the backup folder, as shown in Figure 33.2. Then click Next.
On the Completing the Certification Authority Restore Wizard page, click Finish to restore the certificate database and certificate database log and restart the Certification Authority service.
After the restore is complete, a pop-up window appears asking you to start Certificate Services. If additional incremental restores are necessary, click No and continue the restore process; otherwise, click Yes.
In the Certification Authority window, select the revoked certificates, issued certificates, or other locations to ensure that the correct database has been restored. Then click OK to close the CA property pages, close the Certification Authority console, and log off the server.
If a previous backup of the Dynamic Host Configuration Protocol (DHCP) database was performed manually using the DHCP console or if the default 60-minute database backup is being used, the following steps will restore a DHCP database to the original DHCP or an alternate DHCP server. The DHCP restore will restore server options, scopes, and scope options, including reservations, address leases, and address pools. The DHCP data will be restored in its entirety. If only a single lost configuration needs to be restored—for example, a reservation—the DHCP data can be restored to an alternate server with the DHCP service installed. This server does not need to be authorized in the forest. When the DHCP data is restored, the reservation information can be recorded and manually recreated on the original DHCP server.
To restore DHCP data to the original or an alternate DHCP server, follow these steps:
If a system was restored using a clean installation or ASR and the system state was restored, the DHCP data will have be restored. If a configuration change in the DHCP needs to be rolled back, proceed to the next step.
Locate the previously backed-up DHCP data, which by default is located in the c:Windowssystem32dhcpackup folder. If this folder does not exist on the local system, restore the folder from a previous backup to an alternate location—for example, c:dhcprestore.
Log on to the desired DHCP server using an account with Local and Domain Administrator permissions.
Click Start, All Programs, Administrative Tools, DHCP.
If the desired DHCP server is not listed, right-click DHCP in the left pane and choose Add Server.
Type in the fully qualified domain name of the desired DHCP server and click OK.
When the server is listed in the window, select and right-click the server. Then select Restore, as shown in Figure 33.3.
In the Browse for Folder window that is displayed, locate the previously backed-up DHCP data, select the folder, and click OK. This DHCP backup folder will be accessed on the local system drive in the %systemroot%system32dhcpackup folder or in an alternate restore folder.
A pop-up message appears stating that the DHCP service will need to be stopped and restarted for changes to take effect. Click Yes to restore the data and restart the DHCP server.
When the restore is complete, you might need to refresh the DHCP console. Select Action, Refresh, if necessary, to view changes.
To verify operation, boot up a DHCP client and check for proper addressing information and scope options. Also, check to ensure that reservations, if used, have been restored to the DHCP server configuration.
Close the DHCP console and log off the server.
Note
The DHCPExim utility can be used to quickly export and import DHCP configuration information to a file for safekeeping. This tool can be downloaded from Microsoft’s Web site at http://www.microsoft.com/windows2000/techinfo/reskit/tools/new/dhcpexim-o.asp.
When the Windows Internet Naming Service (WINS) needs to be recovered from a previous backup, it can be recovered only from a system state backup or using the last-saved WINS backup store in the %systemroot%system32WINSBackup folder. The default for WINS server backup is during system shutdown. If more frequent backups are necessary, perform the backup as outlined in the “Creating Regular Backup Procedures” section in Chapter 32.
To restore the WINS data, follow these steps:
Log on to the WINS server using an account with Local Administrator access.
Click Start, All Programs, Administrative Tools, WINS.
If the local WINS server does not appear in the window, right-click WINS in the left pane and select Add Server.
Type in the NetBIOS or fully qualified domain name of the WINS server and click OK.
Select the WINS server in the left pane.
Right-click the WINS server, select All Tasks, and then select Stop to stop the WINS service, as shown in Figure 33.4.
After the service is stopped, right-click the server icon and select Restore Database.
In the Browse for Folder window that is displayed, locate the previously backed-up WINS data, select the folder, and click OK.
After the restore is complete, the WINS service is automatically restarted. Verify that the correct WINS configurations and records have been restored.
Troubleshoot as necessary, close the WINS console, and log off the server.
Domain name system (DNS) zones can be created or restored using zone files created on Windows Server 2003 or from other DNS systems. Because dynamic Active Directory–integrated zones do not store a copy of the data in a backup file, these zones can be simply re-created and the servers and workstations will repopulate the data within. Entries manually entered in the Active Directory–integrated zones will need to be manually re-created. This is why multiple Active Directory DNS servers are desired to provide redundancy.
To restore standard primary zones from a backup file, simply create a new forward or reverse lookup zone but specify to create it using the existing backup file. Creating new zones on Windows 2003 DNS is covered in Chapter 9, “The Domain Name System.”
To recover file and folder data reported to be corrupt, accidentally deleted, or just missing from a server share or volume, the administrator must first verify the report. If a single file is reported corrupt, the administrator should verify file share and NTFS permissions to the file and parent folder to ensure that the error is not access related. After the error is confirmed, the administrator should request that the user show him the problem. If the file is corrupted, it should be restored from backup using one of the methods outlined in the following sections.
If data is reported lost or deleted on a volume, the administrator should first search for the file within subfolders on the same volume. If a user has the permissions to modify files on more than one folder on a volume, there is a chance that the missing file or folder was mistakenly dragged and dropped to a different folder. After a search is completed, the data can be restored to the original location if it is found; otherwise, the data can be restored from backup using one of the methods outlined in the following sections.
When data folders and/or files are corrupt, missing, or a previously backed-up copy is needed, the data can be restored using NTBackup.exe if a previous backup was performed using this utility. For example, if the Marketing folder was deleted from the D: drive of SERVER1, the following backup procedure could be used to restore the data:
Log on to SERVER1 using an account that has at least the privileges to restore files and folders. Backup Operators and Local Administrator groups have this right by default.
Click Start, All Programs, Accessories, System Tools, Backup.
If this is the first time you’ve run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink.
Click the Restore Wizard (Advanced) button to start the Restore Wizard.
Click Next on the Restore Wizard Welcome screen to continue.
On the What to Restore page, select the appropriate cataloged backup media, expand the catalog selection, and select the Marketing folder from the D: drive backup, as shown in Figure 33.5.
If the correct tape or file backup media does not appear in this window, cancel the restore process. Then, from the Restore Wizard, locate and catalog the appropriate media and return to the restore process from step 4.
On the Completing the Restore Wizard page, click Finish to start the restore.
When the restore is complete, review the backup log for detailed information and click Close on the Restore Progress window when finished.
The Volume Shadow Copy service can be used to restore missing files or restore previous versions of files only if shadow copies have been enabled on the volume. To enable shadow copies on a volume, refer to the installation steps outlined in the “Configuring Shadow Copies” section in Chapter 30, “File System Fault Tolerance.” To restore data using shadow copies, the volume containing the data in question needs to be accessed from a share point. For example, if Volume Shadow Copy is enabled on the D: drive of SERVER1, to restore data using a shadow copy, the administrator can open a connection to \SERVER1D$.
Restoring shadow copy data allows the administrator to restore the data to the original location, or it can be copied and restored elsewhere. As an example, the Marketing folder on the SERVER1 D: drive will be restored after it is deleted. When a user reports that the Marketing folder is missing from SERVER1, follow these steps:
Log on to SERVER1 with Administrator access to verify that the Marketing folder has been deleted.
Open an Explorer window to the \SERVER1D$ location.
After a few seconds, the View Previous Versions task is displayed, as shown in Figure 33.6. If the File and Folder Tasks section does not open, change the folder view.
To change the folder options, select Tools, Folder Options. Under Tasks on the General tab, select Show Common Tasks in Folders and click OK to update the folder view.
Select the View Previous Versions task in the left pane of the window.
When the Share Properties page opens, select the Previous Versions tab if it is not already selected.
In the Folder Version window, select the correct shadow copy and click the View button at the bottom of the window.
For this example, select the Marketing folder and choose Copy.
Close the Shadow Copy window and close the Share Properties page.
Back in the \SERVER1D$ window, right-click a blank spot in the window and choose Paste to restore the marketing folder.
Double-check permissions on the restored folder, close the window, and log off the server when you’re finished.
Another popular method of protecting the file system from data loss is to leverage the Distributed File System (DFS) replication technology to mirror information to another server. DFS is a solution that needs to be set up and running before a failure because the data needs to be replicated before a failover or recovery can take place. So this will require preplanning and implementation before the solution can be used.
To use DFS, a file system volume that is wanted for replication is identified, and a replica is created on another server. If the primary server fails, DFS automatically redirects users to access the mirrored copy of the data on the replica server.
For more details on the implementation of DFS for file system replication, see the section, “Using the Distributed File System Replication,” in Chapter 30, “File System Fault Tolerance.”
When Internet Information Services (IIS) data is erased or the service is not functioning as desired, restoring the configuration may be necessary. To restore the IIS metabase data, perform the following steps:
Log on to the desired IIS server using an account with Local Administrator privileges.
Click Start, Programs, Administrative Tools, Internet Information Services (IIS) Manager to open the IIS Manager console.
Select the Web server in the left pane.
Select Action, All Tasks, Backup/Restore Configuration.
On the Configuration Backup/Restore page, there will be a listing of automatic backups that IIS has already performed. Select the desired backup and click the Restore button to perform a manual restore.
A pop-up window opens stating that all Internet services will be stopped to restore the data and restarted afterward. Click Yes to begin the restore.
When the restore is complete, a confirmation pop-up window is displayed. Click OK to close this window.
Click Close on the Configuration Backup/Restore page.
Back in the IIS Manager window, verify that the restore was successful, close the window, and log off the server when you’re finished.
Backups are stored in the %systemroot%system32InetsrvMetaBack folder by default.
IIS Web and FTP folders are stored in the c:InetPub directory. The default location for the IIS logs is the c:Windowssystem32LogFiles folder. To recover the IIS Web site, FTP site, or IIS logs, restore the files using either shadow copy data or a backup/restore tool such as Ntbackup.exe. For detailed information on this process, refer to “Recovering Data with Volume Shadow Copy” and “Recovering Data Using NTBackup.exe,” respectively.
Cluster nodes require that special backup and restore procedures be followed to ensure a successful recovery if a cluster failure is encountered. For detailed information on backing up and restoring a cluster node, refer to the “Backing Up and Restoring Clusters” section in Chapter 31 or use the Windows Sever 2003 Help and Support Tool.
When a Windows Server 2003 domain controller fails, the administrator either needs to recover this server or understand how to completely and properly remove this domain controller from the domain. The following are some questions to consider:
Did this domain controller host any of the domain or forest Flexible Single Master Operations (FSMO) roles?
Was this domain controller a global catalog (GC) server, and if so, was it the only GC in a single Active Directory site?
If the server failed because of Active Directory corruption, has the corruption been replicated to other domain controllers?
Is this server a replication hub or bridgehead server for Active Directory site replication?
Using the preceding list of questions, the administrator can decide how best to deal with the failure. For example, if the failed domain controller hosted the PDC emulator FSMO role, the server could be restored, or the FSMO role could be manually seized by a separate domain controller. If the domain controller was the bridgehead server for Active Directory site replication, recovering this server may make the most sense so that the desired primary replication topology remains intact. The administrator should recover a failed domain controller as any other server would be recovered, restore the OS from an ASR restore or build a clean server, install all the necessary services, restore the system state, and perform subsequent restores of local drive data as necessary.
When undesired changes are made in Active Directory or the Active Directory database is corrupted on a domain controller, recovering the Active Directory database may be necessary. Restoring Active Directory can seem like a difficult task, unless frequent backups are performed and the administrator understands all the restore options.
The Active Directory database contains all the information stored in Active Directory. The global catalog information is also stored in this database. The actual filename is ntds.dit and is by default located in the c:WindowsNTDS directory. When a domain controller is restored from server failure, the Active Directory database is restored with the system state. If no special steps are taken when the server comes back online, it will ask any other domain controllers for a copy of the latest version of the Active Directory database. This situation is called a nonauthoritative restore of Active Directory.
When a change in Active Directory needs to be rolled back or if the entire database needs to be rolled back up across the enterprise or domain, an authoritative restore of the Active Directory database is necessary.
When a domain controller is rebuilt from a backup after a complete system failure, simply recovering this server using a restore of the local drives and system state is enough to get this machine back into the production network. When the machine is back online and establishes connectivity to other domain controllers, any Active Directory and SYSVOL updates will be replicated to the restored server.
Nonauthoritative restores are also necessary when a single domain controller’s copy of the Active Directory database is corrupt and is keeping the server from booting up properly. To restore a reliable copy of the Active Directory database, the entire system state needs to be restored, and if additional services reside on the domain controller, restoring the previous configuration data for each of these services may be undesirable. In a situation like this, the best option is to try to recover the Active Directory database using database maintenance and recovery utilities such as Esentutl.exe and Ntdsutil.exe. These utilities can be used to check the database consistency, defragment, and repair and troubleshoot the Active Directory database. For information on Active Directory maintenance practices with these utilities, refer to the Windows Server 2003 Help and Support.
To restore the Active Directory database to a single domain controller to recover from database corruption, perform the following steps:
Power up the domain controller and press the F8 key when the boot loader is displayed on the screen.
When the advanced boot options are displayed, scroll down, select Directory Services Restore Mode, and then press Enter to boot the server. This mode boots the Active Directory database in an offline state. When you choose this boot option, you can maintain and restore the Active Directory database.
When the server boots up, log on using the username Administrator and the Restore mode password specified when the server was promoted to a domain controller. To change the Restore mode password on a domain controller running in Normal mode, use the Ntdsutil.exe utility; this process is covered in Chapter 32.
Click Start, Run.
When the Backup or Restore window opens, click the Advanced Mode hyperlink.
Select the Restore and Manage Media tab.
Select the appropriate backup media, expand it, and check the system state. If the correct media are not available, the file must be located, or the tape must be loaded in the tape drive and cataloged before it can be used to restore the system state.
Choose to restore the data to the original location and click the Start Restore button in the lower-right corner of the backup window.
A pop-up window indicates that restoring the system state to the original location will overwrite the current system state. Click OK to continue.
A confirm restore window opens in which you can choose advanced restore options. Click OK to initiate the restore of the system state.
When the restore is complete, a system restart is necessary to update the services and files restored during this operation. Because only a nonauthoritative restore of the Active Directory database is necessary, click Yes to restart the server.
After the server reboots, log in as a Domain Administrator.
Check the server event log and Active Directory information to ensure that the database has been restored successfully and log off the server when completed.
When a change made to Active Directory is causing problems or when an object is modified or deleted and needs to be recovered to the entire enterprise, an Active Directory authoritative restore is necessary.
To perform an authoritative restore of the Active Directory database, perform the following steps:
Power up the domain controller and press the F8 key when the boot loader is displayed on the screen.
When the advanced boot options are displayed, scroll down, select Directory Services Restore Mode, and press Enter to boot the server. This mode boots the Active Directory database in an offline state. When you choose this boot option, you can maintain and restore the Active Directory database.
When the server boots up, log in using the username Administrator and the Restore mode password specified when the server was promoted to a domain controller. To change the Restore mode password on a domain controller running in Normal mode, use the Ntdsutil.exe utility; this process is covered in Chapter 32.
Click Start, Run.
Type
Ntbackup.exeand click OK.When the Backup or Restore window opens, click the Advanced Mode hyperlink.
Select the Restore and Manage Media tab.
Select the appropriate backup media, expand it, and check the system state. If the correct media are not available, the file must be located, or the tape must be loaded in the tape drive and cataloged before it can be used to restore the system state.
Choose to restore the data to the original location and click the Start Restore button in the lower-right corner of the backup window.
A pop-up window indicates that restoring the system state to the original location will overwrite the current system state. Click OK to continue.
A confirm restore window opens in which you can choose advanced restore options. Click OK to initiate the restore of the system state.
When the restore is complete, a system restart is necessary to update the services and files restored during this operation. Because an authoritative restore of the Active Directory database is necessary, click No.
Close the backup window and click Start, Run.
Type
cmd.exeand click OK to open a command prompt.At the command prompt, type
ntdsutil.exeand press Enter.Type
Authoritative restoreand press Enter.Type
Restore Databaseand press Enter to restore the entire database. Depending on whether this domain controller is in the forest root domain, a tree root domain, or a child domain in the Active Directory partitions, such as the schema partition and/or the domain naming context partition, the information will be replicated to all the other appropriate replication partner domain controllers.An authoritative restore confirmation dialog box appears; click Yes to start the authoritative restore.
The command-prompt window displays whether the authoritative restore was successful. Close the command prompt and reboot the server.
Boot up the server in Normal mode, log in, and open the correct Active Directory tools to verify whether the restore was successful. Also, check on other domain controllers to ensure that the restore is being replicated to them.
When you’re done, perform a full backup of the domain controller or at least the system state; then log off the server when the backup is complete.
Most Active Directory authoritative restores are performed to recover from a modification or deletion of an Active Directory object. For example, a user account has been deleted instead of disabled, or an organizational unit’s security has been changed and the administrator is locked out. Recovering only a specific object, such as a user account or an organizational unit or a container, requires the distinguished name (DN) of that object. To find the distinguished name, the administrator can use the Ntdsutil utility; however, if an LDIF dump of Active Directory exists, this file would be most helpful. If no LDIF file exists and the DN of the object to be recovered is unknown, recovery of the single object or container is not possible.
To simplify the steps to partial recovery, we will use an example of recovering a single user account using the logon Khalil that was previously contained in the Users container in the Companyabc.com domain. To restore the user account, follow these steps:
Power up the domain controller and press the F8 key when the boot loader is displayed on the screen.
When the advanced boot options are displayed, scroll down, select Directory Services Restore Mode, and press Enter to boot the server. This mode boots the Active Directory database in an offline state. When you choose this boot option, you can maintain and restore the Active Directory database.
When the server boots up, log in using the username Administrator and the Restore mode password specified when the server was promoted to a domain controller. To change the Restore mode password on a domain controller running in Normal mode, use the Ntdsutil.exe utility; this process is covered in Chapter 32.
Click Start, Run.
When the Backup or Restore window opens, click the Advanced Mode hyperlink.
Select the Restore and Manage Media tab.
Select the appropriate backup media, expand it, and check the system state. If the correct media are not available, the file must be located, or the tape must be loaded in the tape drive and cataloged before it can be used to restore the system state.
Choose to restore the data to the original location and click the Start Restore button in the lower-right corner of the backup window.
A pop-up window indicates that restoring the system state to the original location will overwrite the current system state. Click OK to continue.
A confirm restore window opens in which you can choose advanced restore options. Click OK to initiate the restore of the system state.
When the restore is complete, a system restart is necessary to update the services and files restored during this operation. Because only a nonauthoritative restore of the Active Directory database is necessary, click No.
Close the backup window and click Start, Run.
At the command prompt, type
ntdsutil.exeand press Enter.Type
Authoritative restoreand press Enter.Type
Restore Object "cn=Khalil,cn=Users,dc=companyabc,dc=com"and press Enter, as shown in Figure 33.7.The success or failure of the restore appears in the command prompt. Now type
quitand press Enter. Repeat this step until you reach the C: prompt.Close the command-prompt windows and reboot the server.
Log on to the server with a Domain Administrator account and verify that the account has been restored. Then log off the server.
There are no special restore considerations for restoring a global catalog server other than those outlined for restoring Active Directory in the previous sections. The global catalog data is re-created based on the contents of the Active Directory database.
The SYSVOL folder contains the system policies, Group Policies, computer startup/shutdown scripts, and user logon/logoff scripts. If a previous version of a script or Group Policy Object is needed, the SYSVOL folder must be restored. As a best practice and to keep the process simple, the SYSVOL folder should be restored to an alternate location where specific files can be restored. When the restored files are placed in the SYSVOL folder, the File Replication Service will recognize the file as new or a changed version, and it will replicate it out to the remaining domain controllers. If the entire SYSVOL folder needs to be pushed out to the remaining domain controllers and the Active Directory database is intact, a primary restore of the SYSVOL is necessary.
To perform a primary restore of the SYSVOL folder, follow these steps:
Power up the domain controller and press the F8 key when the boot loader is displayed on the screen.
When the advanced boot options are displayed, scroll down, select Directory Services Restore Mode, and press Enter to boot the server. This mode boots the Active Directory database in an offline state. When you choose this boot option, you can maintain and restore the Active Directory database.
When the server boots up, log in using the username Administrator and the Restore mode password specified when the server was promoted to a domain controller. To change the Restore mode password on a domain controller running in Normal mode, use the Ntdsutil.exe utility; this process is covered in Chapter 32.
Click Start, Run.
When the backup or restore window opens, click the Advanced Mode hyperlink.
Select the Restore and Manage Media tab.
Select the appropriate backup media, expand it, and check the system state. If the correct media are not available, the file must be located, or the tape must be loaded in the tape drive and cataloged before it can be used to restore the system state.
Choose to restore the data to the original location and click the Start Restore button in the lower-right corner of the backup window.
A pop-up window indicates that restoring the system state to the original location will overwrite the current system state. Click OK to continue.
A confirm restore window opens in which you can choose advanced restore options. Click the Advanced button to view the advanced restore options.
Check the box labeled When Restoring Replicated Data Sets, Mark the Restored Data as the Primary Data for All Replicas, as shown in Figure 33.8.
Click OK to return to the Confirm Restore page and click OK to start the restore.
When the restore is complete, a system restart is necessary to update the services and files restored during this operation. Because only a nonauthoritative restore of the Active Directory database is necessary, click Yes to restart the server.
After the server reboots, log in using an account with Domain Administrator access.
Check the server event log and the SYSVOL folder to ensure that the data has been restored successfully and log off the server when you’re finished.
If Remote Storage is installed on a system or Ntbackup.exe is used, the media used by both services are managed by the Removable Storage service. The Removable Storage service stores information concerning media stored in tape devices, including tape libraries. The information kept in the database may include a list of all the media pools and media contained within each pool. The service database also contains media labels and other media-related information.
In the event of a system failure in which the operating system needs to be loaded from scratch and removable storage media information needs to be restored, follow this procedure to restore the removable media database:
If the operating system is not in a recoverable state, reinstall the OS if necessary.
Locate the backup media containing the most recent or desired backup of the removable storage database. These files are located in the %systemroot%system32NTMSData folder. To locate the latest copy of the database, insert the most recent backup tape or tapes into the backup device and catalog them.
After you insert the tape into the backup device, open Computer Management from the Administrative Tools menu.
In the left pane, select the plus sign next to Storage to expand it and expand Removable Storage and Libraries.
Under Libraries, right-click the appropriate backup device and choose Inventory.
When the tape device completes the inventory process, the tape information will be listed in the right pane. Note the location information stating which media pool it is currently in.
Place the media in the backup media pool. The backup media pool has submedia pools for the type of media device. For example, see the DLT media pool shown in Figure 33.9.
In the left pane, click the plus sign to expand Media Pools and then expand Backup Media Pool. If the backup media pool does not exist, opening Ntbackup.exe automatically creates the media pool.
If you used only the plus signs to expand the listings, the inventoried media will still be listed in the right pane. If not, select the appropriate tape device in the left pane as previously outlined.
Click and drag the backup media on the right to the backup media pool in the left pane.
Close Computer Management.
Click Start, All Programs, Accessories, System Tools, Backup.
If this is the first time you’ve run Backup, it will open in Wizard mode. Choose to run it in Advanced mode by clicking the Advanced Mode hyperlink.
Click the Restore and Manage Media tab and select either a file or the correct tape device type to start a catalog. The catalog will run one level at a time, so to view the files in the NTMSData directory, you may need to browse a few times.
When the tape is cataloged, review the actual files in the NTMSData directory for last modified date to decide whether these versions of the files are recent enough.
Select all the files within the NTMSData directory, and in the Restore Files To section, select Alternate Location. For the path, specify a restore location. If necessary, use Windows Explorer to create a directory and specify that path in the backup program.
Click the Start Restore button to start the restore process. In the Confirm Restore window, click OK to start the restore.
When the backup is complete, close the Restore Progress window and close the backup program.
Open My Computer or Windows Explorer and locate the files in the restored location. Select all the files, right-click them, and choose Copy.
Open the Services applet, locate the Removable Storage service, right-click it, and stop it. Then minimize the window.
Open a Windows Explorer window and browse to the %systemroot% system32NTMSData directory and delete all the files within it.
Right-click a blank spot in the window and choose Paste to copy in all the files previously restored.
Restore the Services applet to a viewable size, locate the Removable Storage service, right-click the service, and start it. Then close the Services applet.
Open removable media from the Computer Management console and verify that the correct media pools and media information have been restored.
Close Computer Management and log off the server.
To restore the Remote Storage database after the operating system has been recovered or if the service cannot be started, perform the following steps:
Log on to the Remote Storage server using an account with Local Administrator access.
Click Start, All Programs, Administrative Tools, Remote Storage.
In the Remote Storage window, verify that the service is not running or the correct managed volume information is incorrect.
Back on the desktop, click Start, All Programs, Administrative Tools, Services.
Scroll down in the Services applet and stop the Remote Storage Server and Remote Storage Notification services if either or both of them are running.
Minimize the Services applet window.
Click Start, Run.
In the command prompt, change to the %systemroot%system32 RemoteStorageEngdb folder and delete the files contained in it.
At the command prompt, type
rstore.exe c:system32RemoteStorageengdb.bakand press Enter. This command assumes that the operating system has been installed in the default location on the C: drive of the system.Close the command-prompt window and open the Services applet window that was minimized.
Scroll down to find the Remote Storage Server service and start it.
Close the Services applet and open the Remote Storage console.
In the Remote Storage console, verify that the managed volume information has been successfully restored.
Close the Remote Storage console and all other Windows; then log off the server.
If a file has been previously migrated to remote storage media and has been replaced on a volume with a reparse or junction point, both the remote storage media and the reparse point are needed to access the migrated data. If a user inadvertently deletes the reparse point, the administrator needs to use standard file and folder recovery processes to restore it. If no backup of the reparse point is available, the migrated data must be accessed using alternate methods.
To recover this data, insert the correct Remote Storage media into the tape device. After the media is loaded, open the Removable Storage service and move the media from the Remote Storage media pool to the backup media pool as necessary. When that is accomplished, open Ntbackup.exe and catalog the media, locate the data, and restore the original file to the desired location. One of the problems is that the data is not saved in the same folder hierarchy as it was originally on the disk, so you will need the filename and version to recover the data.
When the topic of disaster recovery comes up, many people think of the phrase “five nines” or “99.999% uptime.” Although understanding this concept is reasonably simple, actually providing five nines for a server or a network can be quite a large and expensive task. Achieving 99.999% uptime means that the server, application, network, or whatever is supposed to have this amount of uptime can only be down for just over five minutes a year. Having such success is quite a claim to make, so administrators should make it with caution and document it, citing explicitly what this service depends on. For example, if a power failure occurs and the battery backups will last only two hours, a dependency for a server could be that if a power outage occurs, it can withstand up to two hours without power.
To provide 99.999% uptime for services available on Windows Server 2003, administrators can build in redundancy and replication on a data, service, server, or site level. Many Windows Server 2003 services outlined in previous chapters in this book, including Cluster Services, network load balancing, the Distributed File System, and the File Replication Service, can provide redundancy at each level described here.
To provide redundant domain and network services to be able to deliver five nines uptime, administrators can use Windows Server 2003 built-in services and clever designs to meet the particular type of failure or disaster they are planning for. For example, if an organization provides a Web-based Internet application, five nines can be achieved in a single location by deploying the application on a network load-balancing cluster of servers. To provide this same application across separate sites, the organization would need to establish a VPN across the sites so that a single DNS record could be used to access the server from either location.
Most administrators hate to find themselves trying to recover from a disaster. Without proper planning and testing of backup and recovery procedures, including planning for all the different types of failures, recovering from a failure can take unnecessarily long or might be unachievable. The information provided in Chapter 32 and this chapter can provide an organization with the basic knowledge of what sorts of disasters can occur and how to successfully back up and recover Windows Server 2003 systems.
Document backup and recovery procedures.
Periodically test the restore procedures to verify accuracy and test the backup media to ensure that data can actually be recovered.
Isolate failures before attempting a restore or fixing a problem.
Allocate the appropriate hardware devices including servers with enough processing power and disk space to accommodate the restored machines’ resources.
Host the organization’s DNS zones and records using primary DNS servers located either at an Internet service provider (ISP) co-location facility or have a redundant DNS server registered for the domain and located at both the physical locations.
Ensure that DNS record-changing procedures are documented and available at the remote site or at an offsite data storage location.
Ensure that the host records in the DNS tables for the VPN and Terminal servers are set to low Time to Live values so that DNS changes do not take extended periods to propagate across the Internet.
Ensure that network connectivity is established and stable between each site.
Replicate file data between the two sites as often as possible.
Create at least three copies of backup tape media from a site.
Store a copy of all disaster recovery documentation at a secure location but also keep copies in other locations.
Define hot spare disks for arrays.
Use RAID 1 for system and boot partitions.
Understand the dependencies of the applications and services to the operating system to choose whether to rebuild or restore from backup.
Do not restore the system state if a server has been cleanly installed and is joined to the original domain.
Identify and document special restore requirements for each server.
Use a specified subfolder for the restore point such as
c:RestoredDatato reduce the chance of confusion.