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
Resources
Costs
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
Databases
Database Availability Groups
Recipient Policies
Connectors
Global Catalog Placement
Groups
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
IPSec
Antivirus/Antispam/Antiphishing
Project Plan
Blackout Dates
Vacation Schedules
Additional Projects Overlap
Documentation Plan
Design
Plan
Build Guides
Migration Guides
Administration Guides
Maintenance Guides
As Builts
Disaster Recovery Guides
User Guides
Training Plan
Users
Administrators
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
| 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 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)
ForestPrep/DomainPrep
Rolling Migration
Gateway Migration
Special Considerations: Third-Party Add-Ins (Fax, Voicemail, Apps)
Rollback Planning
Backup and Restore
Phased Migration Rollback
Training
Users
Administrators
Communications
Status Meetings
Open Issues Log
Administration and Maintenance
Administration
Maintenance
Disaster Recovery
Guides
Periodic Schedules
Daily/Weekly/Monthly
Planned Downtime
Checklists
Test
Project Management
Phased Approach
Phase I—Design/Planning
Phase II—Prototype
Phase III—Pilot
Phase IV—Implement
Phase V—Support
Timelines
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
Scripting
Built-In
Third-Party
Building
Normalize Environment
Data Center First
Branch Offices Second
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
Migration Team
Technical Experts
Communications
Migration Team
Executives and Management
Administrators
Users
Methods
Frequency
Detail Level
Administration and Maintenance
Administration
Maintenance
Disaster Recovery
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.
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
Hardware
Software
Personnel
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
WINS
DHCP
IIS
Domain Controller
Exchange
Group Policy
New Settings
GPMC
RSoP
Antivirus
Password Policy
Security Templates
File Migration
Print Migration
DFS
Remote Assistance
UPS Software
Applications Testing
Exchange Server 2010
Exchange Install and Configuration
Exchange Migration
OWA
Functionality
Forms-Based Authentication
Individual Mailbox/Message Restores
Database Restore
Antivirus
Exchange Management Console
Functionality
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: | |
| Tester: | |
| | |
| Date: | |
| | |
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:
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.
