Documenting an Exchange Server 2010 Environment : Exchange Server 2010 Project Documentation

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
3/14/2011 6:17:38 PM
An Exchange Server 2010 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 makes mapping out the tasks much easier. Also, the first round of mapping out a project will most likely have at most 15-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 an Exchange Server 2010 implementation:

  • Design and planning document

  • Communication plan document

  • Migration plan document

  • Training plan document

  • Prototype lab document

  • Pilot test document

  • Support and project completion document

This chapter examines each of these documents individually and focuses on their key elements.

Design and Planning Document

One of the concepts discussed earlier in the chapter was that of documents being used as building blocks. Continuing with that idea, the Exchange Server 2010 design and planning document is considered the foundation for all the documentation created from this point forward. The design and planning document takes the original business requirements, matches them to the technical specifications, and then maps out how to produce the end product. It cannot be stressed enough the importance of a well-developed design and planning document.

The Exchange Server 2010 design and planning document is the outcome of the design sessions held with the subject matter expert (SME) and the technical staff within the organization. A standard Exchange Server 2010 design and planning document contains the following information:

Executive Summary

Project Overview

Project Organization



Risk Assessment

Existing Environment

Network Infrastructure

Active Directory Infrastructure

Exchange Topology

Backup and Restore

Administrative Model

Client Systems

Exchange Server 2010 Environment

Goals and Objectives

Exchange Server 2010 Architecture

Server Placement

Exchange Version


Database Availability Groups

Recipient Policies


Global Catalog Placement


Hardware Configuration and Capacity Planning

Client Access and Hub Servers

Outlook Web App

Edge Services

Unified Messaging Services

Exchange Server 2010 Security

Exchange Roles and Advanced Security Delegation

Edge Security

Disabling Unnecessary Services/Protocols



Project Plan

Blackout Dates

Vacation Schedules

Additional Projects Overlap

Documentation Plan



Build Guides

Migration Guides

Administration Guides

Maintenance Guides

As Builts

Disaster Recovery Guides

User Guides

Training Plan



Migration Team

Communication Plan

Communication Plan Document

The detail of the communication plan depends on the size of the organization and management requirements. From the project management perspective, the more communication, the better! This is especially important when a project affects something as visible as the email system.

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 expectations. Once again, no surprises for the project team or the project sponsor.

A good communication plan should include the following topics:

  • Audience

  • Content

  • Delivery method

  • Timing and frequency

Table 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 1. Communication Plan
AudienceContent (Message)Delivery MethodTiming Stage/Frequency
Executive sponsorProject statusWritten reportWeekly in email
Project teamProject statusVerbal updatesWeekly in meeting
IT departmentProject overviewPresentationQuarterly meeting

Migration Plan Document

After the design and planning document has been mapped out, the project team can begin planning the logistics of implementing Exchange Server 2010. This document is a guide that contains the technical steps needed to implement Exchange Server 2010 from the ground up. However, depending on how the migration team is set up, it can also include logistical 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 might look similar to the following:

Goals and Objectives

Migration Planning—E2010

New Exchange Organization Versus Upgrade

Exchange 2010 Directory Cleanup/One-to-One Mapping

Migration Tools

Migration Using the AD Connector (ADC)


Rolling Migration

Gateway Migration

Special Considerations: Third-Party Add-Ins (Fax, Voicemail, Apps)

Rollback Planning

Backup and Restore

Phased Migration Rollback





Status Meetings

Open Issues Log

Administration and Maintenance



Disaster Recovery


Periodic Schedules


Planned Downtime



Project Management

Phased Approach

Phase I—Design/Planning

Phase II—Prototype

Phase III—Pilot

Phase IV—Implement

Phase V—Support


Resource Requirements

Risk Management

Interactive Refinement of Plan

Migration Planning—AD

In Place Versus Restructuring

Account Domains

Resource Domains

Active Directory Migration Tool (ADMT)

DNS Integration

Switching to Native Mode

Deployment Tools





Normalize Environment

Data Center First

Branch Offices Second

Deployment Strategies

Staged Versus Scripted Versus Manual




Build Guides

Migration Guides

Administration Guides

Maintenance Guides

As Builts

Disaster Recovery Guides

User Guides




Migration Team

Technical Experts


Migration Team

Executives and Management





Detail Level

Administration and Maintenance



Disaster Recovery


Periodic Schedules


Planned Downtime



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.

Training Plan Document

When creating a training plan for an Exchange Server 2010 implementation, the first thing that needs to be identified is the target audience. That determines what type of training needs to be developed. Some of the user groups that need to be targeted for training are as follows:

  • End users— If the implementation is going to change the desktop client, the end user must receive some level of training.

  • Systems administrators— The personnel involved in the administration of the messaging systems must be trained.

  • Help desk— In organizations where the support is divided among different teams, each team must 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 must be trained on the implementation process.

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 training to the organization’s unique Exchange 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 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 resources 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.

Prototype Lab Document

Going in to the prototype stage, experienced engineers and project managers are aware that the initial plan will probably have to be modified. This is because of a range of factors that can include application 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 contains a master test plan and provides the ability to document the test results for reference at a later date. This is necessary because the implementation procedures might change from the first round of testing to the next and the project team will need to refer to the outcome to compare results.

A prototype lab test plan outline contains the following:

Summary of What Is Being Tested and the Overall Technical Goals of the Implementation

Scope of What Will Be Tested

Resources Needed





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





Domain Controller


Group Policy

New Settings




Password Policy

Security Templates

File Migration

Print Migration


Remote Assistance

UPS Software

Applications Testing

Exchange Server 2010

Exchange Install and Configuration

Exchange Migration



Forms-Based Authentication

Individual Mailbox/Message Restores

Database Restore


Exchange Management Console


Backup and Restore

SCOM Agents

Administrative Rights

Each individual test should be documented in a test form listing the expected outcome and the actual outcome. This becomes part of the original test plan and is used to validate the implementation procedure or document a change.

A sample prototype lab test form is shown in Table 2.

Table 2. Sample Test Form
Test Name: 
Hardware Requirements: 
Software Requirements: 
Other Requirements: 
Expected Outcome: 
Actual Outcome: 
Test Name: 

At the end of the stage, it should be clearly documented what, if anything, has changed. The documentation deliverables of this stage are as follows:

  • Test plan

  • Implementation plan

  • Pilot implementation plan

  • Rollback plan

Pilot Test Document

Documenting a pilot implementation has special requirements because it is the first time the implementation will touch the production environment. If the environment is a complex one where multiple applications are affected by the implementation, all details should be documented along with the outcome of the pilot.

This is done by having a document similar in content to the prototype lab test plan form and tracking any issues that come up.

In extreme cases, the project team must put the rollback plan into effect. Before starting the pilot implementation, the team should have an escalation process, along with contact names and phone numbers of the personnel with the authority to make the go-no-go decision in a given situation.

Support and Project Completion Document

An Exchange implementation should include a plan for handing off administration to the personnel who will be supporting the messaging environment after the implementation is complete—especially if the SMEs are brought in to implement the Exchange messaging infrastructure and will not be remaining onsite to support it.

The handoff plan should be included in the original project plan and have a timeline for delivery of the administrative documentation, as well as training sessions if needed.

  •  Documenting an Exchange Server 2010 Environment : Benefits of Documentation
  •  Getting the Most Out of the Microsoft Outlook Client : Using Cached Exchange Mode for Offline Functionality
  •  UML Essentials - UML at a Glance
  •  Understanding Microsoft Exchange Server 2010
  •  Working with Email-Enabled Content in SharePoint 2010
  •  Enabling Incoming Email Functionality in SharePoint
  •  Getting the Most Out of the Microsoft Outlook Client : Using Outlook 2007 (part 3) - Using Group Schedules
  •  Getting the Most Out of the Microsoft Outlook Client : Using Outlook 2007 (part 2) - Sharing Information with Users Outside the Company
  •  Getting the Most Out of the Microsoft Outlook Client : Using Outlook 2007 (part 1)
  •  Implementing and Validating SharePoint 2010 Security : Using IPsec for Internal SharePoint Encryption
    Top 10
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
    - Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
    - Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    programming4us programming4us