Windows Server 2008 R2 Unleashed (152 page)

. Historical/planning (who made which decision and how we will manage the project)

ptg

. Support and maintenance (to assist with maintaining the hardware and software on

the network)

. Policy (service-level agreements)

. Training (for end users or administrators)

It is important that any documentation produced be reviewed by other stakeholders in the

organization to make sure that it meets their needs as well, and to simply get input from

other sources. For technical procedures, the document must be tested and validated.

Ideally, the procedures are written by one resource and validated by one of the target

users, be it an end user or one of the administrators. With a review process of this sort, the

document will be more useful and more accurate. For example, a server build document

that has gone through this process is more likely to be complete and useful in the event

the server in question needs to be rebuilt in an emergency.

Documentation that is not historical and that is intended to be used for supporting the

network environment or to educate on company policies should be reviewed periodically

to make sure that it is still accurate and reflects current corporate policies and processes.

The discipline of creating effective documentation that satisfies the requirements of the

appropriate support personnel as well as management is also an asset to the company and

can have dramatic effects. The material in this chapter gives a sense of the range of differ-

ent documents that can have value to an organization and should help in the process of

deciding which ones are critical in the organization.

766

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

Planning to Document the Windows Server 2008

R2 Environment

When planning documentation (whether for general purposes, specific aspects such as

disaster recovery, or a particular project), several factors should be considered:

. The business requirements of the organization

. The technical requirements of the organization

. The audience that will be using the documents

. How and when the documents will be produced and maintained

The extent of the documentation depends on the business and technical requirements of

the organization. Some organizations require that each step be documented, and other

organizations require that only the configuration be recorded. Careful consideration

should be given to any regulatory requirements or existing internal organization policies.

After the specific documentation requirements have been determined, it is important to

consider who the audience for each document will be. Who will use each document, in

what setting, and for what purpose? It would be impractical to develop a 300-page user

guide when all the user wants to do is log on to the messaging system. In that case, all

ptg

that would be required is a quick reference guide. Properly analyzing the purpose and

goals of each document aids in the development of clear and useful documentation.

Planning the schedule for document production often requires a separate project timeline

or plan. The plan should include checkpoints, sponsorship or management review, and a

clear schedule. Tools such as Microsoft Project facilitate the creation of a documentation

project plan. The project plan can also provide an initial estimate of the number of hours

required and the associated costs. For instance, based on previous documentation projects,

there is an estimate that one to two pages per hour will be produced.

Knowledge Sharing and Knowledge Management

Knowledge sharing is about making the enterprise documentation available to the people

who are going to use it. The right documentation enables an organization to organize and

manage its data and intellectual property. Company policies and procedures are typically

located across multiple locations that include individual files for various departments.

Consolidating this information into logical groupings makes it easier to locate for day-to-

day usage as well as updating the documents in a timely manner.

TIP

Place documentation in at least two different locations where it is easily accessible for

authorized users, such as on the intranet, in a public folder, or in hard-copy format.

Also consider using a document management system such as Microsoft Office

SharePoint Server 2007.

Windows Server 2008 R2 Project Documents

767

A complete design document consolidates and summarizes key discussions and decisions,

budgetary concerns, and timing issues. This consolidation provides a single source of

information for questions that might emerge at a later date. In addition, a document that

describes the specific configuration details of the Windows server might prove very valu-

able to a manager in another company office when making a purchasing decision.

Knowledge management is about keeping the information contained in the documents

22

updated and relevant to the most current environment as well as archiving the historical

documentation. All of the documents should be readily available at all times. This is espe-

cially critical regarding disaster recovery documents. Centralizing the documentation and

communicating the location helps reduce the use of out-of-date documentation and

reduce confusion during disaster recovery. It is also recommended that documentation be

available in a number of formats, such as hard copy, the appropriate place on the network,

and even via an intranet.

TIP

Add review and updating of configuration and procedural documents into the recurring

maintenance tasks list. This will help keep the task at the forefront of the administra-

tor’s responsibilities and ensure the documents are up to date when the time comes

to use them.

ptg

Windows Server 2008 R2 Project Documents

A Windows Server 2008 R2 implementation is a complex endeavor that should be

approached in phases. First and foremost, a decision should be made on how the project

will be tracked. This can be done using a simple Microsoft Excel spreadsheet, but a tool

like Microsoft Project will make mapping out the tasks much easier. Also, the first round

of mapping out a project will most likely have at most 15 to 20 lines of tasks. Using a tool

like Microsoft Project makes it easier to fill in more line items as you progress in the

design and planning stages.

With the tracking method in place, you can move on to address the documents that are

typically created for a Windows Server 2008 R2 implementation:

. Project plan

. Design and planning document

. Communication plan

. Migration plan

. Training plan

. Test plan

768

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

. Pilot test plan

. Support and project completion document

This chapter discusses each of these documents individually and outlines their key elements.

Project Plan

A project plan is essential for more complex migrations and can be useful for managing

smaller projects, even single-server migrations. Tasks should be laid out in the order in

which they will occur and be roughly half-day durations or more because a project plan

that tries to track a project hour by hour can be overwhelmingly hard to keep up to date.

Tools such as Microsoft Project facilitate the creation of project plans and enable the

assignment of one or more resources per task and the assignment of durations and links to

key predecessors. The project plan can also provide an initial estimate of the number of

hours required from each resource and the associated costs if outside resources are to be

used. “What-if” scenarios are easy to create by simply adding resources to more complex

tasks or cutting out optional steps to see the effect on the budget.

NOTE

ptg

It’s a great idea to revisit the original project plan after everything is completed (the

baseline) to see how accurate it was. Many organizations fail to take this step and miss

the opportunity to learn from the planning process to better prepare for the next time.

Design and Planning Document

The first step in the implementation of the Windows Server 2008 R2 environment is the

development and approval of a design. Documenting this design contributes to the

success of the project. The design document records the decisions made during the design

process and provides a reference for testing, implementation, and support. The key

components to a design document include the following:

. The goals and objectives of the project

. The background or what led up to the design

. The approach that will be used to implement the solution

. The details of the end state of the project

Goals and objectives can be surprisingly hard to pin down. They need to be detailed

and concrete enough to define the results that you want while staying at a high level.

For instance, “reduce downtime” is too vague to be considered a functional goal,

whereas “implement server clustering with Windows Server 2008 R2 Enterprise Server to

reduce downtime to less than five minutes in the case of a single-server failure” is much

more specific.

Including the background of meetings and brainstorming sessions that led up to the deci-

sions for the end state of the project provides the groundwork for the detailed designs

Windows Server 2008 R2 Project Documents

769

provided later in the document. For example, a decision might have been made “because

the CEO wants it that way,” which affects the postmigration environment. Other deci-

sions might have come about after many hours of debates over the particulars and

required technical research to come up with the “right” answer. Recording this level of

information can be extremely useful in the future if performance issues are encountered or

additional changes to the network are being considered.

22

The description of the end state to be implemented can be very high level or can drill

down to more specific configurations of each server, depending on the document’s audi-

ence. However, it is recommended that the design document not include step-by-step

procedures or other details of how the process will be accomplished. This level of detail is

better handled, in most cases, in dedicated configuration or training documents as

discussed later in this chapter.

The Windows Server 2008 R2 design and planning document is the outcome of the design

sessions held with the subject matter expert (SME) and the technical staff within the orga-

nization. A standard Windows Server 2008 R2 design and planning document will contain

the following information:

. Executive Summary

. Project Overview

ptg

. Project Organization

. Resources

. Costs

. Risk Assessment

. Goals and Objectives

. Active Directory Architecture

. Design

. Domain Design

. Placeholder Root

. Namespace

. Organizational Unit Design

. Group Design

. Site Design

. Group Policy Design

. Mixed Mode Versus Native Mode

. AD Services Design

. Domain Controller (DC) Placement

. Global Catalog (GC) Placement

770

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

. DNS, DDNS, and Integration

. Platform Selection and Alternatives

. Autosite Coverage

. WINS Placement

. Flexible Single Master Operations (FSMO) Role Placement

. DC Sizing

. Client Performance

. Service-Level Agreements

. Replication Topology

. Site Link Topology

. Site Link Bridges

. Costs

. Cost Formula = 1024/log (bw)

. Schedule

ptg

. Latency/Convergence Time

. Traffic

. Transport: IP/RPC Versus SMTP

. Knowledge Consistency Checker (KCC) and Complexity Equation

. Connection Creation—Automatic Versus Scripted Versus Manual

. Active Directory Database Sizing

. Domain Database

. Global Catalog

. Attributes

. Exchange 2007/2010 Extensions

. Security Model

. Groups

. Administrators

. Domain Administrators

. Schema Administrators

. Enterprise Administrators

. DNS Administrators

Windows Server 2008 R2 Project Documents

771

. Administrative Model

. Delegation

. Group Policy

. Default Domain

22

. Default Domain Controller

. Security Templates

. Directory Integration

. Existing Windows Environments

. LDAP

. NDS

. AD

. Application Integration

. Desktop Clients

. Existing Windows Clients

ptg

. UNIX

. Apple Mac

. PDAs

. Group Policy and Lockdown

. Group Policy Application

. Templates

Communication Plan

The detail of the communication plan depends on the size of the organization and

management requirements. From the project management perspective, the more commu-