CHAPTER 30
Recovering from a Disaster

When organizations need to recover data or restore business services and operations after a disruption in business operations, having a well-formulated and validated recovery plan is vital to success. This requires a disciplined process of creating and maintaining backup and recovery procedures and documentation, as well as periodically validating the recovery tasks by simulating different failure scenarios and recovering data and applications.

In addition to having a disaster recovery plan, many organizations—not just the organizations that are required by law—should also implement and follow a strict change management system to evaluate the benefits and risks associated with proposed changes to current business systems, services, applications, and operational processes.

This chapter, as a complement to Chapter 29, “Backing Up the Windows Server 2016 Environment,” details how to recover a Windows Server 2016 environment using Windows Server Backup after a failure or disaster has occurred. In addition to system recovery, this chapter provides some best practices and ideas organizations should consider when planning how to support and restore operation to the computer and network infrastructure when system failures and disasters occur.

Each year, many businesses, business divisions, or departments update their computer and network infrastructure and change the way they provide services to their staff, vendors, and clients. In many of these cases, the responsible information technology staff, cross-departmental managers, executives, and employees are not involved or properly informed in advance of the execution or implementation of these changes. Computer and network infrastructure changes can have ripple effects throughout an entire organization during transition and during disaster and failure situations, so proper planning and approval of changes should always be performed and documented.

To reduce the risk of a change negatively impacting business operations, many organizations implement processes that require new projects and system changes to be submitted, evaluated, and either approved or rejected based on the information provided. Although this chapter does not focus or even really discuss project management, all organizations that utilize computer and network infrastructures should consider implementing a project management office and change-control committee to review and oversee organizational projects and infrastructure changes.

The role of the PMO can be different in almost every organization, but most include a few key functions. The role of the PMO usually involves reviewing proposed projects to determine how or if the project deliverables coincide with the organization’s current or future business plans or strategies. PMO membership can also be very different among organizations. PMO membership can include departmental managers, directors or team leads, executive staff, employee advocates, and, in some cases, board members. Having the PMO staff represent views and insight from the different levels and departments of an organization enables the PMO to add value to any proposed project.

Having diverse staff included in the PMO staff enables the organization to evaluate and understand current and proposed projects and how these projects will positively or negatively affect the organization as a whole. General functions or roles a PMO can provide include the following:

High-level project visibility—All proposed projects are presented to the PMO and if approved, the project is tracked by the PMO. This provides a single entity that is knowledgeable and informed about all ongoing and future projects in an organization and how they align to business and technical objectives.

Project sounding board—When a new project is proposed or presented to the PMO, the project will be scrutinized and many questions will be asked. Some of these questions might not have been considered during the initial project design and planning phases. The PMO improves project quality by constantly reviewing and monitoring projects from when the project is proposed and during regular scheduled project status and PMO meetings.

Committee-based project approval or denial—The PMO is informed of all the current and future projects as well as business direction and strategy and is the best-equipped group to decide on whether a project should be approved, denied, or postponed.

Enterprise project management—The PMO tracks the status of all ongoing projects and upcoming projects, which enables the PMO to provide additional insight and direction with regard to internal resource utilization, vendor management for outsourced projects, and, of course, project budget and scheduling.

Change description—Includes which systems will be changed, what the change is, and why it is proposed or required

Impact of the change—Details if any systems or services will be unavailable during the execution of the change and who will be affected or impacted by the change

Change duration—Details how long it will take to execute and complete the change and, if necessary, revert or roll back the change

Change schedule—Includes the proposed date and time to execute the change

Change procedure—Details how the change will be executed, including a detailed description; this usually also includes detailed steps or an accompanying document

Change rollback plan—Details the steps necessary to recover or roll back the change in the event that the change causes undesirable results

Change owners—Includes who will execute the change and is responsible for communicating the status and results of the change back to the change-control committee

A change-control committee, similar to a PMO, is made of up of managers, executives, and employee advocates who will review and determine if the change is approved, denied, or needs to be postponed. Proposed changes are submitted in advance. A day or two later, a change-control review meeting is held where each change is discussed by the change-control committee and the change owner and the change will be approved, denied, postponed, or closed, or more information will be requested.

During failure or disaster situations, going through the normal change-control process might not be an option due to the impact of the failure. During these situations, emergency change-request processes should be followed. An emergency change request usually involves getting the particular departmental manager and the responsible information technology manager, director, or CIO to sign off on the change before it is executed. In short, all changes need to be considered and approved, even in failure scenarios when time is of the essence. When an administrator is troubleshooting and trying to resolve a failure or trying to recover from a disaster, especially in a stressful situation, making changes without getting approval can lead to costly mistakes. Following the proper change-control and emergency change-control processes to inform and involve others, getting approval from management, and following documented processes will provide accountability and might even save the administrator’s job.

The chief information officer is responsible for disaster recovery planning and maintaining and executing disaster recovery-related tasks for the entire telecom, desktop and server computer infrastructure, network infrastructure, and all other electronic and fax-related communication.

The manager of facilities or operations is responsible for planning alternate office locations and offsite storage of original or duplicates of all important paper documents, such as leases, contracts, insurance policies, stock certificates, and so on, to support disaster recovery operations to alternate sites or offices.

The manager of human resources is responsible for creating and maintaining emergency contact numbers for the entire company, storing this information offsite, and communicating with employees to provide direction and information prior to disasters striking and during a disaster recovery operation.

The list of responsibilities can be very granular and extensive, and disaster recovery planning should not be taken lightly or put on the back burner. Although there are many aspects of disaster recovery planning, the remainder of this chapter focuses only on the disaster recovery responsibilities and tasks that should be assigned to qualified Windows administrators who need to support a Windows Server 2016 environment.

If the system is, in fact, in a failed state, the impact of the failure should be noted, and this information should be escalated within the organization so that a formal recovery plan can be created. This can be known as qualifying the disaster or failure. An example of qualifying a failure includes a short description of the failure, the steps used to validate the failure, who is affected, how many end users are affected, which dependent applications or systems are affected, which branch offices are affected, and who is responsible for the maintenance and recovery of this system.

When a serious failure has occurred, recovery efforts might require multiple technical resources onsite for an extended period of time. Furthermore, some dependencies might affect which systems can be restored, and, of course, the order or priority of restore will advance or delay the recovery of a system. Mapping out the extended recovery timeline and technical resource scheduling ensures that a technical resource is not onsite until their skills and time are required. Also, rotating technical resources after 6 to 8 hours of time helps to keep progress moving forward.

Test the reported outage to verify if the issue is related to a wide-area network (WAN) connection between the organization and the Internet service provider (ISP), the router, a network switch, a firewall, a physical fiber or copper network connection or network port, or line power to any of the aforementioned devices.

After the issue is isolated or, at least, the scope of the issue is understood, the network administrator should communicate the outage to the necessary managers or business owners and, as necessary, open communication to outside support vendors and ISP contacts to report the issue and create a trouble ticket. And no, this should not go out in email if the network is down.

Create a logical action plan to resolve the issue and execute the plan.

Create and distribute a summary of the cause and result of the issue and how it can be avoided in the future. Close the trouble ticket as required.

Can the main and most critical phone lines be accessed or forwarded remotely?

Is there a remote-access solution to allow employees with or without notebooks/laptop computers to connect to the organization’s network and perform their work?

Are any other business operations that require onsite access tied to a service-level agreement, such as responding to paper faxes or submitted customer support emails, phone calls, or custom applications?

Can all services be restored in an alternate capacity—or at least the most critical systems, such as the main phone lines, fax lines, devices, applications, system, and remote access services?

If systems are cut over to an alternate location, what is the impact in performance, or what percentage of end-user load can the system support?

If systems are cut over to an alternate location, will there be any data loss or will only some data be accessible?

If the decision to cut over to the alternate location is made, how long will it take to cut over and restore the critical services?

If the site outage is caused by power loss or network issues, how long of an outage should be sustained before deciding to cut over services to an alternate location?

When the original system is restored, if possible, what will it take to failback or cut the systems back to the main location, and is there any data loss or synchronization of data involved?

These short lists merely break the surface when it comes to the planning of or dealing with a physical site outage, but, hopefully, they will spark some dialogue in the disaster recovery planning process to lead the organization to the solution that meets their needs and budget.

For Windows services, using Server Manager to review the status of the role and role services assists administrators in identifying and isolating problems because the Server Manager tool displays a filtered representation of Event Viewer items and service state for each role installed on the system. Figure 30.1 details that the File and Storage Services role FILESERVER1 had logged and issue related to the role service.

When a system is suspected of having hardware issues and it is a business-critical system, steps should be taken to migrate services or applications hosted on that system to an alternate production system, or the system should be recovered to new hardware. Windows Server 2016 can tolerate a System Image Recovery to alternate hardware if the system is an exact or close hardware match with regard to the motherboard, processors, hard disk controller, and network card. Even if the hardware is exact and the disk arrays, disk IDs, and volume or partition numbers do not match, a System Image Recovery to alternate hardware might fail if no additional steps are taken during the restore or recovery process.

If the system can communicate out but users still cannot access the system, possible causes could be an incorrect IP subnet mask, default gateway or routing table, or firewall restrictions imposed locally or through group policy. Windows Firewall is enabled by default on Windows Server 2016 systems, and the firewall supports multiple firewall profiles simultaneously if multiple adapters are installed on the system. If a network is identified incorrectly as a public network instead of a private or domain network, depending on the firewall profile settings, this may undesirably restrict access. When administrators follow the proper procedures for installing roles and role services, during role installation, exceptions will be added to the firewall. Administrators can review the settings using the Windows Firewall applet from Control Panel, but to get very detailed firewall information, the Windows Firewall with Advanced Security console should be used. You can access this console through the Server Manager Tools menu.

1. Log on to the Windows Server 2016 system with an account with administrator privileges and open Server Manager from the taskbar.

2. Click the File and Storage Services link in the tree pane on the left.

3. In the File and Storage Services section of Server Manager, click the Shares link and in the Shares pane, right-click the desired share, and select Properties.

4. Select the Permissions link on the left, and the window will display the NTFS permission and will summarize the share permissions.

5. Click the Customize Permissions button.

6. In the Advanced Security Settings window, select the permission tab for NTFS permissions, the Share tab for share permissions, and the Central Policy tab to review Dynamic Access Control settings for the shared folder, as shown in Figure 30.2.

7. Close the Advanced Security Settings window, close the share properties window, and close Server Manager when done reviewing the settings.

1. Log on to the Windows Server 2016 system with an account with administrator privileges and open Server Manager.

2. From the Server Manager tools menu, select Local Security Policy.

3. In the tree pane of the Local Security Policy window, double-click Local Policies, and double-click Audit Policy.

4. In the tasks pane, double-click Audit Object Access.

5. When the Audit Object Access window opens, check the Failure check box, and click OK, as shown in Figure 30.3.

6. Close the Local Security Policy window.

7. Back in Server Manager, click the File and Storage Services link in the tree pane on the left.

8. In the File and Storage Services section of Server Manager, click the Shares link and in the Shares pane, right-click the desired share, and select Properties.

9. Select the Permissions link on the left, and the window will display the NTFS permission and will summarize the share permissions.

10. Click the Customize Permissions button.

11. Select the Auditing tab and click the Add button to change the audit settings of the shared folder. In this particular example, we want to log failed attempts to access the folder, so we will use the Everyone group and enable All Failure Audits.

12. In the Audit Entry for the share window, click the Select a Principal link at the top of the window.

13. When the Select User, Computer, Service Account, or Group window opens, type in Everyone and click OK.

14. In the Auditing Entry for the share window, pull down the Type menu and select the Fail Audit option and check the Full Control Permissions check box. Click OK to apply the new audit settings, as shown in Figure 30.4.

15. In the Advanced Security Settings window, check the Replace All Existing Inheritable Auditing Entries check box, and then click OK.

16. Click OK to close the Advanced Security page, click OK to close the share property pages, and close Server Manager.

When a user then attempts to access the shared folder with the enabled audit settings and fails based on permissions, a failed audit entry will be logged on the server’s Security event log.

1. Log on to a Windows Server 2016 system or a client system running Windows XP SP1 or greater and open Windows Explorer.

2. In the Windows Explorer window type \servername and press Enter, where servername represents the NetBIOS or fully qualified domain name of the server hosting the file share. The share must already exist and be stored on a volume in which a shadow copy has already been created.

3. Right-click the folder beneath the share, or the share itself, that contains the file or folder that will be restored, and select Restore Previous Versions.

4. When the window opens, if necessary, select the Previous Versions tab, and select the desired previous version based on the date and click Open, as shown in Figure 30.5.

5. After the previous version of the share or folder beneath the share is opened, displaying the contents, select a single file single folder or multiple items, right-click the selections, and choose Copy. This places the selected items in the Clipboard.

6. Close the previous version window and close the share or folder properties window.

7. Browse to the location where the data will be restored, right-click in an empty location, and choose Paste. Overwrite the file as desired or restore the data to an alternate location, and close all the windows when completed.

1. Log on to the Windows Server 2016 system with an account with administrator privileges and open Server Manager from the taskbar.

2. From the Tools menu, select Windows Server Backup.

3. When the Windows Server Backup window opens, select Local Backup in the tree pane.

4. Click Recover from the actions pane.

5. On the Getting Started page, select either to restore data previously backed up from the local computer or a different computer. For this example, select This Server (Servername), and click Next to continue.

6. On the Select Backup Data page, select the date of the backup by selecting the correct month and click the particular day.

7. After the month and day are selected, if multiple backups were run in a single day, click the Time drop-down list arrow, and select the correct backup. Click Next to continue after the month, day, and time are selected.

8. On the Select Recovery Type page, select the Files and Folders option button, and click Next to continue.

9. On the Select Items to Recover page, expand the server node; select the disks, folders, and files to be restored; and click Next to continue.

10. On the Specify Recovery Options page, specify whether the files will be restored to the original location or an alternate location. Do not click Next.

11. On the Specify Recovery Options page, if the restore will be placed in the original location, specify how to deal with existing files by choosing to either create copies in the same folder, overwrite the existing data with restore data or do not recover items that already exist. Also check or uncheck the check box to determine whether NTFS access control lists will also be restored with the data.

12. On the Confirmation page, verify the restore selections and options. If everything is correct, click the Recover button to start the recovery process.

13. On the Recovery Progress page, verify the success of the recovery or troubleshoot the errors if the recovery fails.

14. Click Close to complete the recovery and close Windows Server Backup.

15. Browse to the location of the restore to verify the recovery and notice that there are two copies, the original and the restored, which is named after the date and time the backup was taken. When you have finished, log off of the server.

Windows Server Backup can be configured to run a scheduled backup or a manual backup. Either can be run from the graphical user interface or the command-line utility, but the backup options, including where the backup can be stored and the recovery options available, are different.

A Windows Server Backup disk can have a drive letter added after the initial backup is created if the disk needs to be accessed from within the operating system, from across the network, or if the backup data needs to be copied to additional disks or network folders for offsite storage. Backups contained on a Windows Server Backup dedicated disk can be used to restore an entire system, an entire volume, a set of specified files and folders, or application data.

1. Log on to the Windows Server 2016 system with an account with administrator privileges and open Server Manager from the taskbar.

2. From the Tools menu, select Windows Server Backup.

3. When the Windows Server Backup window opens, select Local Backup in the tree pane.

4. Click Recover from the actions pane.

5. On the Getting Started page, select either to restore data previously backed up from the local computer or a different computer. For this example, select This Server (Servername), and click Next to continue.

6. On the Select Backup Data page, select the date of the backup by selecting the correct month and click the particular day.

7. After the month and day are selected, if multiple backups were run in a single day, click the Time drop-down list arrow, and select the correct backup. Click Next to continue after the month, day, and time are selected.

8. On the Select Recovery Type page, select the Volumes option button, and click Next to continue.

9. On the Select Volumes page, the window displays each of the volumes contained in the backup that was previously chosen. Check the box next to the desired volume that will be restored, and select the destination volume to which you will restore the backed-up volume. Click Next to continue after the correct selections are made.

10. After clicking Next on the Select Volumes page, a window opens requesting confirmation that the data on the volumes will be lost by the recovery process; click Yes to continue with the volume recovery process.

11. On the Confirmation page, review the selections. If everything looks correct, click the Recover button to start the volume recovery.

12. On the Recovery Progress page, the recovery status of the volume will be displayed. After the recovery completes, review the results and click Close if the recovery was successful; otherwise, select the Errors tab to review the errors.

13. If the volume recovery was successful, the only additional step that might be required is to reboot the system if the data on the volume is shared or used by any applications or services. Reboot as required.

1. Boot your system using the Windows Server 2016 installation media. If necessary, configure the BIOS to allow booting from the CD/DVD drive and, if prompted, press a key to boot from the DVD.

2. When the Windows Setup interface opens, select the correct language, time, and keyboard settings, and click Next to continue.

3. On the next page, click the Repair Your Computer link located in the lower-left corner of the window.

4. On the Choose an Option page, select the Troubleshoot tile.

5. On the Advanced Options page, select System Image Recovery tile to continue.

6. On the System Image Recovery page, select to restore the Windows Server 2016 installation by clicking the tile.

7. A Re-Image Your Computer window will open and will display the option to restore the latest available system image by default.

8. On the Choose Additional Restore Options page, the box labeled Only Restore System Drives will be checked and dimmed (grayed out). Do not make any other changes. Click Next to continue. This will leave any other disks intact, but any volumes that are hosted on the same disks that contain system volumes will be formatted, re-created, and restored as well.

9. The next page details the date and time of the backup that will be restored, the server that will be restored, and the volumes that are contained in this restore set. Review the information and click Finish to continue with the recovery of the system volumes.

10. A dialog box will appear stating that all drives selected will be restored with the data in the system image. Click Yes to approve this and continue.

The recovery time frame will vary depending on the size of the system volume, the performance of the volume, and the restore disk or network share. After the recovery completes, the system will automatically reboot.

11. After the system reboots, log on and verify functionality. If everything is back up and running, run a full backup and log off.

1. Log on to the Windows Server 2016 system with an account with administrator privileges and open Server Manager from the taskbar.

2. From the Tools menu, select Windows Server Backup.

3. When the Windows Server Backup window opens, select Local Backup in the tree pane.

4. Click Recover from the actions pane.

5. On the Getting Started page, select either to restore data previously backed up from the local computer or a different computer. For this example, select This Server (Servername), and click Next to continue.

6. On the Select Backup Data page, select the date of the backup by selecting the correct month and click the particular day.

7. After the month and day are selected, if multiple backups were run in a single day, click the Time drop-down list arrow, and select the correct backup. Click Next to continue after the month, day, and time are selected.

8. On the Select Recovery Type page, select the System-State option button, and click Next to continue.

9. On the Select Location for System-State Recovery page, click the Original Location button and click Next to continue. If this system was a domain controller, more options will be available, but that is covered later in this chapter.

10. On the Confirmation page, review the section and then press Recover to start the process. Once the process starts a checkbox to Automatically reboot the server to complete the recovery process is presented and already checked by default.

11. After the system reboots, log on to the server to verify functionality. If the system is working properly, perform a full system backup.

1. Log on to the Windows Server 2016 domain controller system with an account with domain administrator privileges and open Server Manager from the taskbar.

2. From the Tools menu of Server Manager, select Active Directory Administrative Center.

3. In the tree pane, click the domain to reveal each of the root-level organizational units and containers. Select the Deleted Objects container.

4. In the center pane, each of the deleted objects should be listed. Review or expand the Last Known Parent column. This is the location the object will be restored to by default.

5. If the last known parent is where the object should be restored to, right-click the object and select Restore, as shown in Figure 30.6. If the object should be restored elsewhere, right-click the object and select Restore To, and then select the desired container or organizational unit.

A deleted object needs to be restored and the Active Directory Recycle Bin is not enabled, or was not enabled when the object was originally deleted.

The Active Directory Domain Services service will not start or the Active Directory database on that domain controller is corrupted.

The files, possibly including scripts or group policies, stored in the SYSVOL folder have been deleted or overwritten and need to be restored and replicated across the domain.

Before a domain controller can be booted into DSRM, the DSRM password is required. This password is configured when a system is promoted to a domain controller and is stored locally on each domain controller. The DSRM username is administrator with no domain designation, and the password can manually be changed on a working domain controller by using Ntdsutil. To restore the system state of a domain controller, follow these steps:

1. If the domain controller is still functional, log on to the Windows Server 2016 domain controller system with an account with domain administrator privileges.

2. Click the charms bar and select the Search option. In the Search pane, type in MSConfig and press Enter.

3. In the MSConfig.exe window (System Configuration Utility), select the Boot tab.

4. In the Boot Options section, check the Safe Boot check box, click the Active Directory Repair button, as shown in Figure 30.7, and then click OK.

5. The System Configuration utility will ask for a reboot, and if there are no additional tasks to perform, click the Restart button to boot the system into DSRM.

6. When the system completes a reboot, log on as administrator with the DSRM password. Make sure to specify the local server as the logon domain (e.g., DCadministrator instead of companyabcadministrator).

7. Open Server Manager from the taskbar, and from the Tools menu select Windows Server Backup.

8. When the Windows Server Backup window opens, select Local Backup in the tree pane.

9. Click Recover from the actions pane.

10. On the Getting Started page, select either to restore data previously backed up from the local computer or a different computer. For this example, select This Server (Servername), and click Next to continue.

11. On the Select Backup Data page, select the date of the backup by selecting the correct month and click the particular day.

12. After the month and day are selected, if multiple backups were run in a single day, click the Time drop-down list arrow, and select the correct backup. Click Next to continue after the month, day, and time are selected.

13. On the Select Recovery Type page, click the System-State button, and click Next to continue.

14. On the Select Location for System-State Recovery page, click the Original Location button. Do not check the Perform an Authoritative Restore of Active Directory Files box unless the SYSVOL folder and contents will be marked as the definitive/authoritative copy and replicated to all other domain controllers. For our example, we will recover the system state but not mark the SYSVOL as an authoritative restore, as shown in Figure 30.8. Click Next to continue.

15. A dialog box opens that states that this recovery option will cause the server to re-sychronize after recovery. Click OK to continue.

16. On the Confirmation page, verify that the system state is listed, and click Recover to start the system-state recovery of the domain controller.

17. A dialog box opens detailed that once the recovery is started it cannot be paused and a restart will be required to complete the recovery. Click Yes to start the recovery. System-state recovery can take a long time to complete, so be patient.

18. When the system-state restore completes, Windows Server Backup presents a dialog box with only a Restart button and no other option. Restart the server now.

19. When the server reboots, it reboots into DSRM again. Log on with the DSRM local username and password.

20. Once logged in, a wbadmin command prompt will open stating that the restore completed successfully. Close the command prompt window by pressing Enter.

21. Click the charms bar and select the Search option. In the Search pane, type in MSConfig and press Enter.

22. In the MSConfig.exe window (System Configuration Utility), select the Boot tab.

23. In the Boot Options section, uncheck the Safe Boot check box, and then click OK.

24. If an authoritative restore of Active Directory objects is not required, click the Restart button in the dialog box and allow the server to reboot normally. If an authoritative restore is required, click the Exit Without Restart button in the dialog box and perform the steps outlined in the following section, “Active Directory Authoritative Restore.”

1. Open a command prompt on the domain controller that is running in DSRM and has just completed a system-state recovery and a reboot.

2. In the command prompt window, type Ntdsutil and press Enter.

3. Type Activate Instance NTDS and press Enter.

4. Type in Authoritative Restore and press Enter.

5. To restore a single object, type Restore Object followed by the distinguished name of the previously deleted object. For example, to restore an object named Jamil Droubi in the Users container of the companyabc.com domain, type the following:

Click here to view code image

Restore Object "cn=Jamil Droubi,cn=users,
dc=companyabc,dc=com"

6. To restore a container or organizational unit and all objects beneath it, replace the “restore object” with “restore subtree,” followed by the appropriate distinguished name.

7. After the appropriate command is typed in, press Enter. A window opens asking for confirmation of the authoritative restore; click the Yes button to complete the authoritative restore of the object or subtree.

8. The Ntdsutil tool displays the name of the text file that may contain any back-links for objects just restored. Note the name of the files and whether any back-links were contained in the restored objects.

9. Type quit and press Enter; type quit again to close out of the Ntdsutil tool. Type exit to close the command prompt window.

10. Open the charms bar and select the Settings icon and click the Power button.

11. Choose to restart the server and select Operating System Recovery(Planned) as the reason, and then click Continue to restart the server into normal operation.

12. After normal reboot, verify the authoritatively restored object replicates to all domain controllers, and then perform a full backup of the domain controller.

Many technologies and solutions built in to Windows Server 2016 were covered in this chapter to provide you with useful recovery processes for Windows Server Backup or shadow copies to recover data and systems. Also covered were the tasks involved in creating the recovery plan, testing it, and making sure (through tested procedures) that what you think will happen in a recovery process actually can happen.

Document all 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.

Validate reported system failures before attempting to restore data or fix an issue.

Allocate the appropriate hardware devices, including servers with enough processing power and disk space to accommodate the restored machines’ resources.

Store a copy of all disaster recovery documentation and copies of dedicated Windows Server Backup disks at secure offsite locations.

Understand the dependencies of the applications and services to the operating system to choose whether to rebuild or restore from backup.

Identify and document special restore requirements for each server.

If an organization has not or cannot standardize on server hardware platforms or if systems will be used in production even when the hardware is at its end of life or the maintenance on a system has expired; consider moving critical physical systems to virtual servers.

When planning for recovery scenarios, ensure that a proper chain of communication is established to allow the technical staff to focus on their tasks and not be inundated with requests for status updates.