Planning Phase: Creating the Design Document

When the initial discovery work is complete, attention can be turned to the Design document itself, which paints a detailed picture of the end-state of the network upgrade. In essence, this document expands on the Statement of Work document and summarizes the process that was followed and the decisions that were made along the way.

The second key deliverable in the planning phase is the Migration document, which tells the story of how the end-state will be reached. Typically, these documents are separate, because the Design document gives the "what" and "why" information, and the Migration document gives the "how" and "when" information.

Collaboration Sessions: Making the Design Decisions

The planning phase kicked off with discovery efforts and review of the networking environment, and additional meetings with the stakeholders and the Project Team should be scheduled for collaborative discussions. This process covers the new features that Exchange Server 2003 offers and how these could be beneficial to the organization as a whole and to specific departments or key users. Typically, several half-day sessions are required to discuss the new features and whether implementing them makes sense.

Ideally, quite a bit of thought has already gone into what the end-state will look like, as reflected in the Statement of Work document, so everyone attending these sessions will be on the same page in terms of goals and expectations for the project. If they aren't, this is the time to resolve differing opinions , because the Design document is the blueprint for the results of the messaging upgrade.

The collaborative sessions should be led by a consultant with hands-on experience in designing and implementing Exchange Server 2003 solutions. Agendas should be provided in advance to keep the sessions on track (see Figure 2.1 for a sample agenda) and enable attendees to prepare specific questions. A technical writer should be invited to take notes and start to become familiar with the project as a whole, because that individual will most likely be active in creating the Design document and additional documents required.

Figure 2.1. Sample Exchange Server 2003 design agenda.

The specifics of the upgrade should be discussed in depth, especially the role that each server will play in the upgrade. A diagram is typically created during this process (or an existing Visio diagram updated) that defines the locations and roles of all Exchange 2003 Servers and any legacy Exchange Servers that need to be kept in place.

The migration process should be discussed as well, although often organizations prefer to discuss the minutiae of the migration after the Design document has been completed. Why spend hours discussing how to get to end-state A when the budget ends up being too high, and a design B needs to be crafted?

Disaster Recovery Options

A full disaster recovery assessment is most likely out of the scope of the messaging upgrade project, but the topic should be covered at this phase in the project.

Most people would agree that the average organization would be severely affected if the messaging environment were to go offline for an extended period of time. Communications between employees would have to be in person or over the phone, document sharing would be more complex, communication with clients would be affected, and productivity of the remote work force would suffer. Employees in the field rarely carry pagers any more, and some have even discarded their cell phones, so many employees would be hard to reach. This dependence on messaging makes it critical to adequately cover the topic of disaster recovery as it pertains to the Exchange messaging environment.

Existing service level agreements (SLAs) should be reviewed and input gathered on the "real" level of disaster recovery planning and testing that has been completed. Few companies have spent the necessary time and energy to create plans of action for the different failures that could take place, such as power failures in one or more locations, Exchange database corruptions, or server failures. A complete disaster recovery plan should include offsite data and application access as well.

Design Document Structure

The Design document expands on the content created for the Statement of Work document defined previously, but goes into greater detail and provides historical information on the decisions that were made. This is helpful if questions come up later in the testing or implementation process, such as "Whose idea was that?" or "Why did we make that decision?"

The following is a sample table of contents for the Exchange Server 2003 Design document:

1. Executive Summary

2. Goals and Objectives

   • Business Objectives

   • Departmental Goals

3. Background

   • Overview of Process

   • Summary of Discovery Process

4. Exchange Design

   • Exchange 2000 Design Diagram

   • Exchange Mailbox Server Placement (where do they go)

   • Organization (definition of and number of Exchange Organizations)

   • Administrative Groups (definition of and number of)

   • Routing Groups (definition of and number of)

   • Storage Groups (definition of and number of)

   • Mixed Mode Versus Native Mode (choice and decision)

   • Global Catalog Placement (definition and placement)

   • Recipient Policies (definition and usage)

   • Front-end and Bridgehead Servers (definition and usage, includes remote access)

   • Server Specifications (recommendations and decisions, role for each server defined, redundancy, disaster recovery options discussed)

   • Virus Protection (selected product with configuration)

   • Administrative Model (options defined, and decisions made for level of administration permitted by administrative group )

   • System Policies (definition and decisions on which policies will be used)

   • Exchange Monitoring (product selection and features described)

   • Exchange Backup/Recovery (product selection and features described)

5. Budget Estimate

   • Hardware and Software Estimate

Executive Summary

The Executive Summary should summarize the high-level solution for the reader in under one page by expanding upon the scope created previously. The importance of the testing phase can be explained and the budget summarized.

Design Goals and Objectives

Goals and objectives have been discussed earlier in this chapter and should be distilled down to the most important and universal goals. They can be broken down by department if needed. The goals and objectives listed can be used as a checklist of sign-off criteria for the project. The project is complete and successful when the goals are all met.

Background

In the background section, the material gathered in the discovery portion of the planning phase should be included in summary form (details can always be attached as appendixes); also helpful is a brief narrative of the process the project team followed to assemble this document and make the decisions summarized in the design portion of the document.

Design

The design section defines how the Exchange Server 2003 environment will be configured. Exchange Server 2003 was designed to be extremely flexible in how it can be added to the network. In Figure 2.2, the possibilities are listed for Exchange 5.5, Exchange 2000, Exchange Server 2003, Windows NT, Windows 2000, and Windows Server 2003. This flexibility can be very important if there are third-party applications used to extend the functionality of the current version of Exchange that are not available for Exchange Server 2003 or that have been written specifically for a previous version of Exchange or to control the costs of the overall upgrade. For instance, a unified messaging solution currently in place on Exchange 2000 could simply be left as is while the rest of the messaging environment is upgraded to Exchange Server 2003.

Figure 2.2. Exchange and Windows server coexistence.

NOTE

Note also that Exchange 5.5 and 2000 cannot run directly on servers running Windows 2003 Server; they can, however, operate in a Windows Server 2003 Active Directory environment.

Additional information on the options for coexistence of different Windows Server Operating Systems and Exchange Server versions is covered in Part II, "Microsoft Exchange Server 2003 Messaging."

Technical Advantages of Exchange Server 2003 Running on WS2003

Exchange Server 2003 can run on Windows 2000 and Windows Server 2003, but the latter provides a number of technical advantages. Note that Exchange Server 2003 cannot be run on Windows Server 2003 Web Edition.

Using Exchange Server 2003 with Windows Server 2003 provides memory tuning, database snapshot through Volume Shadow Copy Services (VSS), secured HTTP support for Outlook 2003, OWA compression support, IPSec support between front-end and back-end clusters, object quotas, and SID filtering. If Windows Server 2003 Enterprise is the platform, there is support for up to 8-way PIII or P4 processors, and up to 8-node clustering.

If the Enterprise version of Exchange Server 2003 is used, the 16GB database limit is removed; instead of 1 mailbox store, there can be up to 20 databases per server.

Future chapters cover these topics in greater detail, especially in Parts III, "Microsoft Networking Services' Impact on Exchange"; IV, "Securing a Microsoft Exchange Server 2003 Environment"; VI, "Microsoft Exchange Server 2003 Administration and Management"; VII, "New Mobility Functionality in Microsoft Exchange Server 2003"; and X, "Fault Tolerance and Optimization Technologies."

Agreeing on the Design

When the document is complete, it should be presented to the project stakeholders and reviewed to make sure that it fully meets their requirements, and to see whether any additional concerns come up. If there were significant changes since the initiation phase's Statement of Work document, they should be highlighted and reviewed at this point. Again, it is valuable in terms of time and effort to identify any issues at this stage in the project, especially when the Migration document still needs to be created.

Some organizations choose to use the Design document to get competitive proposals from service providers, and having this information levels the playing field and results in proposals that promise the same end results.