Planning Phase: Discovery
The planning phase enables the Exchange Server 2010 design consultant time to paint the detailed picture of what the end state of the upgrade will look like, and also to detail exactly how the network will evolve to this new state. The goals of the project are clear, what's in and what's out are documented, the resources required are defined, the timeline for the planning phase and an initial sketch of the risks are anticipated, and the budget is estimated.
Understanding the Existing Environment
If an organization has multiple Exchange servers in place, third-party add-on applications, multiple sites, complex remote access, or regulatory security requirements, it makes sense to perform a full network audit. If an outside company is spearheading the planning phase, this is its first real look at the configuration of the existing hardware and network, and it is essential to help create an appropriate end state and migration process. Standard questionnaires are helpful to collect data on the different servers that will be affected by the upgrade. Typically, these questionnaires are sent to the groups that manage the Exchange Server-related systems in various locations as they generally have the best information on those systems, including any issues or "quirks" they might have.
The discovery process typically starts with onsite interviews with the IT resources responsible for the different areas of the network and proceeds with a hands-on review of the network configuration. Focus groups or white boarding sessions can also help dredge up concerns or issues that might not have been shared previously. External consultants often generate better results because they have extensive experience with network reviews and analysis and with predicting the problems that can emerge midway through a project. Consider holding at least some of the interview sessions with only specific groups present. Sometimes, some groups don't want to bring up specific issues with other groups present.
Network performance can be assessed at the same time to predict the level of performance the end users will see and whether they are accessing email, public folders, or calendars from within the company, from home, or from an Internet kiosk in an airport. This is also a great time to get a baseline of system performance and bandwidth consumption. Having this baseline is very important and allows you to accurately rate the new environment. It can be very hard to deal with comments of "the new environment seems slower" if you have no previous performance data to compare it with.
Existing network security policies might be affected by the upgrade, and should be reviewed. If AD is being implemented, group policies -- which define user and computer configurations and provide the ability to centralize logon scripts and printer access -- can be leveraged.
Anyone using Exchange Server is familiar with the challenges of effectively managing the data that builds up, and in grooming and maintaining these databases. The existing data-base structure should be reviewed at least briefly so the Exchange Server 2010 design consultant understands where the databases reside, how many there are and their respective sizes, and whether regular maintenance has been performed. Serious issues with the database(s) crashing in the past should be covered. Methods of backing up this data should also be reviewed.
Desktop configurations should be reviewed if the upgrade involves an upgrade to the Outlook client. If there are a variety of different desktop configurations, operating systems, and models, the testing phase might need to expand to include these.
Disaster recovery plans or SLAs can be vital to the IT department's ability to meet the needs of the user community, and should be available for review at this time.
Remote and mobile connections to the messaging system should be reviewed in this phase as OWA is used by most organizations, as well as Terminal Services, or virtual private networks (VPNs). The features in Exchange Server 2010 might enable the organization to simplify this process; VPNs might not be needed if the design allows Outlook to be accessed via Hypertext Transfer Protocol Secure (HTTPS).
Although the amount of time required for this discovery process varies greatly, the goals are to fully understand the messaging infrastructure in place as the foundation on which the upgrade will be built. New information might come to light in this process that will require modifications to the Statement of Work document. Always review the initial documentation at the end of a phase so that any changes can be fed back into the processes, and you can determine if any tests need to be repeated as a result of the changes.
Understanding the Geographic Distribution of Resources
If network diagrams exist, they should be reviewed to make sure they are up to date and contain enough information (such as server names, roles, applications managed, switches, routers, firewalls, IP address information, gateways, and so forth) to fully define the location and function of each device that plays a role in the upgrade. These diagrams can then be modified to show the end state of the project. Also critical to these network diagrams is an understanding of not only the bandwidth rating of the connection, but also the average utilization. Connection latency is also a useful piece of information because improvements in Outlook 2007 and Exchange Server 2010 might allow you to use configurations that were previously unavailable to you because of high latency on a WAN connection. On the flip side of this, many of the new technologies in Exchange Server 2010 will encourage administrators to replicate more mailbox data than ever before. This can create a noticeable increase in bandwidth requirements for Exchange Server.
Existing utility servers -- such as bridgehead servers, front-end servers, domain name system (DNS) naming servers, and Dynamic Host Configuration Protocol (DHCP) or Windows Internet Naming Service (WINS) servers -- should be listed in these diagrams as well.
Has connectivity failure been planned for a partial or fully meshed environment? Connections to the outside world and other organizations need to be reviewed and fully understood at the same level, especially with an eye toward the existing security features. If this is an area that can be improved in the new Exchange Server 2010 design, be sure to track this as a goal of the project.
Companies with multiple sites bring added challenges to the table. As much as possible, the same level of information should be gathered on all the sites that will be involved in and affected by the messaging upgrade. Also, a centralized IT environment has different requirements from a distributed management model. It's important to fully understand these aspects of the environment to successfully plan for your upgrade.
If time permits, the number of support personnel in each location should be taken into account, as well as their ability to support the new environment. Some smaller sites might not have dedicated support staff and network monitoring, and management tools, such as System Center Operations Manager or System Center Configuration Manager might be required.
How is directory information replicated between sites, and what domain design is in place? If the company already has Active Directory in place, is a single domain with a simple organizational unit (OU) structure in place, or are there multiple domains with a complex OU structure? Global catalog placement should also be clarified. Did the existing Exchange Server environment span multiple administrative groups? Who managed what functions in each administrative group? Is this administrative model going to change in the new Exchange Server 2010 environment?
The answers to these questions directly shape the design of the solution, the testing phase, and the implementation process. Keep in mind that each decision made in the planning phase needs to support the original goals and objectives of the project. When in doubt, always return to these goals and ask yourself if a particular decision is in line with those goals.
Planning Phase: Creating the Design Document
When the initial discovery work is complete, you can turn your attention to the Design document itself, which paints a detailed picture of the end state of the messaging system 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. When possible, include a little information on what the options were and why a particular decision was made. This helps other people to understand why decisions were made if they were not directly involved in the design process.
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. This is a good example of writing documents slightly differently based on who the audience will be.
Collaboration Sessions: Making the Design Decisions
Just as the planning phase kicked off with discovery efforts and review of the networking environment, the design phase will start with more meetings with the stakeholders and the project team for collaborative design discussions. This process covers the new features that Exchange Server 2010 offers and how these could be beneficial to the organization as a whole and to specific departments or key users in support of the already defined goals. Typically, several half-day sessions are required to discuss the new features and whether implementing them makes sense. Try to leave a bit of time between sessions to give participants a chance to let the information sink in and make sure there won't be any unintended side effects of a given decision.
By this point in the process, quite a bit of thought has already gone into what the end state will look like, and that is reflected in the Statement of Work document. This means that everyone attending these sessions should 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 plan of record for the results of the messaging upgrade.
The collaborative sessions should be led by someone with hands-on experience in designing and implementing Exchange Server 2010 solutions. This might be an in-house expert or it might be an external consultant. Agendas should be provided in advance to keep the sessions on track and enable attendees to prepare for 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.
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 Server 2010 servers and any legacy Exchange servers that need to be kept in place. This includes plans for the number of mailbox servers, the number of client access servers needed to support the remote users, the placement of Edge Transport servers to allow for redundancy, and the placement of Hub Transport servers to ensure that mail can be routed efficiently.
The migration process should be discussed as well because it is likely to have the largest impact on the end users. This is the time to account for overlapping projects that might impact your Exchange Server 2010 rollout. Also pay careful attention to the availability of the resources you defined previously. You don't want any surprises, such as having your Exchange Server 2010 expert on vacation during the critical phases of your migration.
Disaster Recovery Options
Although a full disaster recovery assessment is most likely out of the scope of the messaging upgrade project, the topic should be covered at this phase in the project. Take this opportunity to review your existing disaster recovery plans for your existing environment and think about how it will need to change with the new design.
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 workforce 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 Server messaging environment.
Existing 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 Server database corruptions, or server failures. A complete disaster recovery plan should include offsite data and application access as well. For more details on items that should be considered, see Chapter 33, "Recovering from a Disaster in an Exchange Server 2010 Environment."
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 2010 Design document:
- Executive Summary
- Goals and Objectives
- Business Objectives
- Departmental Goals
- Overview of Process
- Summary of Discovery Process
- Exchange Server 2010 Design Diagram
- Exchange Mailbox Server Placement
- Exchange Mailbox Replication
- Exchange Client Access Server Placement
- Exchange Edge Transport Server Placement
- Exchange Hub Transport Server Placement
- Exchange Unified Messaging Server Placement
- Organization (definition of and number of Exchange Server organizations)
- Mailbox Databases (definition of and number of)
- Mixed Mode Versus Native Mode (choice and decision)
- Global Catalog Placement (definition and placement)
- Recipient Policies (definition and usage)
- 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 admin-istration 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)
- Hardware and Software Estimate
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. The goal with this document is to really understand your audience. The executives probably don't care that you are implementing Database Availability Groups, but they might be interested to hear that you are designing for "four 9s" of uptime.
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.
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.
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.
Planning, Prototyping, Migrating, and Deploying Exchange Server 2010
Initiating an Exchange 2010 upgrade: identifying goals
Using an Exchange Server 2010 design document for upgrades
Using a migration document for Exchange Server 2010
Exchange Server 2010 upgrade: Prototype, pilot phases
Printed with permission from Sams Publishing. Copyright 2009. Exchange Server 2010 Unleashed by Rand Morimoto, Michael Noel, Chris Amaris, Andrew Abbate and Mark Weinhardt. For more information about this title and other similar books, please visit Sams Publishing.
This was first published in April 2010