Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
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
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.
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
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.
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