Windows Server 2008 R2 Unleashed (250 page)

is now enabled.

9. If necessary, select the next volume and enable shadow copying; otherwise, select

the enabled volume and immediately create a shadow copy by clicking the Create

Now button.

10. If necessary, select the next volume and immediately create a shadow copy by click-

ing the Create Now button.

ptg

11. After the shadow copies are created, click OK to close the Shadow Copies page, close

the Server Manager, and log off of the server.

To learn how to recover lost or overwritten data using Shadow Copies for Shared Folders,

refer to Chapter 31.

Windows Server 2008 R2 Startup Options

When a Windows Server 2008 R2 system has startup issues, a few different startup options

can be used to troubleshoot the problem. On every server, when the boot loader is shown,

the administrator can press the F8 key to list several boot configurations, including Safe

mode to load only the core drivers and applications. The different options can be used to

disable or change a suspected driver or application that is causing normal system startup

to fail. The different startup options are detailed in Chapter 31.

Emergency Management Services Console Redirection

Windows Server 2008 R2 enables administrators to remotely manage or troubleshoot a

system when normal operating system functionality is not available. Using out-of-band

connections, such as a serial COM port, information can be redirected to other servers to

resolve startup or operating system problems. Emergency Management Services (EMS) can

be used when physical access to a server is not available and remote administrative

options through network connections are not working properly.

Best Practices

1265

Some hardware requirements must be met before Emergency Management Services

console redirection can be used. For example, the system motherboard BIOS must support

Serial Port Console Redirection (SPCR). Emergency Management Services is enabled and

installed on servers during operating system installation if the motherboard supports

SPCR. To enable and configure EMS on existing Windows Server 2008 R2 systems, use the

bcdedit.exe utility.

Refer to the Windows Server 2008 R2 Help and Support documentation for the specific

switches and settings for Bcdedit.

Summary

When it comes to disaster recovery planning and backing up Windows Server 2008 R2

systems, there are many options to consider. Specialized utilities can be leveraged for

specific backup tasks, but for complete server backup, the graphic and command-line utili-

ties of Windows Server Backup take care of all of the Windows Server 2008 R2 role services

requirements. Third-party applications might require additional backup programs or tasks

to be backed up properly.

ptg

Best Practices

The following are best practices from this chapter:

. Make sure that disaster recovery planning includes considerations for the physical

site, power, entire system failure, server component failure, and software corruption.

. Identify the different services and technologies, points of failure, and critical areas;

then prioritize in order of importance.

. Make sure that the disaster recovery solution contains costs associated with addi-

tional hardware, complex configurations, and a service-level agreement estimating

how long it will take to recover the service should a failure occur. Different options

should also be presented.

. Document the server configuration for any environment, regardless of size, number

of servers, or disaster recovery budget.

. Verify that any backup disks or remote server shares used to store backups are both

physically secure and secured by NTFS and share permissions to reduce the risk of

30

compromising or losing company data.

This page intentionally left blank

ptg

CHAPTER 31

IN THIS CHAPTER

Recovering from a
. Ongoing Backup and Recovery

Preparedness

Disaster
. When Disasters Strike

. Disaster Scenario

Troubleshooting

. Recovering from a Server or

System Failure

When organizations need to recover data or restore busi-

. Managing and Accessing

ness services and operations after a disruption in business

Windows Server Backup Media

operations, having a well-formulated and validated recovery

. Windows Server Backup

plan is vital to success. This requires a disciplined process of

Volume Recovery

creating and maintaining backup and recovery procedures

and documentation, as well as periodically validating the

. Recovering Role Services and

Features

recovery tasks by simulating different failure scenarios and

recovering data and applications.

ptg

In addition to having a disaster recovery plan, many organi-

zations—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 asso-

ciated with proposed changes to current business systems,

services, applications, and operational processes.

This chapter, as a complement to Chapter 30, “Backing Up

the Windows Server 2008 R2 Environment,” details how to

recover a Windows Server 2008 R2 environment using

Windows Server Backup after a failure or disaster has

occurred. In addition to system recovery, this chapter also

provides some best practices and ideas organizations should

consider when planning how to support and restore opera-

tion to the computer and network infrastructure when

system failures and disasters occur.

Ongoing Backup and Recovery

Preparedness

Creating and documenting processes that detail how to

properly back up and recover from a disaster is an essential

step in a disaster recovery project. Equally important as

1268

CHAPTER 31

Recovering from a Disaster

creating these processes is periodically reviewing, validating, and updating the processes.

Disaster recovery planning should not be considered a project for the current calendar

year; instead, it should be considered an essential part of regular business operations and

should have dedicated annual budget and assigned staff.

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 organiza-

tions 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 a change-control committee to review and oversee organizational

projects and infrastructure changes.

ptg

Project Management Office (PMO)

In recent years, many organizations have introduced Project Management Offices (PMOs)

into their business operations. A PMO is used to provide somewhat of a project oversight

committee to organizations that frequently operate several projects simultaneously.

Organizations that utilize a proven project methodology can further extend this method-

ology to include workflow processes that include checkpoints with the PMO staff.

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 deter-

mine 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 organiza-

tions. 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 organiza-

tion 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 nega-

tively affect the organization as a whole. Some of the 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 organiza-

tion and how they align to business and technical objectives.

Ongoing Backup and Recovery Preparedness

1269

.
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

31

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 post-

poned.

.
Enterprise project management—
The PMO tracks the status of all ongoing pro-

jects 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 Control

Whereas a PMO improves project management and can provide the necessary checkpoints

to verify that backup and recovery requirements are addressed within the new projects, an

ptg

organization with a change-control system can ensure that any proposed changes have

been carefully evaluated and scheduled before approval or change execution. Change

control involves a submittal, review, and approval process for each change that typically

includes the following information:

.
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 com-

municating the status and results of the change back to the change-control commit-

tee.

A change-control committee, similar to a PMO, is made 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

1270

CHAPTER 31

Recovering from a Disaster

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, post-

poned, 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, emer-

gency 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