Solutions provider takeaway: When performing an Exchange Server 2010 upgrade, the first thing a solutions provider should do is outline their customers' scopes, goals and objectives. This chapter excerpt details the initiation phase of an Exchange Server 2010 upgrade and outlines what to look for when identifying upgrade requirements. Making sure that you are well-versed in defining a company's goals based on their size and needs will make an Exchange Server 2010 upgrade easier for you.
Implementing a new messaging environment or upgrading an existing one can be both an exciting time and a stressful time for an administrator. Messaging has changed drastically over the years, steadily growing from an occasionally used way to send short messages to a highly critical collaboration tool that sends hundreds of times more messages each day than the U.S. Post Office. Users depend on Exchange Server to track their tasks, keep their appointments, store important pieces of information, and communicate quickly and easily with co-workers and vendors. As users become more and more dependent on these types of tools, their requirements increase in terms of accessibility and reliability. The ultimate goal of the end users is for email to be much like the telephone. They never want to have to think twice about whether they'll have access to it and whether or not they'll get a dial tone. Proper planning is the key to being able to deliver this level of functionality and reliability. This chapter helps Exchange Server administrators to properly plan out their build or upgrade through standardized processes of planning, prototyping, and migrating or deploying Microsoft Exchange Server 2010.
About the book
This chapter excerpt on Planning, Prototyping, Migrating, and Deploying Exchange Server 2010 (download PDF) is taken from the book Exchange Server 2010 Unleashed. This book provides expert advice on designing, deploying, managing, troubleshooting and supporting Exchange Server 2010. You will learn about Exchange 2010's newest features, including Microsoft Operations Manager, Database Availability Group replication and other new backup and disaster recovery features.
Email has become a business-critical tool and, as such, the upgrade process should never be taken lightly. Although an upgrade from Exchange Server 2003 or Exchange Server 2007 might at first appear to be a simple process, its success relies on your understanding of current issues with the messaging environment, defining both the objectives of the upgrade and its potential effects on the user community. Adding more features and complexity to the messaging "ecosystem" might not result in ecstatic users, but reducing spam and the resulting impact on Inboxes might more than justify the cost of the upgrade.
Reducing the number of milliseconds it takes to send an email probably won't get noticed, but being able to guarantee access to email anywhere and anytime should. Be aware of who your audience is for the upgrade and make sure you understand their existing pain points and how they use Exchange Server and Outlook. An enthusiastic user community tends to generate support and momentum for projects, which allows you to extend the functionality of the messaging system and increase the productivity of your users. Productive users result in happy management. Happy management results in project approval. It's a very positive circle to create. As such, it's important for an administrator to understand the potential benefits that come with Exchange Server 2010 and to ensure that the correct functions are mapped to the appropriate user need.
Important decisions include whether the entire network operating system (NOS) needs to be upgraded (if Active Directory [AD] is not yet in place) or only a subset of it, and what other infrastructure components need to be changed or replaced. It is also very important to realize that Exchange Server 2010 is a 64-bit application and, therefore, needs a 64-bit operating system and 64-bit capable hardware to run. This means that some of your existing tools or integrated applications might or might not work. Testing cannot be underestimated in this process. Pay special attention to the fact that unlike Exchange Server 2007, there will be no 32-bit code available for Exchange Server 2010. This means that if an administrator is going to run the Exchange Server 2010 management tools from his or her own workstation, that workstation must be running a 64-bit version of Windows.
The examples used in this chapter assume that the environments being migrated are primarily based on Exchange Server 2003 or Exchange Server 2007 and, except where noted, that Active Directory is already in place. Please note that an Exchange Server environment must be in Exchange Server 2000 Native mode or higher. Exchange Server 2010 cannot be introduced into an organization that still has Exchange Server 5.5 servers. This would require migrating into a new forest and is discussed later in this chapter. The same process can be applied to other messaging migration projects, such as GroupWise or Notes. The migration process is covered in detail in Chapters 15, "Migrating from Active Directory 2000/2003 to Active Directory 2008," and 16, "Transitioning from Exchange Server 2003/2007 to Exchange Server 2010."
Initiation, Planning, Testing, and Pilot: The Four Phases to the Upgrade
This chapter presents a structured process for upgrading to Exchange Server 2010 and highlights some best practice recommendations to enhance the success of the project. The standard project management phases of initiation, planning, testing, and implementation can be used for organizations of any size and can be applied to most any information technology (IT) project. Transitioning each phase is a "go/no-go" decision, in which the results of the phase are reviewed, and the decision makers determine whether or not the project should move forward. Any problems that were encountered are assessed to deter-mine whether they require attention before moving forward. This ensures that issues identified are addressed, rather than being overlooked, to inevitably crop up at the worst possible moment. You can also use this go/no-go point to feedback results of the testing back into your plans. If you determine that something will be an issue when rolled out, take the fix for the issue and work it back into your process. Now retest with the altered procedure to make sure it works as expected. In this way, you will eventually reach a production rollout with no surprises.
Documentation Required During the Phases
A number of documents are produced during each phase to ensure that the phase is well defined and ultimately successful. In the initiation phase, the goals and requirements of the project can be identified and documented in a Statement of Work document. In the planning phase, more time and energy can be applied to detailing the end state of the migration into a Design document, including the majority of the technical decisions. Although this document paints the picture of what the end state will look like, the road map of how to get there is detailed in the Project Schedule and Migration documents. These documents are only drafts during this phase, because they need to be validated in the prototype phase before they can be considered "final."
Consider tracking the options that were discussed during the design process and document the reasons why a particular choice was made. This allows for future members of your team to understand why particular decisions were made.
The prototype phase validates that the new technologies will effectively meet the organization's needs, and determines whether modifications to the project are needed. Any additional documents that would help with the implementation process, such as Server Build documents, Business Continuity or Disaster Recovery documents, and checklists for work-station configurations, are also created during the testing phase. Finally, the appropriate Maintenance documents are created during the prototype phase so that they can be properly tested without impacting production users. The prototype phase is also when the majority of team cross training should occur, as it's an excellent opportunity to demonstrate the creation and modification of Exchange Server-related objects without impacting a production environment.
These phases and the documents to be created are discussed in more detail later in this chapter.
The following list summarizes the standard phases of an Exchange Server 2010 upgrade and the standard documents created in each phase:
- Initiation phase -- Statement of Work document that reflects the goals and objectives of the key stakeholders of the project.
- Planning phase -- Design document draft, Migration document draft, and Migration schedule draft (Gantt chart).
- Prototype phase -- Design document final, Migration document final, Migration schedule final (Gantt chart), Server Build documents, Migration checklists, Maintenance documents, and Training documents for end users and administrators.
- Implementation phase -- As-built documents for all servers.
For smaller environments, not all of these items are required, but it's important to have each document created before it is needed, to avoid delays during the migration process. For example, having a Statement of Work document that is well constructed and agreed upon in the initiation phase clears the way for the creation of the Design document and Migration document. A detailed Migration Schedule Gantt chart facilitates scheduling of resources for the actual work and clarifies the roles and responsibilities. Remember to have the appropriate groups review the documentation and get their approval to consider the document "done." This avoids potential issues in which a group might change their minds and claim that they never agreed to a design decision or migration process.
Initiation Phase: Defining the Scope and Goals
Upgrading to Exchange Server 2010 can be a simple process for basic messaging environments, or as challenging as a complete network operating system upgrade for more complex organizations. In most environments, Exchange Server is implemented on multiple servers, and an upgrade affects a number of other software applications. In fact, changes to the Exchange Server environment might affect the daily lives of the employees to a much greater extent than moving from Windows NT to Windows Server 2003 (or even more than an upgrade from a non-Microsoft environment) because they will most likely receive a new Outlook client and change the way they access email remotely. With an operating system upgrade, the end users often don't even know that anything has changed.
The upgrade process is also a great opportunity to help the business achieve its business objectives by leveraging the messaging components of the technology infrastructure and to help justify the never-ending IT expenses. Messaging, in essence, enables the sharing of information and access to data and other resources within the company to help the company deliver its products or services. With this critical purpose in mind, it makes sense to engage in a structured and organized process to determine the goals of the project, control the variables and risks involved, and make sure that a clear definition of the end state has been crafted. The Statement of Work is the key deliverable from this phase that paints the overall picture of the upgrade project and gains support from the key decision makers (and allocates an initial budget).
Be sure to take into account any regulatory compliances that you need to maintain. This includes things such as HIPAA, Sarbanes-Oxley, or the Gramm-Leach-Bliley Act. These types of regulatory compliances will likely influence your decisions about how your systems will be deployed and managed. It is much easier to account for these requirements during the planning phase than it is after you've deployed Exchange Server 2010.
The Scope of the Project
Before the entire Statement of Work can be written, time should be allocated to define the scope of the project. The scope of the project simply defines what is included in the project and what is not. For a simpler environment, this might be very easy to define -- for example, an environment in which there is only one server used for email and scheduling, with a dedicated backup device and virus-protection software. If this organization has not migrated to Active Directory yet, the scope might expand to include the upgrade of additional servers or simply upgrade the single server. Depending on the version of Active Directory in place, there would likely be a schema updated in the scope as well. A desktop upgrade might be included in the scope of the project if the features and benefits of Outlook 2007 are desired. In any case, it's important to clarify this level of detail at the beginning of the planning process. "Scope creep" is a lot more manageable if it can be predicted in advance! If the scope starts to grow to be out of hand, consider breaking it up into multiple projects. For example, if you have a large upgrade to Exchange Server 2010, you can split off the upgrading of desktops to Outlook 2007 to be a separate project. This can also help prevent a project from stalling out because of too many dependencies on other groups or projects.
An example of a scope of work for a small organization is as follows:
- Upgrade the Exchange Server 2003 Windows 2003 server to Exchange Server 2010 with Windows Server 2008 64-bit.
- Upgrade the tape backup and virus-protection software to Exchange Server 2010--compatible versions.
- Upgrade the Outlook client to Outlook 2007 on all workstations.
- Provide secure Outlook Web App (OWA) access to all remote users.
In a larger company, "what's in" and "what's out" can be significantly more complicated. A company with multiple servers dedicated to Exchange Server functions -- such as load-balanced client access servers and clustered mailbox servers, multiple Hub Transport servers, or servers dedicated to faxing or conferencing -- requires the scope definition to get that much more detailed. Multiple sites and even different messaging systems complicate the scope, especially if the company has grown via mergers over the last few years. Odds are that larger environments will have a mix of hardware ranging in age from 0 to 3 years old. Changes in the architecture of Exchange Server 2010 mean that companies will likely be looking at changes in their standard hardware specs, as well as their storage require-ments for Exchange Server. Always be sure to look at the big picture and account for as much as you can in the scope.
An example of a scope of work for a larger organization is as follows:
- Upgrade the four Exchange Server 2007 Windows 2003 mailbox clusters to two Exchange Server 2010 mailbox servers in DAG on Windows Server 2008 64-bit.
- Replace the two Exchange Server 2007 on Windows 2003 client access servers with two Exchange Server 2010 on Windows 2008 client access servers.
- Migrate the mailbox data from the SAN storage to local disks on the new Exchange Server 2010 mailbox servers.
- Provide Outlook Web App (OWA) access to all remote users.
- Upgrade the enterprise tape backup and virus-protection software on all servers to the latest versions that are Windows Server 2008--compatible and Exchange Server 2010--compatible.
- Implement unified messaging on Exchange Server 2010.
- Upgrade the Outlook client to Outlook 2007. Provide OWA access to all remote users.
The scope of work might change as the initiation phase continues and, in the more detailed planning phase, as the Design and Migration documents are created and reviewed. This is especially true for more complex migration projects after the detailed planning phase is completed and the all-important budget is created. At this point, the scope might need to be reduced, so that the budget requested can be reduced.
It is in your best interest to circulate your plans among other groups not only to get their buy-in on the migration, but also to give them a chance to see how it might impact their projects. Often, the group managing the phone systems will look at a project like an Exchange Server 2010 upgrade and take the opportunity to make changes to their systems to further integrate with Exchange Server. Knowing about these integration plans early in your process makes it easier to accept them. Altering a deployed environment after the fact is almost always more expensive and more complicated. Do everything you can to keep your project stable and uneventful.
Identifying the Goals
As a next step in the initiation phase, it helps to spend time clearly identifying the goals of the project before getting too caught up in the technical details. All too often, everyone runs up the whiteboard and starts scribbling and debating technology before agreeing on the goals. Although this conversation is healthy and necessary, it should be part of the planning phase, after the high-level goals for the project and initial scope have been defined. Even if there is a very short timeline for the project, the goals -- from high-level business objectives, to departmental goals, to the specific technology goals -- should be specified.
It is important to have the correct audience in the goal-setting phase of the initiation phase. This will likely be the meeting with the largest attendance. Try to gather goals and objectives from groups such as the following:
- Information technology
- Help desk
- Upper management
- Business unit representatives
- Enterprise backup
By talking to this diverse group of people, you can capture existing pain points of the users and maintainers of the messaging environment and try to alleviate those issues. You can also get a much more accurate feel for how your end users actually utilize Exchange Server and ensure that you account for those items.
One of the biggest values you get out of clearly identifying your goals is that it simplifies the technical decisions that will be made later. Anytime there is contention around a given decision, you can always ask yourself "Does this decision support my originally stated goals?" and if not, it is probably not the right decision.
High-Level Business Goals
The vision statement of an organization is an excellent place to start because it tells the world where the company excels and what differentiates that company from its competitors. There will typically be several key objectives behind this vision, which are not so publicly stated, that can be related to the Exchange Server 2010 upgrade. These should be uncovered and clarified, or it will be difficult, if not impossible, to judge whether the project succeeds or fails from a business standpoint.
High-level business goals that pertain to an Exchange Server 2010 upgrade can include better leveraging of company knowledge and resources through efficient communications and collaboration, controlling IT costs to lower overhead and enabling products to be more competitively priced, or improving security to meet governmental requirements. An IT group that understands these larger goals and can serve as an enabler for business practices through technology is an amazing asset to any company.
Although this process sounds basic, it might be more difficult if the company hasn't documented or updated its business objectives in some time (or ever). Different divisions of larger companies might even have conflicting business goals, which can make matters more complicated. High-level business goals of a company can also change rapidly, whether in response to changing economic conditions or as affected by a new key stake-holder or leader in the company. So even if a company has a standard vision statement in place, it is worth taking the time to review and ensure that it still accurately reflects the opinions of the key stakeholders.
This process helps clarify how the messaging upgrade fits into the overall company strategy and should help ensure that support will be there to approve the project and keep its momentum going. In this time of economic uncertainty, a project must be strategic and directly influence the delivery of the company's services and products; otherwise, the danger exists of a key stakeholder "pulling the plug" at the first sign of trouble or shifting attention to a more urgent project.
For example, a consulting organization might have a stated vision of providing the latest and greatest processes and information to its clients, and the internal goal could be to make its internal assets (data) available to all employees at all times to best leverage the knowledge gained in other engagements. The Exchange Server environment plays a key role in meeting this goal because employees have become so dependent on Outlook for communicating and organizing information, and many of the employees rely on portable devices such as BlackBerries or Windows Mobile devices.
A different company, one which specializes in providing low-cost products to the market-place, might have an internal goal of cost control, which can be met by Exchange Server 2010 through reduction in the total server count, storage technologies, and more cost-effective management to help reduce downtime. For this company, user productivity is measured carefully, and the enhancements in the Outlook 2007 client would contribute positively.
High-Level Messaging Goals
At this point, the business goals that will guide and justify the Exchange Server upgrade should be clearly defined, and the manner in which Exchange Server 2010's enhanced features will be valuable to the company are starting to become clear. The discussion can now turn to learning from key stakeholders what goals they have that are specific to the messaging environment that will be put in place and how Exchange Server 2010 might improve their day-to-day business processes.
The high-level goals tend to come up immediately, and be fairly vague in nature; but they can be clarified to determine the specific requirements. A CEO of the company might simply state "I need access to all of my email and calendar data from anywhere." The CTO of the same company might request "zero downtime of the Exchange servers and easy integration with other automated business systems." The CFO might want to "reduce the costs of the email system and associated technologies." If the managers in different departments are involved in the conversation, a second level of goals might well be expressed. The IT manager might want geographic redundancy, the ability to restore a single user's mailbox, and reduced user complaints about spam and performance. The marketing manager might want better tools to organize the ever-increasing amount of "stuff" in his employees' Inboxes and mail folders.
Time spent gathering this information helps ensure that the project is successful and the technology goals match up with the business goals. It also matters who is spearheading the process and asking the questions because the answers might be very different if asked by the president of the company rather than an outside consultant who has no direct influence over the career of the interviewee. By involving the people whose employees will be most affected by the upgrade and listening to their needs, you can create very powerful allies in getting approval for the technology and hardware necessary to support their goals and objectives.
An example of some common high-level messaging goals include a desire to have no downtime of the Exchange servers, access to email and calendars from anywhere, better functionality of the OWA client, and increased virus and spam protection.
A specific trend or theme to look for in the expression of these goals is whether they are focused on fixing and stabilizing or on adding new functionality. When a company is fixated on simply "making things work properly," it might make sense to hold off on implementing a variety of new functionality (such as videoconferencing or providing Windows-powered mobile devices using the Windows Mobile operating system) at the same time. Make sure you listen to your audience and design an environment that supports their needs and addresses their concerns. Avoid the pitfalls of enabling new functions simply because they seem "cool."
Business Unit or Departmental Messaging Goals
After these higher-level goals have been identified, the conversations can be expanded to include departmental managers and team leads. The results will start to reveal the complexity of the project and the details needed to complete the Statement of Work for the migration project. For an Exchange Server upgrade project to be completely successful, these individuals, as well as the end users, need to benefit in measurable ways.
Based on the business and technology goals identified thus far, the relative importance of different departments will start to become clear. Some organizations are IT-driven, especially if they are dependent on the network infrastructure to deliver the company's products and services. Others can survive quite well if technology isn't available for a day or even longer.
Examples of some departmental goals include a desire to ensure encrypted transmission of human resource and personnel emails, an OWA client that has the same functionality as the Outlook client, and support for Smartphone and Windows Mobile devices. The IT department might also like better mailbox recovery tools and Exchange Server-specific management tools that can be used to centralize and simplify the management of Exchange Server.
All departments use email, but the Sales department might also receive voice mails through the Outlook client and updates on product pricing, and, therefore, need the best possible reliability and performance. This includes ensuring that viruses don't make it into employee Inboxes and that spam be reduced as much as possible.
Certain key executives are rarely in the office and might not be happy with the existing OWA client. They might also carry BlackBerry wireless devices or Windows Mobile phones and need to make sure that they remain fully functional during and after the upgrade.
The Marketing department might use the email system for sharing graphics files via public folders, which have grown to an almost unmanageable size, but this enables them to share the data with strategic partners outside of the company. This practice won't change, and the amount of data to be managed will continue to grow over time.
The Finance and Human Resources departments might be concerned about security and want to make sure that all email information and attached files are as safe as possible when traveling within the organization, or being sent to clients over the Internet.
The IT department could have a very aggressive service level agreement (SLA) to meet and be interested in clustering, reducing the number of servers that need to be managed, and improving the management tools in place. In addition, Exchange Server 2010's integration with Active Directory will facilitate the management of users and groups and additions and changes to existing user information.
In the process of clarifying these goals, the features of the Exchange Server messaging system that are most important to the different departments and executives should become apparent.
A user focus group might also be helpful, which can be composed of employee volunteers and select managers, to engage in detailed discussions and brainstorming sessions. In this way, the end users can participate in the initial planning process and help influence the decisions that will affect their day-to-day work experience.
Other outcomes of these discussions should include an understanding of which stakeholders will be involved in the project and the goals that are primary for each person and each department. A sense of excitement should start to build over the possibilities presented by the new technologies that will be introduced to make managers' lives easier and workers' days more productive.
This process also serves an additional benefit of giving people a sense of how big the project really is and where they'll see the benefits that affect them the most. A major change like an Exchange Server upgrade should always be well communicated to the end-user community so that they will know what changes to expect, when to expect them, and how to prepare for them.
Initiation Phase: Creating the Statement of Work
Executives generally require a documented Statement of Work that reflects strategic thinking, an understanding of the goals and objectives of the organization, and a sense of confidence that the project will be successful and beneficial to the company. The document needs to be clear and specific and keep its audience in mind. This generally means not going into too much technical detail in the Statement of Work. This document also needs to give an estimate of the duration of the project, the costs involved, and the resources required. The document should be written such that it can be understood by someone who knows nothing about the technology that is being proposed. This is a classic example of where one needs to understand the point of view of their audience and to tailor the information to what that target audience will want to see.
The initial scope of work might have changed and evolved as discussions with the executives, managers, and stakeholders reveal problems that weren't obvious and requirements that hadn't been foreseen. Although the scope started out as a "simple Exchange Server upgrade," it might have expanded to include an upgrade to Active Directory, the addition of new features for remote access to the messaging environment, the rollout of new 64-bit capable servers or management, and business continuity features.
The following is a standard outline for the Statement of Work document:
- Scope of Work
- Goals and Objectives
- Timeline and Milestones
- Risks and Assumptions
- Initial Budget
The following sections cover the different components of the Statement of Work. This document is arguably the most important in the entire process because it can convince the executives who hold the purse strings to move forward with the project -- or, of course, to stop the project in its tracks.
Summarizing the Scope of Work
At this point in the initiation phase, a number of conversations have occurred that have clarified the basic scope of the project, the high-level business goals as they pertain to the messaging upgrade, and the more specific goals for each department and of key stakeholders. Armed with this wealth of information, the lead consultant on the project should now organize the data to include in the Statement of Work and get sign-off to complete the phase and move to the more detailed planning phase.
The Scope section of the Statement of Work document should answer these essential questions:
- How many Exchange Server and Windows servers need to be upgraded?
- Where do these servers reside?
- What additional applications need to be upgraded (especially backup, virus protection, disaster recovery, and remote access) as part of the project?
- What additional hardware needs to be upgraded or modified to support the new servers and applications (especially tape backup devices, SANs, routers)?
- Will laptop configurations be changed? If so, will you need physical access to them?
- Will the desktop configurations be changed?
The answers to these questions might still be unclear at this point, and require additional attention during the planning phase.
Summarizing the Goals
As discussed earlier, a number of conversations have been held previously on the topic of goals, so there might be a fairly long list of objectives at this point. A structure to organize these goals is suggested in the following list:
- Business continuity/disaster recovery (clustering, storage, backup, and restore)
- Performance (memory allocation improvements, public folders, email)
- Security (server, email)
- Mobility (Outlook Web App, Windows Mobile, and Outlook Anywhere support)
- Collaboration (Public Folders, SharePoint Portal, Office Communications Server integrations)
- Serviceability (administration, management, deployment)
- Development (Collaboration Data Objects, managed application programming inter-face [API])
By using a framework such as this, any "holes" in the goals and objectives of the project will be more obvious. Some of the less-glamorous objectives, such as a stable network, data-recovery abilities, or protection from the hostile outside world, might not have been identified in the discussions. This is the time to bring up topics that might have been missed, before moving into the more detailed planning phase.
It might also be valuable to categorize portions of the upgrade as "fixes" for existing pain points, as opposed to "new" capabilities that will be added to the environment.
Summarizing the Timeline and Milestones
A bulleted list of tasks is typically all that is needed to help define the time frame for the upgrade, although more complex projects will benefit from a high-level Gantt chart. The time frame should be broken down by phase to clarify how much time is to be allocated for the planning phase and testing phases. The actual implementation of the upgrade also should be estimated. A good rule of thumb at this point is that no task represented on the project plan should have a duration of less then 1 day. If it logically has a shorter duration, it's probably too detailed to call out at this point.
Depending on the complexity of the project, a time frame of 1 to 2 months could be considered a "short" time frame, with 2 to 4 months offering a more comfortable window for projects involving more servers, users, and messaging-related applications. Additional time should be included if an outside consulting firm will assist with part or the entire project. Be sure to account for things such as acquiring hardware, application testing, and shipping of hardware to remote locations. These types of items can often be overlooked, yet they can easily add weeks to the timeline of a project like this.
Because every project is different, it's impossible to provide rules for how much time to allocate to which phase. Experience has shown that allocating additional time for the planning and testing phase helps the upgrade go more smoothly, resulting in a happier user base. If little or no planning is done, the testing phase will most likely miss key requirements for the success of the project. Remember also to allocate time during the process for training of the administrative staff and end users.
Be aware of your own internal processes and try to account for them. If your environment requires, for example, that the security group perform a security audit on any server before it is released into production, be sure to account for this in the timeline. Also be sure to let that other group know that you will be submitting a potentially large number of servers for them to audit so that they can also prepare their own resources to be ready for you. Careful teamwork and communication around these types of activities can save a lot of time overall.
The key to successfully meeting a short timeline is to understand the added risks involved and define the scope of the project so that the risks are controlled. This might include putting off some of the functionality that is not essential, or contracting outside assistance to speed up the process and leverage the experience of a firm that has performed similar upgrades many times. Hardware and software procurement can also pose delays, so for shorter time frames, they should be procured as soon as possible after the ideal configuration has been defined. Don't be afraid to make certain portions of the original project "out of scope" and spin them into separate projects. Keeping your project realistic makes it easier to complete successfully.
Summarizing the Resources Required
Typical roles that need to be filled for an Exchange Server 2003 upgrade project include the following:
- Project sponsor or champion
- Exchange Server 2010 design consultant
- Exchange Server 2010 technical lead
- Exchange Server 2010 consulting engineer
- Project manager
- Systems engineer(s)
- Technical writer
- Administrative trainer
- End-user trainer
The organization should objectively consider the experience and skills, as well as available time of internal resources, before deciding whether outside help is needed. For the most part, few companies completely outsource the whole project, choosing instead to leverage internal resources for the tasks that make sense and hiring external experts for the planning phase and testing phases. Often, internal resources simply can't devote 100% of their energy to planning and testing the messaging technologies because their daily duties get in the way. Contracted resources, on the other hand, are able to focus just on the messaging project. Most successful projects include a mix of internal and external resources. This allows the internal resources to gain valuable knowledge from the external resources and end up with a strong knowledge of their own environment from their direct involvement with the design and deployment.
The resulting messaging environment needs to be supported after the dust settles, so it makes sense for the administrative staff to receive training in the early phases of the upgrade (such as planning and testing) rather than after the implementation. Many consultants provide hands-on training during the testing and implementation phases. It is easier to perform most of the training in the prototype phase because you will have a working environment that doesn't have any users on it. This allows the administrative staff to practice moving mailboxes, recovering data and entire servers, and rebuilding servers from scratch without impacting any production users.
For larger projects, a team might be created for the planning phase, a separate team allocated for the testing phase, and a third team for the implementation. Ideally, the individuals who perform the testing participate in the implementation for reasons of continuity. Implementation teams can benefit from less-experienced resources for basic server builds and workstation upgrades. By properly assigning the project tasks to the right resources, you can maximize the chances for overall success. By providing for a bit of overlap between tasks and resources, you can also cross-train your staff so that they can more easily support each other.
Summarizing the Risks and Assumptions
More time is spent discussing the details of the risks that could affect the successful outcome of the project during the planning phase; however, if there are immediately obvious risks, they should be included in the Statement of Work.
Basic risks could include the following:
- Existing Exchange Server problems, such as a corrupt database or lack of maintenance
- Lack of in-house expertise and bandwidth for the project
- Using existing hardware that might not have enough random access memory (RAM), storage capacity, processor speed, or the ability to support a 64-bit operating system
- Wide area network (WAN) or local area network (LAN) connectivity issues, making downtime a possibility
- A production environment that cannot experience any downtime or financial losses will occur
- Customized applications that interface with Exchange Server and that need to be tested and possibly rewritten for Exchange Server 2010
- Short timeline that will require cutting corners in the testing process
Summarizing the Initial Budget
The decision makers will want to start getting a sense for the cost of the project, at least for the planning phase of the project. Some information might already be quite clear, such as how many servers need to be purchased. If the existing servers are more than a few years old and don't support a 64-bit operating system, chances are they need to be replaced, and price quotes can easily be gathered for new machines. Software upgrades and licenses can also easily be gathered, and costs for peripheral devices such as tape drives or SANs or host bus adapters should be included.
If external help is needed for the planning, testing, and implementation, some educated guesses should be made about the order of magnitude of these costs. Some organizations set aside a percentage of the overall budget for the planning phase, assuming outside assistance, and then determine whether they can do the testing and implementation on their own.
As mentioned previously, training should also not be forgotten for both the administrative staff and the end users.
Getting Approval on the Statement of Work
After the initial information has been presented in the Statement of Work format, formally present it and discuss it with the stakeholders. If the process has gone smoothly this far, the Statement of Work should be approved, or, if not, items that are still unclear can be clarified. After this document has been agreed upon, a great foundation is in place to move forward with the planning phase.
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.
About the authors:
Michael Noel is an IT expert and a partner at Convergent Computing. Noel has also written Microsoft SharePoint 2007 Unleashed.
Chris Amaris cofounded Convergent Computing and also serves as the chief technology officer. Amaris is the co-author of Microsoft Exchange Server 2007 Unleashed.
Andrew Abbate has been in the IT industry for more than 10 years and specializes in Active Directory and Microsoft Exchange Server migration planning and implementations.
Mark Weinhardt has worked in the IT world for more than 20 years and has also authored Network Security for Government and Corporate Executives.