Windows Server 2008 R2 Unleashed (155 page)

devices permit configuration dumps to a text file that can be used in the overall documen-

tation, whereas others support web-based retrieval methods. In worst-case scenarios,

administrators must manually document the configurations.

Network device configurations, with possibly the exception of a firewall, rarely change. If

a change does occur, it should be documented in a change log and updated in the

network infrastructure documentation. This allows administrators to keep accurate records

of the environment and also provides a quick, documented way to rebuild the proper

configurations in case of a failure.

ptg

NOTE

Step-by-step procedures for rebuilding each network device are recommended. This

information can minimize downtime and administration.

Disaster Recovery Documentation

Creating and maintaining a disaster recovery plan for the Windows Server 2008 R2 infra-

structure requires the commitment of IT managers as well as the systems administrators in

charge of the messaging systems. This is because creating a disaster recovery plan is a

complex process and, after it is developed, the only way of maintaining it is by practicing

the procedures on a regular schedule. This will, of course, involve the administrative

personnel and should be worked into their scheduled tasks.

The initial steps of creating the DR plan will involve determining what the desired recov-

ery times are. Then, the team will move on to discuss possible disaster scenarios and map

out a plan for each one. The following table of contents outlines the different topics that

are addressed when creating the DR plan.

. Executive Summary or Introduction

. Disaster Recovery Scenarios

. Disaster Recovery Best Practices

. Planning and Designing for Disaster

786

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

. Business Continuity and Response

. Business Hours Response to Emergencies

. Recovery Team Members

. Recovery Team Responsibilities

. Damage Assessment

. Off-hours Response to an Emergency

. Recovery Team Responsibilities

. Recovery Strategy

. Coordinate Equipment Needs

. Disaster Recovery Decision Tree

. Software Recovery

. Hardware Recovery

. Server Disaster Recovery

. Preparation

ptg

. Documentation

. Software Management

. Knowledge Management

. Server Backup

. Client Software Configuration

. Restoring the Server

. Build the Server Hardware

. Post Restore

. Active Directory Disaster Recovery

. Disaster Recovery Service-Level Agreements

. Windows Server 2008 R2 Disaster Recovery Plan

. Complete RAID-5 Failure

. Complete RAID-1 Failure

. Complete System Failure

. NIC, RAID Controller Failures

. Train Personnel and Practice Disaster Recovery

Disaster Recovery Documentation

787

Every organization should go through the process of contemplating various disaster

scenarios. For instance, organizations on the West Coast might be more concerned with

earthquakes than those on the East Coast. Each disaster can pose a different threat.

Therefore, it’s important to determine every possible scenario and begin planning ways to

minimize those disasters.

22

Equally important is analyzing how downtime resulting from a disaster might affect the

company (reputation, time, productivity, expenses, loss in profit or revenue) and deter-

mine how much should be invested in remedies to avoid or minimize the effects.

A number of different components make up disaster recovery documentation. Without

this documentation, full recovery is difficult at best.

Disaster Recovery Planning

The first step of the disaster recovery process is to develop a formal disaster recovery plan.

This plan, while time consuming to develop, serves as a guide for the entire organization

in the event of an emergency. Disaster scenarios, such as power outages, hard drive fail-

ures, and even earthquakes, should be addressed. Although it is impossible to develop a

scenario for every potential disaster, it is still helpful to develop a plan to recover for

different levels of disaster. It is recommended that organizations encourage open discus-

ptg

sions of possible scenarios and the steps required to recover from each one. Include repre-

sentatives from each department because each department will have its own priorities in

the event of a disaster. The disaster recovery plan should encompass the organization as a

whole and focus on determining what it will take to resume normal business function

after a disaster.

Backup and Recovery Development

Another important component of a disaster recovery development process is the evalua-

tion of the organization’s current backup policies and procedures. Without sound backup

policies and procedures, a disaster recovery plan is useless. It is not possible to recover a

system if the backup is not valid.

Backup procedures encompass not only backing up data to tape or other media, but also a

variety of other tasks, including advanced system recovery, offsite storage, and retention.

These tasks should be carefully documented to accurately represent what backup method-

ologies are implemented and how they are carried out. Step-by-step procedures, guide-

lines, policies, and more can be documented.

Periodically, the backup documents should be reviewed and tested, especially after any

configuration changes. Otherwise, backup documents can become stale and can only add

more work and add to the problems during recovery attempts.

Recovery documentation complements backup documentation. This documentation

should include where the backup data resides and how to recover from various types of

failures (such as hard drive failure, system failure, and natural disaster). As with backup

788

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

documentation, recovery documentation can take the form of step-by-step guides, poli-

cies, frequently asked questions (FAQs), and checklists. Moreover, recovery documents

should be reviewed for validity and revised if necessary.

Monitoring and Performance Documentation

Monitoring is not typically considered a part of disaster recovery documentation.

However, alerting mechanisms can detect and bring attention to issues that might arise.

Alerting mechanisms can provide a proactive means to determining whether a disaster

might strike. Documenting alerting mechanisms and the actions to take when an alert is

received can reduce downtime and administration.

Windows System Failover Documentation

Organizations using failover technologies or techniques such as clustering or network load

balancing (NLB) can benefit from having documentation regarding failover. When a

system fails over, knowing the procedures to get the system back up and running quickly

can help you avoid unnecessary risk. These documented procedures must be thoroughly

tested and reviewed in a lab setting so that they accurately reflect the process to recover

each system.

ptg

Change Management Procedures

Changes to the environment occur all the time in an organization, yet often those

changes are either rarely documented or no set procedures are in place for making those

changes. IT personnel not responsible for the change might be oblivious to those changes,

and other administration or maintenance might be adversely affected.

Documented change management seeks to bring knowledge consistency throughout IT,

control when and how changes are made, and minimize disruption from incorrect or

unplanned changes. As a result, documenting change procedures should entail the

processes to request and approve changes, the high-level testing procedures, the actual

change procedures, and any rollback procedures in case problems arise.

Performance Documentation

Documenting performance-related information is a continuous process because of the

ever-changing metrics of business. This type of documentation begins by aligning with

the goals, existing policies, and service-level agreements (SLAs) for the organization. When

these areas are clearly defined and detailed, baseline performance values can be established

using System Monitor, System Center Operations Manager (SCOM), or third-party tools

(such as PerfMon and BMC Patrol). Performance baselines capture performance-related

metrics, such as how much memory is being used, the average processor utilization, and

more; they also illustrate how the Windows Server 2008 R2 environment is performing

under various workloads.

Routine Reporting

789

After the baseline performance values are documented and understood, the performance-

related information that the monitoring solution is still capturing should be analyzed peri-

odically. More specifically, pattern and trend analysis needs to be examined on a weekly

basis if not on a daily basis. This analysis can uncover current and potential bottlenecks

and proactively ensure that the system operates as efficiently and effectively as possible.

22

Baselining Records for Documentation Comparisons

Baselining is a process of recording the state of a Windows Server 2008 R2 system so that

any changes in its performance can be identified at a later date. Complete baselining also

pertains to the overall network performance, including WAN links, but in those cases it

might require special software and tools (such as sniffers) to record the information.

A Windows Server 2008 R2 system baseline document records the state of the server after

it is implemented in a production environment and can include statistics such as memory

use, paging, disk subsystem throughput, and more. This information then allows the

administrator or appropriate IT resource to determine at a later date how the system is

performing in comparison to its initial operation.

ptg

Routine Reporting

Although System Monitor can log performance data and provide reporting when used

with other products such as Microsoft Excel, it behooves administrators to use products

such as SCOM for monitoring and reporting functionality. For example, SCOM can

manage and monitor multiple systems and provide graphical reports with customizable

levels of detail.

Management-Level Reporting

Management-level reporting on performance data should be concise and direct but still at

a high level. Stakeholders don’t require an ample amount of performance data, but it’s

important to show trends, patterns, and any potential problem areas. This extremely

useful information provides a certain level of insight to management so that decisions can

be made as to what is required to keep the systems operating in top-notch condition. For

instance, administrators identify and report to management that, if current trends on

Windows Server 2008 R2 server processor utilization continue at the current rate of a 5%

increase per month, this will require additional processors in 10 months or less.

Management can then take this report, follow the issue more closely over the next few

months, and then determine whether to allocate funds to purchase additional processors.

If the decision is made to buy more processors, management has more time to negotiate

quantity, processing power, and cost instead of having to potentially pay higher costs for

the processors on short notice.

790

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

Technical Reporting

Technical performance information reporting is much more detailed than management-

level reporting. Details are given on many different components and facets of the system.

For example, many specific counter values can be given to determine disk subsystem

utilization. In addition, trend and pattern analysis should also be included to show histor-

ical information and determine how to plan for future requirements.

Security Documentation

Administrators can easily feel that documenting security settings and other configurations

is important but that this documentation might lessen security mechanisms in the

Windows Server 2008 R2 environment. Nevertheless, documenting security mechanisms

and corresponding configurations is vital to administration, maintenance, and any poten-

tial security compromise.

As with many of the documents about the network environment, they can do a lot of

good for someone either externally or internally trying to gain unauthorized access. So,

security documentation and many other forms of documentation, including network

diagrams, configurations, and more, should be well guarded to minimize any security risk.

ptg

Some areas regarding security that should be documented include, but aren’t limited to,

the following:

. Auditing policies including review

. Service packs (SPs) and hotfixes

. Certificates and certificates of authority

. Firewall and proxy configurations

. Antivirus configurations

. Access control policies, including NTFS-related permissions