Windows Server 2008 R2 Unleashed (153 page)

nication the better! This is especially important when a project touches all aspects of the

server environment.

Mapping out the how, when, and who to communicate with allows the project team to

prepare well-thought-out reports and plan productive meetings and presentations. This also

provides the recipients of the reports the chance to review the plan and set their expecta-

tions. Once again, there are no surprises for the project team or the project sponsors.

A good communication plan should include the following topics:

. Audience

. Content

772

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

. Delivery method

. Timing and frequency

Table 22.1 gives an example of a communication plan. To make the plan more detailed,

columns can be added to list who is responsible for the communication and specific dates

for when the communication is delivered.

TABLE 22.1

Communication Plan

Audience

Content (Message)

Delivery Method

Timing

Stage/Frequency

Executive sponsor

Project status

Written report

Weekly in email

Project team

Project status

Verbal updates

Weekly in meeting

IT department

Project overview

Presentation

Quarterly meeting

Migration Plan

After the design and planning document has been mapped out, the project team can

ptg

begin planning the logistics of implementing Windows Server 2008 R2. This document

will be a guide that contains the technical steps needed to implement Windows Server

2008 R2 from the ground up. This document will go into great detail on the specific steps

for migration. Depending on how the migration team is set up, it might also include logis-

tical instructions, such as the following:

. Communication templates

. Location maps

. Team roles and responsibilities during the implementation

In a large organization, a session or sessions will be held to develop the migration plan.

An agenda for the development of the plan will look something like this:

. Goals and Objectives

. Project Management

. Phase I—Design/Planning

. Phase II—Prototype

. Phase III—Pilot

. Phase IV—Implement

. Phase V—Support

. Timeline

. Resource Requirements

Windows Server 2008 R2 Project Documents

773

. Risk Management

. Iterative Refinement of Plan

. Migration Planning—Active Directory

. In-Place Versus Restructuring

22

. Account Domains

. Resource Domains

. Active Directory Migration Tool (ADMT)

. DNS Integration

. Deployment Tools

. Scripting

. Built-in

. Third-party

. Building

. Normalize Environment

ptg

. Data Center First

. Deployment Strategies

. Staged Versus Scripted Versus Manual

. Documentation

. Design

. Plan

. Build Guides

. Migration Guides

. Administration Guides

. Maintenance Guides

. As Builts

. Disaster Recovery Guides

. User Guides

. Training

. Users

. Administrators

774

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

. Migration Team

. Technical Experts

. Communications

. Migration Team

. Executives and Management

. Administrators

. Users

. Methods

. Frequency

. Detail Level

. Administration and Maintenance

. Administration

. Maintenance

. Disaster Recovery

ptg

. Guides

. Periodic Schedules

. Daily/Weekly/Monthly

. Planned Downtime

. Checklists

. Testing

Note that many of the agenda topics are stated in a way that facilitates discussion. This is

a great way to organize discussion points and at the same time keep them on track.

NOTE

The results of testing the design in a prototype or pilot might alter the actual migration

steps and procedures. In this case, the migration plan document should be modified to

take these changes into account.

Server Migration Procedures

High-level migration procedures should be decided on during a design and planning

process and confirmed during a prototype/testing phase. The initial migration document

also should focus on the tools that will be used to migrate data, users, and applications, as

well as the division of labor for these processes.

Windows Server 2008 R2 Project Documents

775

A draft of the document can be put together, and when the process is tested again, it can

be verified for accuracy. When complete, this information can save you a great deal of

time if a number of servers need to be migrated.

TIP

22

Server migration procedures should be written in such a way so that even less-experi-

enced staff members can use the procedures for the actual migrations.

The procedures covered can include the following:

. Server hardware configuration details

. Windows Server 2008 R2 version for each server

. Service pack (SP) and hotfixes to install on each server

. Services (such as DNS and DHCP) to enable or disable and appropriate settings

. Applications (such as antivirus and SQL Server) to install and appropriate settings

. Security settings

ptg

. Steps required to migrate services and data to the new server(s)

. Steps required to test the new configuration to ensure full functionality

. Steps required to remove old servers from production

Desktop Migration Procedures

As with the documented server migration process, the desktop migration process should be

discussed in the design and planning phase and documented in the migration document.

In some migrations, the changes might be minimal, whereas other migrations might

require dramatic upgrades. For instance, a desktop machine might qualify for an in-place

upgrade to Windows 7, whereas another might require hardware or system replacement.

What specifically is documented will vary among organizations; however, the recom-

mended areas to consider documenting are as follows:

. Hardware inventory

. Installation method(s), such as Remote Installation Services, third-party imaging

software, and network-based installations

. Base installation applications

. Security configuration

. Templates being used

. Language options

. Accessibility considerations

776

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

User Migration Procedures

Users and their related information (username, password, and contact information) in

other systems or directories need to be migrated to take advantage of Windows Server

2008 R2. The procedures to migrate the users should be examined during the design and

planning phases of the project.

User information can exist in many different places such as an Active Directory (AD)

domain, an application, and more. The user information might be inconsistent depending

on where it exists and how it is stored. Procedures should be documented for migrating

the user information from each different location. For example, if some users will be

migrated from another operating system or from multiple forests, separate procedures

should be documented for each process.

Another scenario to document is the migration of user profiles and desktops. Although

some of this information might be redundant with desktop migration scenarios, it is

nonetheless important to capture the procedures for making sure that, when clients log on

after the migration, all their settings still exist and they won’t have any problems with the

applications they use. This is a very important consideration for mobile users. For

instance, will mobile users need to come back into the office to have settings changed or

migrated? Will these changes be performed the next time they log on?

ptg

Checklists

The migration process can often be a long process, based on the amount of data that

must be migrated. It is very helpful to develop both high-level and detailed checklists to

guide the migration process. High-level checklists determine the status of the migration

at any given point in the process. Detailed checklists ensure that all steps are performed

in a consistent manner. This is extremely important if the process is being repeated for

multiple sites.

Training Plan

When creating a training plan for a Windows Server 2008 R2 implementation, the first

thing that needs to be identified is the target audience. That will determine what type of

training needs to be developed. Some of the user groups that need to be targeted for train-

ing are as follows:

.
End users—
If the implementation is going to change the desktop client, the end

user will have to receive some level of training.

.
Systems administrators—
The personnel involved in the administration of the

messaging systems will need to be trained.

.
Help desk—
In organizations where the support is divided among different teams,

each one will have to be trained on the tasks they will be carrying out.

.
Implementation team—
If the implementation is spread across multiple locations,

some project teams choose to create implementation teams. These teams will need

to be trained on the implementation process.

Windows Server 2008 R2 Project Documents

777

After the different groups have been identified, the training plan for each one can be

created. The advantage of creating a training plan in-house is the ability to tailor the train-

ing to the organization’s unique Windows environment. The trainees will not have to go

over configurations or settings that do not apply to their network.

As a special note, if the systems administrators and implementation team members can be

22

identified ahead of time, it is wise to have them participate in the prototype stage.

The implementation team can assist by validating procedures and, through the repetitive

process, can become more familiar with the procedures. After the prototype environment

is set up, administrators and help desk personnel can come in to do the same for the

administrative procedures.

This provides the necessary validation process and also allows the systems groups to

become more comfortable with the new tools and technology.

Test Plan

Thorough testing is critical in the success of any implementation project. A test plan

details the resources required for testing (hardware, software, and lab personnel), the tests

or procedures to perform, and the purpose of the test or procedure.

It is important to include representatives of every aspect of the network in the develop-

ptg

ment of the test plan. This ensures that all aspects of the Windows Server 2008 R2 envi-

ronment or project and its impact will be included in the test plan.

Prototype Test Plan

Going in to the prototype stage, experienced engineers and project managers are aware

that the initial plan will probably have to be modified because of reasons such as applica-

tion incompatibility, administrative requirements, or undocumented aspects of the current

environment.

So, if it was important to start out this stage with a well-documented plan, the most

important documentation goal for the prototype is to track these changes to ensure that

the project still meets all goals and objectives of the implementation.

The document tool the project team will use to do this is the test plan. A well-developed

test plan will contain a master test plan and provide the ability to document the test

results for reference at a later date. This is necessary because the implementation proce-

dures will likely have changes from the first round of testing to the next and the project

team will need to refer to the outcome to compare results.

A test plan outline will contain the following:

. Summary of what is being tested and the overall technical goals of the implementation

. Scope of what will be tested

. Resources Needed

. Hardware

. Software

. Personnel

778

CHAPTER 22

Documenting a Windows Server 2008 R2 Environment

. Documentation

. What will be recorded

. Test Plan Outline

. Operating System

. Hardware Compatibility

. Install First Domain Controller

. Test Replication

. Install Additional Domain Controllers

. Client Access

. Role-Based Configuration

. DNS

. DHCP

. IIS

. Domain Controller

ptg

. Exchange

. Group Policy

. New Settings

. Group Policy Management Console

. Resultant Set of Policies

. Antivirus

. Password Policy

. Security Templates

. File Migration

. Print Migration

. Distributed File System

. Volume Shadow Copy