New information has been added to this article since publication.
Refer to the Editor's Update below.

Exchange Server 2007

Upgrading Your Infrastructure to Exchange 2007

Kate Follis

At a Glance:

• What's new in Exchange 2007
• Preparing for upgrade
• Role-based deployment
• Message routing topology

I used to teach a class about migrating from Exchange Server 5.5 to Exchange 2000 Server. The class would begin at 8:30 in the morning, and end around 6:00 P.M. I would leave the classroom

drained of energy. There was a lot of preparation work involved just to move the directory resources, plus lots of confusion about NTDSNoMatch, and the occasional Windows NT® 4.0 trust that would refuse to be trusted. Due to time constraints, we barely touched on Exchange 2000 Server administration, yet invariably there would be a couple of eager students who planned to leave the classroom Friday night and complete migration over the weekend. I would caution against this, advising more planning time, but I doubt they heeded the warning.

The transition from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 requires the same kind of caution-you need to spend time planning. The actual transition process will vary by organization and the complexity of the current deployment, but the transition process will still require several phases. A small organization may move through these phases as a single project, while a large organization may decide to gradually introduce server roles and support Exchange in a coexistence mode for a period of time. The end-to-end process is designed to maintain messaging functionality and stability through the entire transition period. In this article, I'll focus on the essential steps required to maintain message flow through your organization as you upgrade to Exchange Server 2007.

Considerations

The first requirement to note is that Exchange Server 2007 must be deployed on 64-bit hardware and does not support an in-place upgrade from any previous version of Exchange. You must use the swing upgrade method to move your existing messaging services to Exchange 2007. Further, the Exchange organization must be operating in native mode to support the addition of Exchange 2007 servers, so if your organization is currently using Exchange 5.5, you will be required to perform an interim upgrade to Exchange Server 2003 before moving to Exchange 2007.

There are some important changes in Exchange 2007 you must consider when planning your transition. For example, Exchange 2007 introduces role-based deployment, which lets you choose the messaging services you want to provide and deploy server roles specific to those services. You can deploy the server roles individually on dedicated hardware, or install multiple roles on the same physical server, administered as separate entities. See the sidebar "Exchange 2007 Server Roles" for an explanation of each.

Exchange Server 2007 Server Roles

Mailbox Server The Mailbox server role provides message storage for an organization. Exchange 2007 can support up to 50 stores per server. These stores can be deployed as 50 individual storage groups, or you can create up to 50 stores in a single storage group. The Mailbox server role is the only role that can be deployed as a cluster, so if you will be using clustering, you will need to install the Mailbox server on dedicated hardware.

Client Access Server The Client Access server role replaces the functionality provided by a front-end server. It provides mailbox access to clients accessing Exchange using POP3, IMAP4, Outlook® Web Access (OWA), RPC over HTTPS (now known as Outlook Anywhere), and Exchange ActiveSync®.

Hub Transport Server This role provides SMTP and MAPI message transport services for the Exchange organization. Every message that is sent or received by the users in your organization is processed by a Hub Transport server. This is great, because it ensures that no message can bypass the server-based rules or journaling policies that are provided by agents that fire at various points in the transport pipeline.

Unified Messaging Server This role provides voice access to your mailbox. It integrates with your IP/VoIP gateway or IP-PBX to provide telephone access to messages and calendar items and lets you transcribe a reply. This role is new to Exchange, and is not able to interoperate with any previous versions of Exchange.

Edge Transport Server The Edge Transport server is typically deployed in your perimeter network. It provides SMTP message transport between the Exchange organization and the Internet, and provides anti-spam and antivirus processing using transport agents. You can now standardize on a single technology for both your organizational and perimeter network servers. This seamless interaction model simplifies administration and allows for easy integration of perimeter servers.

Examine Your Topology

So, where do you begin? Well, it's difficult to figure out where you are going unless you know where you are. Take time to assess your current environment and to document the topology-not only Exchange but also your Active Directory® environment. You'll probably be pleased to know that Exchange 2007 has done away with link state routing and the topology based on routing groups and connectors. Instead, Exchange 2007 takes advantage of the investment your organization has already made in designing the Active Directory topology. As a result, all Exchange recipient and configuration data is stored in Active Directory, the routing topology is derived from the Active Directory site configuration, and all server roles will use site awareness to discover the services running on other server roles.

Make sure that the current Active Directory site topology truly leverages the underlying physical network and that all Active Directory sites have associated subnets, then document the existing Active Directory sites and IP site links. Also document where all of your Exchange 2003 servers are physically located, and the routing group and routing group connector structure.

This is the trickiest part of the transition process: moving from an Exchange routing infrastructure based on routing groups to a routing infrastructure based on Active Directory sites. For a small organization, it's generally a simple process. But a large organization with many routing groups will need to plan carefully for an interim phase when Exchange 2003 and Exchange 2007 are coexisting. The last thing you want is to end up having a message sent to your Exchange 2003 mailbox from the Exchange 2007 user across the hall routed through some remote routing group over a low bandwidth connection.

Let's start by making some assumptions about your current topology:

• The Exchange 2003 organization is running in native mode.
• You have more than one routing group.
• You have more than one Active Directory site.

Figure 1 diagrams an Exchange and Active Directory topology. Remember, the more details you include in your preliminary plans, the better your design will be.

Figure 1** An Exchange and Active Directory Topology **(Click the image for a larger view)

How Exchange 2007 Uses Active Directory

When an Exchange 2007 server starts, it is stamped with a site attribute that helps other Exchange 2007 servers locate the services provided by that server. Only the Hub Transport server can use SMTP to transport a message within the organization. Each Active Directory site that contains a Mailbox server must also contain a Hub Transport server and, if the mailbox users access their mailbox by using any non-MAPI method, each site must also contain a Client Access server. Any time that a message needs to be processed for delivery, it will pass through a Hub Transport server, which will make a decision about how the message should be routed. If the message is destined for a Mailbox server in the same Active Directory site as the Hub Transport server, the Hub Transport server will deliver the message to the mailbox. If the message is destined for a Mailbox server that's in a different site, the Hub Transport server will relay the message directly to a Hub Transport server in the remote site.

The Hub Transport server uses the Active Directory IP site link cost information to calculate the lowest-cost route to the Active Directory site where the recipient mailbox is located. The route selection algorithm is very similar to Exchange 2003, but it's based on IP site link costs instead of routing group connector costs. Moreover, the message does not stop at each Hub Transport server along the way. It goes directly from source to destination. So why does it bother to calculate the lowest-cost route if it's relying on the IP network to transport the message? There are a couple of reasons. One is to delay message bifurcation. A message that is being sent to more than one recipient may need to be delivered to Mailbox servers in more than one Active Directory site. Rather than bifurcate, or split, the message at the first Hub Transport server, Exchange 2007 will not split the message until it reaches a fork in the routing path. As a result, the message will be relayed directly to a Hub Transport server in the Active Directory site that represents the bifurcation point. This behavior is known as delayed fan-out.

The lowest cost route is also used to determine where to queue the message in case the destination can't be reached. If a Hub Transport server in the target Active Directory site can't be reached, the sending Hub Transport server will then attempt delivery to a Hub Transport server in the next closest Active Directory site according to the routing path. Message delivery will continue along the lowest cost route until it reaches an Active Directory site where a Hub Transport server is available. Finally, if no Hub Transport servers along the route to the recipient Active Directory site are available, the message is queued locally. This method queues the message as close to the delivery point as possible, helping to make diagnosis of network failures more deterministic. This behavior is known as queue-at-point-of-failure.

Exchange 2003 works in a completely different manner. It calculates the lowest-cost route from one routing group to another based on the costs assigned to the routing group connectors. A bridgehead server in each routing group along the routing path will receive and then relay the message. If the next connector in the path is not available, an attempt is made to calculate an alternative route. Link state update messages are also communicated throughout the Exchange organization to notify the other Exchange servers that the connection is down. The bridgehead servers will attempt to route around the down connector until a link state notification is received indicating that the connection is up.

The challenge when transitioning a large organization is to maintain mail flow during the coexistence period. To achieve this continuity when Exchange 2007 is introduced into the environment, all Exchange 2007 servers become members of a single routing group. This means that regardless of which Active Directory site the Exchange 2007 server is in, Exchange 2003 will see it as belonging to that single routing group. This allows you to establish a routing group connector between that routing group and the Exchange 2003 routing groups so that Exchange 2003 can figure out how to route messages to Exchange 2007. Exchange 2007 will also use the routing group connector to determine how to get messages to Exchange 2003. However, Exchange 2007 will always prefer to route a message through another Exchange 2007 server, and will never backbone across an Exchange 2003 routing group to reach another Exchange 2007 server.

Introducing the First Exchange 2007 Server

When you install the first Exchange 2007 server into the Exchange 2003 organization, you will need to select an Exchange 2003 bridgehead server with which to establish the first routing group connector.

Figure 2 shows how the introduction of the first Exchange 2007 server affects the organization topology.

Figure 2** Installing the First Exchange 2007 Server **(Click the image for a larger view)

So far, so good. Notice that the default cost of the routing group connector created by Exchange 2007 is only 1. Mail continues to flow as usual through the Exchange 2003 servers, and if a message is sent to a user on the Exchange 2007 server from any Exchange 2003 server, it will flow through the Acapulco routing group. When the routing group connector was created, the Exchange 2003 bridgehead server you selected became a member of the ExchangeLegacyInterop universal security group automatically and was granted the correct permissions to send and receive e-mail messages to and from Exchange 2007. You must always use the New-RoutingGroupConnector in the Exchange Management Shell to create a routing group connector whenever an Exchange 2007 server is specified as a source or target server for the connector. You can also use the Set-RoutingGroupConnector cmdlet to modify the configuration of a routing group connector. For example, you may want to add source and target servers to the initial routing group connector to provide redundancy. (See David Strome's article on the Exchange Management Shell in this issue of TechNet Magazine for more information.)

Prepare to Move Some Mailboxes

The next step is to move some mailboxes from the Exchange 2003 servers to the Exchange 2007 servers. Use the Move-Mailbox cmdlet to accomplish this. Before you can decommission the Exchange 2003 servers, however, you'll want to create Send and Receive connectors on the Exchange 2007 server to replace any SMTP connectors that were defined on the Exchange 2003 server to handle routing to external SMTP address spaces.

In the next diagram, the resources from the Acapulco routing group have been moved to Exchange 2007. The Acapulco routing group can be decommissioned, but this means you have to establish a routing group connector to a different routing group now. In Figure 3 I have configured the routing group connector to a bridgehead server in the Miami North routing group.

Figure 3** Configuring the Routing Group Connector **(Click the image for a larger view)

Let's move on to transitioning the LA East Routing Group to Exchange 2007. This is the kind of situation when maintaining routing gets a little tricky. In Figure 4, Exchange 2007 has been installed in the Los Angeles site, and a second routing group has been decommissioned, but no additional routing group connectors have been created.

Figure 4** Exchange 2007 Intsalled in the Los Angeles Site **(Click the image for a larger view)

Now, if a message is sent from the Exchange 2007 server in the Los Angeles site to the Exchange 2003 server in the LA West routing group, it will be relayed first to Acapulco, then to Miami North, to Miami South, and finally to LA West. If a message is sent from the Exchange 2003 server in the LA West Routing Group to the Exchange 2007 server in the Los Angeles site, it will be relayed first to Miami South, then to Miami North, to Acapulco and then finally arrive back in Los Angeles. Ouch.

In order to avoid this, we'll need to add a second routing group connector. Figure 5 shows the addition of a routing group connector from LA West to the Exchange 2007 server at the Los Angeles site. Note: If you want to avoid an abundance of routing group connectors, make sure that your first routing group connector is configured in a well-connected hub Active Directory site.

Figure 5** More Efficient Routing **(Click the image for a larger view)

This introduces a problem that may not be immediately apparent. There is now more than one way in and out of the Exchange 2007 routing group. Since the Exchange 2007 routing group does not use link state, a potential routing loop now exists. The Exchange 2003 server may select an alternative route to go around a down connector, while Exchange 2007 will always select the lowest-cost route. The way around this problem is to suppress minor link state update messages, which will prevent link state messages that communicate a down connector state but will not prevent link state messages that communicate configuration changes. This is important, because we want the Exchange 2003 servers to know about the new routing group connectors, but we don't want them to try to calculate an alternative route. The end result is that the Exchange 2003 servers will exhibit the same queue-at-point-of-failure behavior as the Exchange 2007 servers.

In Figure 6 we have transitioned more Exchange 2003 resources to Exchange 2007. Link-state updates have been suppressed and we have been careful to establish routing group connectors that maintain a logical routing path.

Figure 6** More Exchange 2003 Resources Move to Exchange 2007 **(Click the image for a larger view)

There's another problem, though. We've created link-state islands in Redmond and Vancouver. Mail can flow just fine, albeit through Miami, but there's no way for Redmond and Vancouver to communicate link-state configuration changes.

[**Editor's Update - 12/19/2006:**This sentence originally stated that Redmond and Miami had no way to communicate link-state configuration changes. This has been corrected to read that Redmond and Vancouver have no way to communicate link-state configuration changes.]

To maintain a current routing table, you'll need to configure another routing group connector between Redmond and Vancouver. You can adjust the cost of this routing group connector so that it is high enough to prevent Exchange 2003 from routing over the connection, while still allowing link-state configuration changes to be communicated.

With careful planning, you can circumvent the problems that may arise from maintaining two separate Exchange routing topologies. You'll achieve the most seamless results by transitioning one routing group at a time and then moving on to the next, until you are running only Exchange 2007 servers.

So far, I've focused on the routing changes in Exchange 2007 and how they will affect your transition. There are a couple of other considerations to bear in mind when planning the move to Exchange 2007.

Exchange 2003 front-end servers can't access Exchange 2007 mailboxes. However, an Exchange 2007 Client Access Server has no problem connecting you to your Exchange 2003 mailbox. When using the Exchange 2007 Client Access Server, you'll simply see the same OWA version as the mailbox server where your mailbox is stored. If you are deploying Exchange 2007 on separate hardware, the Client Access Server should be the first role you introduce to an Active Directory site. Any Exchange 2003 front-end servers that provide public Internet access to mailboxes should be replaced with Exchange 2007 Client Access Servers before any mailboxes are moved to Exchange 2007.

I mentioned before that each site that contains the Mailbox server role also requires the Client Access Server role (if you have non-MAPI clients-and who could live without OWA these days?) and a Hub Transport server. So, if you're going to have your server roles share hardware, be sure to include the Client Access Server in the role selection. A typical installation will include the Hub Transport Server role, the Client Access Server role, and the Mailbox server role-all that you need for a fully functional Exchange environment.

Another consideration for the transition process is when to upgrade your client application (Outlook). You will not be able to take full advantage of all Exchange 2007 server features until your clients have been upgraded to Outlook 2007. This includes enhanced out-of-office message settings and managed mailbox folder features.

You will also need to decide when to deploy the Edge Transport server role. Technically, you can supplant your current perimeter network SMTP-relay and smart host with the Edge Transport server before or after introducing any other Exchange 2007 server roles. If you deploy the Edge Transport server first, however, the overall functionality will be limited because Exchange 2003 has no way to replicate the recipient and configuration data that the Edge Transport server needs from Active Directory to ADAM (Active Directory Application Mode).

After you've installed at least one Hub Transport server, you can deploy the Edge Transport server in the perimeter network and then subscribe the Edge Transport server to the Active Directory site where the Hub Transport server resides. The EdgeSync service on the Hub Transport server will replicate a subset of the recipient data in Active Directory to ADAM.

This data allows the Edge Transport server to perform recipient-lookup and safelist aggregation so that you can take full advantage of the anti-spam agents running on the Edge Transport server. In addition, EdgeSync will create the Send connectors that are required for end-to-end mail flow to and from the Exchange organization and the Internet. This can simplify the process of replacing the Exchange 2003 SMTP connectors that provide routing to external address spaces.

So, take a little time to plan your transition to Exchange 2007 and you'll find the route straightforward and pain-free.

Kate Follis is a Senior Content Publisher on the Exchange 2007 technical writing team. Her group specializes in the Edge Transport and Hub Transport server roles. Prior to joining Microsoft, Kate worked as a Microsoft Certified Trainer for several years, teaching Exchange and Active Directory.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.