Planning the Exchange Server 2010 Infrastructure

Objective 1.5: Plan for Transition and Coexistence

One thing to keep in mind when planning for transition from Exchange 2003 or Exchange 2007 to Exchange 2010 or coexistence is that the term upgrade isn’t entirely accurate. You can’t perform an in-place upgrade from either Exchange 2003 or Exchange 2007 to Exchange 2010 in so far as it is not possible to directly upgrade a server running either of these products to Exchange 2010. An upgrade involves installing Exchange 2010 into your existing Exchange organization and then moving data and functionality across to the new Exchange 2010 servers. A migration involves moving from one messaging system to another. If you are performing a migration from Exchange 2003 or Exchange 2007, you install Exchange 2010 in a new Active Directory forest and then migrate data across.

Exchange Consolidation

As organizations are able to deploy more powerful hardware, they are able to consolidate their Exchange deployment onto fewer servers. For example, an organization that may have had 10 Exchange 2007 mailbox servers might, with the substantially better hardware that has become available in the intervening years, be able to service the same number of clients with fewer servers. Hardware improvements aside, Exchange Server 2010 has been engineered to provide better performance on the same hardware compared to previous versions of Exchange. When planning a transition from Exchange 2003 or Exchange 2007 to Exchange 2010, remember that you may not need to have as many Exchange 2010 servers as you had previously because of improvements in hardware an Exchange performance.

To determine the capacity of your new servers, Microsoft makes available two tools that you can use to perform a capacity analysis on your hardware. The drawback of these tools is that you have to actually have the hardware to test it against. The first tool, Exchange Server Jetstress 2010, allows you to perform I/O benchmarking against the storage on a mailbox server. The second tools, Exchange Server Load Generator 2010 (LoadGen) allows you to simulate a client workload against a test Exchange environment. You learned about LoadGen earlier in this chapter. Using these tools, you can make informed estimates about the capacity of the Exchange 2010 servers that you are going to deploy.

Upgrade Approaches

When you are developing your upgrade plan, you have to decide whether you are going to perform a single-phase upgrade or whether you are going to prepare a multiphase upgrade with coexistence. The differences between these two approaches are as follows:

• Single-phase upgrades involve replacing an existing messaging system with Exchange Server 2010. Single-phase upgrades minimize the coexistence period between the two systems and all required data and services are moved to Exchange 2010 as expeditiously as possible. These upgrades allow the transition to occur quickly, but the chance of problems arising is higher than when the transition occurs at a more measured pace.

• Multiphase upgrade with coexistence is a more measured approach to transitioning to Exchange Server 2010. This might involve upgrading one server at a time or one site at a time. This is often a more pragmatic approach for large sites where a quick transition of the existing infrastructure is infeasible because of the size of the migration. This involves planning for a period of interoperability. Although supporting interoperability is more complicated, the more measured approach allows each phase in the migration to be completed separately before moving on to the next phase.

When using a multiphase upgrade with coexistence strategy, you need to ensure that users that have mailboxes hosted on both the existing and the Exchange 2010 messaging system have access to the following:

• Public folders If your Exchange 2003 or Exchange 2007 organization uses public folders, you will need to come up with a way of replicating public folder data between systems. As an alternative, you could migrate public folder data to SharePoint if you don’t need to support Outlook 2003 clients.

• E-mail message flow You need to keep this working transparently so that users of the old and new systems are able to send email to each other without having to know whether the destination mailbox is on the old or new system.

• Global Address List (GAL) You need to ensure that users of both systems are able to efficiently locate addresses and address lists on both the old and new systems.

• Calendar information Users in on both the old system and the new system need to be able to schedule meetings and view free/busy data of other people in the organization irrespective of which messaging system people’s mailboxes reside on.

• Administration tools Exchange administrators need to be able to quickly and efficiently manage servers running both the original messaging system and Exchange Server 2010.

Multiple Sites

Transitioning an organization that has a single site from Exchange 2003 or Exchange 2007 to Exchange 2010 is far simpler than transitioning an organization that has sites spread across geographically dispersed locations. When planning a transition from a previous version of Exchange to Exchange 2010, keep the following in mind:

• You must upgrade Internet-facing sites prior to upgrading internal sites. This restriction is due to Client Access Server proxying functionality.

• When upgrading a site, upgrade Exchange roles by introducing servers in the following manner:

  1. Client Access

  2. Hub Transport

  3. Mailbox

  4. Edge Transport

The Edge Transport server is only necessary if you are choosing to use an Edge Transport server rather than a third-party email gateway. Edge Transport servers are also only deployed on perimeter networks at Internet-facing sites, so you don’t need to plan on deploying them at every site during a transition to Exchange 2010.

Exchange 2003 Upgrade or Coexistence

When planning an upgrade or coexistence scenario for an Exchange 2003 organization that you wish to transition to Exchange 2010, first ensure the following:

• Your Exchange 2003 organization is running in Native rather than Mixed mode.

• All servers running Exchange 2003 are upgraded to Exchange 2003 Service Pack 2.

• At least one global catalog server in each site is running at Windows Server 2003 Service Pack 2 or later.

• The computer that hosts the schema master role is running at Windows Server 2003 Service Pack 2 or later.

• The domain and forest functional level are configured at the Windows Server 2003 or higher level.

As you’ll learn in Chapter 2, the requirements for Exchange Server 2010 SP1 are slightly different than those published for Exchange Server 2010 RTM, and that the 70-663 exam targets RTM rather than SP1. It is also worth checking with the relevant TechNet documentation that is linked to this and the next chapter to determine whether any other prerequisites have changed when Exchange Server 2010 Service Pack 2 is released. Chapter 2 will cover the process in more detail, but in general your plan should involve the following steps:

1. Upgrade any Internet-facing sites first.

2. Install the Client Access Server first. Configure clients to use the new Exchange 2010 Client Access Server as their connection point to both Exchange 2010 and Exchange 2003.

3. Install the Hub Transport role after the Client Access Server has been deployed. The first Hub Transport server deployment will involve you specifying an Exchange 2003 bridgehead server.

4. Deploy the Mailbox servers in the site.

5. Deploy the Edge Transport server and configure EdgeSync.

6. After you have performed steps 2 through 4 on all Internet-facing sites, perform steps 2 through 4 on all non-Internet-facing sites.

7. Begin migrating public folders and mailboxes from the Exchange 2003 servers to the Exchange 2010 servers. In multiple-site upgrades, you can begin moving mailboxes and public folders prior to upgrading additional sites if you so choose.

When planning a transition from Exchange 2003 to Exchange 2010, remember that the following Exchange 2003 features are not supported in Exchange 2010:

• Novell GroupWise connector This connector allows coexistence between Novell GroupWise and an Exchange 2003 organization. If your organization requires the functionality this connector provides, it will be necessary to retain at least one server running Exchange 2003 in your environment until the functionality is no longer required or another solution becomes available.

• NNTP Network News Transfer Protocol (NNTP) allows the use of newsgroup content. If it is necessary to retain NNTP functionality in your organization, either retain a server running Exchange 2003 or look for a third-party NNTP server solution.

• Office Outlook Mobile Access The functionality that was provided by Office Outlook Mobile Access is now provided through ActiveSync.

• Inter-Organization Replication Tool This tool allowed the exchange of meeting, appointment, and contact data between two different Exchange 2003 organizations. Exchange Server 2010 uses Microsoft Federation Gateway to provide this functionality.

Once you have moved all public folder and mailbox server data from Exchange 2003 to Exchange 2010, you can begin to decommission the existing Exchange 2003 infrastructure. Microsoft recommends that you remove Exchange 2003 in the following manner:

• Remove Exchange 2003 back-end servers first. You can remove back-end servers as soon as all the relevant data on the server has been migrated across to Exchange 2010.

• Remove the Exchange Server 2003 bridgehead server after you’ve removed the last mailbox server in a routing group.

• Remove the Exchange 2003 front-end servers last.

Exchange 2007 Upgrade or Coexistence

Exchange 2007 has a superficially similar structure to that of Exchange 2010 with both systems utilizing the Hub Transport, Edge Transport, Mailbox and Client Access Server roles. As is the case with an upgrade from Exchange 2003, you’ll need to ensure that the global a catalog server in each site and the schema master is upgraded to the appropriate service pack level for the deployment of Exchange 2010 SP1. You also need to ensure that the forest functional level is set to Windows Server 2003. Finally, prior to attempting upgrade, ensure that all Exchange 2007 servers have Exchange 2007 Service Pack 2 installed. The specifics of upgrading Exchange 2007 to Exchange 2010 are covered in more detail by Chapter 2, but in general you need to perform the following steps:

1. In multi-site environments, upgrade any Internet-facing sites before upgrading any internal sites.

2. Deploy the Exchange 2010 Client Access Server first. After this is done, modify Autodiscover settings to point at the Exchange 2010 Client Access Server.

3. Install the Exchange Server 2010 Hub Transport server. During coexistence, you will have both Exchange Server 2010 and Exchange Server 2007 Hub Transport Servers in the same sites.

4. Install the Exchange Server 2010 Mailbox servers. You can begin migrating mailboxes and public folder data from Exchange Server 2007 Mailbox servers at this stage, or wait until several sites are upgraded fully before taking that step.

5. Install the Exchange Server 2010 Edge Transport Servers. Exchange Server 2010 Edge Transport servers can only synchronize with Exchange Server 2010 Hub Transport Servers.

6. Repeat steps 2 through 5 at all Internet-facing sites before performing steps 2 through 4 at all non-Internet-facing sites.

When planning an upgrade from Exchange 2007 to Exchange 2010, ensure that you account for the fact that the following Exchange 2007 features are not supported in Exchange 2010:

• Single Copy Cluster Exchange 2007 high-availability features have been replaced in Exchange 2010 by Database Availability Groups. You’ll learn more about Database Availability Groups in Chapter 4.

• Local Continuous Replication Exchange 2007 high-availability features have been replaced in Exchange 2010 by Database Availability Groups. You’ll learn more about Database Availability Groups in Chapter 4.

• Cluster Continuous Replication Exchange 2007 high-availability features have been replaced in Exchange 2010 by Database Availability Groups. You’ll learn more about Database Availability Groups in Chapter 4.

• Standby Continuous Replication Exchange 2007 high-availability features have been replaced in Exchange 2010 by Database Availability Groups. You’ll learn more about Database Availability Groups in Chapter 4.

• Microsoft Transport Suite for Lotus Domino This tool allowed for interoperability between Exchange 2007 environments and Lotus Domino. It also provided tools that could be used to migrate users from Lotus Domino to Exchange Server 2007. If you need to retain interoperability with your organization’s Lotus Domino messaging system, you’ll need to retain at least one server running Exchange 2007 in your Exchange organization.

• Programmatic Access to Exchange through ExOLEDB, WebDAV, or CDOEX (CDO for Exchange 2000 Server) This functionality has been replaced by the Exchange Web Services (EWS) or EWS-Managed API. If you have not migrated the applications that use this technology to utilize the EWS-Managed API, you’ll need to retain at least one server running Exchange 2007 in your Exchange organization.

After you have moved all data from your organization’s Exchange 2007 Mailbox servers to the new Exchange 2010 Mailbox servers, you’ll be able to begin removing the Exchange 2007 infrastructure. Remove Exchange 2007 servers in the following order:

1. Remove Mailbox servers first. You can decommission a mailbox server as soon as you have removed all mailbox and public folder data from it.

2. When all Exchange 2007 Mailbox servers at a site have been removed, you can remove any Exchange 2007 Hub Transport servers at that site.

3. Remove the Exchange 2007 Client Access Servers and Edge Transport servers.

Mixed Exchange 2003 and Exchange 2007 Environments

Planning to upgrade a mixed Exchange 2003 and Exchange 2007 environment is similar to upgrading from environments containing a single Exchange 2003 or Exchange 2007 organization. You’ll need to upgrade Internet-facing sites first by introducing Client Access, Hub Transport, and then Mailbox servers. Introduce Edge Transport servers at this stage as appropriate. Move data from Exchange 2003 back-end and Exchange 2007 Mailbox servers to Exchange 2010. Begin decommissioning, removing the Exchange 2003 back-end servers, bridgehead servers, and then front-end servers. Then remove the Exchange 2007 Mailbox servers, Hub Transport servers, Client Access Servers, and then Edge Transport servers.

Exchange Server Deployment Assistant

The Exchange Server Deployment Assistant, also known as ExDeploy, which you learned about earlier in this chapter, is an excellent tool for generating checklists to assist you with transitioning your organization from Exchange 2003, Exchange 2007, or a mixed Exchange 2003 and Exchange 2007 environment to Exchange Server 2010. The tool is Silverlight-based and generates a transition checklist based on the answers you provide to a series of questions about your environment. The checklist for an Exchange 2003 to Exchange 2010 environment is shown in Figure 1-15.

You can use this automatically generated checklist as a guide in developing your plans to transition your organization from previous versions of Exchange. You can also use the checklist to verify each step of the transition process.

Coexistence with SMTP-Based Messaging Systems

Many organizations use messaging systems from multiple vendors. This is often the case in environments that have substantial UNIX-based deployments where each team of administrators is wary of using systems hosted on different platforms, though you may have other technical and political reasons to maintain a multi-vendor messaging infrastructure.

In most cases the third-party messaging system will support SMTP traffic and it is possible to get the both Exchange and the third-party messaging system to communicate by configuring appropriate internal Send and Receive connectors.

Coexistence with non-SMTP Messaging Systems

Although almost all modern previous versions of Exchange did offer connector and migration tools for third-party products such as Lotus Notes and Novell GroupWise, but these connectors are not present in Exchange Server 2010. Exchange 2010 does support foreign connectors for third-party messaging systems, but you need to obtain those connectors from the vendor of the third-party messaging system or another third-party vendor who might provide their own set of tools.

You can also use delivery agents and Foreign connectors to deliver messages to third-party non-SMTP messaging systems. Although Foreign connectors are supported in Exchange Server 2010, Microsoft recommends that you use Delivery Agents for coexistence functionality. Delivery agents have the following benefits:

• Allows queue management for messages routed to foreign systems using standard queue management tasks

• Improved performance

• Can use the message representation and management features of Exchange

• Provides confirmation that messages have been delivered to the third-party system

• Allows administrators to track latency of message delivery to the foreign system

Global Address List Synchronization

In coexistence scenarios, it is often useful to include some sort of Global Address List scenario so that users of the Exchange messaging system are able to view and search addresses in the third-party messaging system. Similarly, users of the organization’s third-party messaging system are likely to want to be able to search and view addresses of users with Exchange mailboxes. How effectively this can be done depends very much on the functionality available in the third-party messaging system. You have the following options when it comes to planning synchronization of Global Address lists between Exchange 2010 and third-party messaging systems:

• You may be able to use the GAL synchronization functionality available in Forefront Identity Manager 2010, though this is mostly used to support Exchange cross-forest topologies.

• The third-party vendor might provide a GAL synchronization tool that automatically synchronizes the third-party global address list with Exchange.

• You can create Lightweight Directory Access Protocol (LDAP) replication scripts. You can only do this if the third-party messaging system supports using LDAP queries to extract mailbox and contact information. These scripts will have to be run manually or be automated in some fashion.

Objective Summary

• JetStress allows you to test how well a mailbox server handles simulated load. LoadGen allows you to simulate CAS load. Both tools can be used when determining whether it is feasible to consolidate existing servers.

• Single-phase upgrades minimize the coexistence periods. These are suitable for smaller organizations. Cutover to Exchange 2010 occurs rapidly organization-wide.

• Multiphase upgrades with coexistence have longer coexistence periods. This upgrade type is suitable for larger organizations. Parts of the organization are moved across to Exchange 2010 in stages, rather than all at once.

• If an organization needs to support Outlook 2003 clients, it will be necessary to retain a public folder infrastructure after the upgrade to Exchange 2010 is complete.

• When performing an upgrade, Internet-facing sites must be upgraded before sites that do not have a direct Internet connection.

• When upgrading from Exchange 2003, Exchange 2007, or a mixture of Exchange 2003 and Exchange 2007, introduce CAS to a site first, then Hub Transport, and then Mailbox servers. Add Edge Transport servers at Internet-facing sites as appropriate.

• Remove Exchange 2003 back-end servers first, but only after you have migrated all mailbox and public folder data from these servers.

• The Exchange Server Deployment Assistant can analyze a current environment to determine whether it meets the necessary infrastructure.

Objective Review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. You are in the process of planning a migration from Exchange Server 2003 to Exchange Server 2010. As part of your migration you want to consolidate your Exchange deployment onto fewer servers. You have purchased new hardware for an Exchange Server 2010 test deployment that reflects the hardware profile of the servers you will eventually deploy. In your new deployment, the Hub Transport, Mailbox, and Client Access Server roles will all be located on the same server. You need to determine how many client computers can use this server as part of your consolidation planning. Which of the following tools can you use to accomplish this goal?

   1. Exchange Server Load Generator 2010

   2. Exchange Server Jetstress 2010

   3. Exchange Remote Connectivity Analyzer

   4. Exchange Server Best Practices Analyzer

2. You are planning a transition from an environment running Exchange Server 2003 to Exchange Server 2010. You are planning on a coexistence period of approximately four months where both messaging systems must run side by side. Which of the following Exchange Server 2010 roles must you plan to install first?

   1. Hub Transport server

   2. Mailbox server

   3. Client Access Server

   4. Edge Transport server

3. You are planning the transition from Exchange Server 2003 to Exchange Server 2010. You will be deploying each Exchange Server 2010 role on a separate computer. You are working on the deployment order plan for each role. Which of the following Exchange Server 2010 roles would you deploy after all the others have been deployed?

   1. Mailbox server

   2. Client Access Server

   3. Hub Transport server

   4. Edge Transport server

4. You are planning a transition from an environment running Exchange Server 2007 to one running Exchange Server 2010. You expect the transition to take approximately three months. Your organization intends to keep using public folders, but you intend to use a third-party appliance as a mail gateway rather than an Edge Transport server. Which of the following Exchange Server 2010 roles must you deploy prior to starting to move mailboxes hosted on Exchange 2007 mailbox servers to Exchange 2010? (Choose all that apply.)

   1. Client Access Server

   2. Hub Transport server

   3. Mailbox server

   4. Edge Transport server

5. You are in the process of planning an upgrade of a mixed Exchange 2003 and Exchange 2007 environment to Exchange 2010. Which of the following tools can you use to analyze your organization’s environment to determine whether the existing infrastructure is prepared for the deployment of Exchange Server 2010?

   1. Exchange Remote Connectivity Analyzer

   2. Exchange Best Practices Analyzer

   3. Exchange Pre-Deployment Analyzer

   4. Exchange Server Jetstress 2010