Factors to Consider Before Upgrading | Mastering Microsoft Exchange Server 2007 SP1

Are you ready to upgrade? Not so fast! Before you pull the trigger and pop the Exchange 2007 installation media into the drive, you need to consider a few factors. Let's take some time to go over them in more detail so that your upgrade is successful.

Prerequisites

Before you can begin upgrading your Exchange organization, you have to ensure that it meets the necessary prerequisites. We've gone over some of these already in previous chapters from the context of a fresh install of Exchange 2007, but let's look at them again with a fresh eye, thinking about how your existing Exchange deployment may affect your ability to meet them.

Hardware and Operating System

For production use, you must have x64-compatible hardware - systems with one of the following types of processors:

The Opteron processor line, made by AMD, is found in high-end servers hardware. AMD also makes Athlon 64 processors that are meant for inexpensive servers and high-end workstations.
Intel offers both its Xeon and Pentium line of processors with the Extended Memory 64 Technology (EM64T) extensions. The Xeon family is typically found in high-end servers, while the Pentiums are found in low-end servers and workstations.

Note

The Intel Itanium processor line is not compatible with Exchange 2007. Unlike some other Microsoft restrictions, this isn't just a case of being a supported configuration; the Itanium processors are not compatible with the x64 specification and Exchange 2007 has not been compiled against the Itanium family of CPUs.

Nowadays, multi-core processors are increasingly common - both Intel and AMD. Although Windows recognizes multiple cores as separate processors when managing processes and threads, Microsoft licensing does not make a distinction between single-core and dual-core processors. This is to your benefit, because Exchange will certainly benefit from additional cores.

You can run Exchange 2007 on any of the following versions of Windows Server:

Windows Server 2003 x64 Standard Edition with SP1 or later applied
Windows Server 2003 x64 Enterprise Edition with SP1 or later applied
Windows Server 2003 R2 x64 Standard Edition
Windows Server 2003 R2 x64 Enterprise Edition

At press time, Windows Server 2003 SP2 was in the final release candidate stage and is intended to be compatible with Exchange 2007.

Tip

Windows Server 2003 Standard Edition limits you to a maximum of four CPUs. By making use of multi-core processors, you can still use the cheaper Standard Edition while maximizing your server's CPU power, which can be important for some server roles (or for servers that are hosting multiple roles). Remember, though, that if you're planning on deploying clustered mailbox servers, you can't use Windows Server 2003 Standard Edition in clusters.

If you're one of the people using prerelease versions of Windows Longhorn Server (the codename for the next generation of Windows Server), don't even think about trying to use it with Exchange 2007. You shouldn't be using prerelease versions of Windows in production (unless you're directed to by Microsoft as part of one of its special early-adopter programs). However, bitter experience has taught the folks at Microsoft that even when they clearly tell people not to do something, someone out there will do try to do it, so Microsoft has made Exchange 2007 incompatible with Longhorn. Microsoft has, however, stated that Longhorn support will be part of the Exchange 2007 SP1 timeframe. Until then, you can't install Exchange 2007 on Longhorn, nor can you have Longhorn domain controllers in any site that contains an Exchange 2007 server.

When Microsoft first began releasing the specific requirements for Exchange 2007 deployments, no single revelation drew greater attention than the requirement for 64-bit hardware. Even now, many people insist that the lack of support for 32-bit hardware will dramatically increase the final cost of upgrades to Exchange 2007. Microsoft, though, makes the argument that most of the servers sold in recent timeframes already have 64-bit support. As the x64 hardware platform (initially introduced by AMD for its Opteron and Athlon 64 processors, then supported by Intel with the EM64T extensions to its Xeon and Pentium 4 processors) is backward compatible with 32-bit hardware and operating systems, many server manufacturers switched to offering 64-bit hardware regardless of which operating system their customers order.

This doesn't mean you're completely off the hook on the hardware front, however. Even if your current Exchange 2003 servers are running on 64-bit hardware, you can't just pop the Exchange 2007 DVD in and do an in-place upgrade. Why not?

Previous versions of Exchange are all 32-bit only and can't be run on Windows Server 2003 x64. Note that this is not a matter of support; Exchange 2000 and 2003 will not run on 64-bit Windows - period, end of story.
You can't upgrade from Windows Server 2003 x86 to Windows Server 2003 x64. You have to perform a clean install.
Remember that you can't run the 32-bit version of Exchange 2007 in production. The 32-bit version is intended for testing and training and cannot be taken out of trial mode, which means that it will cease to operate after a set number of days.

This means that to reuse existing server hardware, you're going to have to have at least one spare server and be prepared to reinstall Windows and Exchange on your servers as you go. We'll discuss this in more detail in the section "Transitioning Your Exchange Organization" later in the chapter.

Active Directory

Because Exchange 2007 continues to have such a dependence on Active Directory, you need to take a good look at the domain controllers and global catalog servers in your Active Directory forest before starting the upgrade process.

Unlike Exchange 2003, which could use domain controllers running either Windows 2000 Server with the appropriate service pack or Windows Server 2003, Exchange 2007 requires that all of the following domain controllers be running Windows Server 2003 + SP1:

The schema master domain controller. This is usually the first domain controller that you installed in the forest, unless you have moved the schema master FSMO role to another domain controller.
At least one global catalog server in each Active Directory site in your forest where you will be installing an Exchange 2007 server.

Our recommendation is to upgrade all your domain controllers to Windows Server 2003 + SP1, especially if you still have Windows 2000 Server domain controllers. The Active Directory improvements in Windows Server 2003 can help vastly reduce the amount of bandwidth required for Active Directory replication, and several Exchange 2007 features (such as address book browsing in OWA) rely on features in Windows Server 2003 SP1. By making sure you've upgraded all of your domain controllers, you increase the redundancy and resiliency of your Exchange/Active Directory integration.

Tip

It is extremely important that Active Directory be healthy. Exchange 2007 relies directly on your Active Directory site structure for message routing information. In previous versions of Exchange, the Active Directory site design could become decoupled from the Exchange Server routing design.

Whether you upgrade all of your domain controllers or just the minimum number, you need to list all the domains in which you will either install Exchange 2007 or create Exchange 2007 recipient objects such as users, contacts, and mail-enabled groups. For each of these domains, ensure that the domain functional level is set to either the Windows 2000 native or Windows 2003 native level. This ensures that you have no lingering Windows NT 4.0 servers acting as down-level domain controllers via the PDC emulator.

Tip

If you can't upgrade all of the domain controllers in your forest, we recommend at the very least upgrading all of the domain controllers in the sites and domains that will be hosting Exchange servers and recipient objects. Officially, you only need to have a single Windows Server 2003 SP1 global catalog server in each site, but Windows Server 2003 SP1 domain controllers offer many advantages to your organization above and beyond their benefits to Exchange Server 2007.

For Windows 2003 Active Directory forests, there is no direct requirement for the forest functional level as long as each domain that will be used for Exchange 2007 meets the per-domain requirements.

A few additional caveats exist:

If you plan on using OWA and any of your domain controllers are using a non-English version of Windows, you will need to install the hotfix in Knowledge Base article 919166 on each non-English domain controller.
DNS must be configured correctly. In addition, each server that you plan to install Exchange 2007 on cannot have a disjoint namespace; that is, the server's primary DNS suffix (set in the Computer Name tab of the computer's property sheet) must match the DNS name of the domain the server belongs to.
You may want to use 64-bit Windows Server 2003 on your domain controllers for performance increases; however, this is not required.
Assuming similar speeds and models of processor, you should still plan to meet the long-standing recommendation of having a ratio of Exchange processors to global catalog processors in a given site be no higher than 4:1. This helps ensure that global catalog lookups happen quickly enough to keep Exchange responding in a timely fashion.
While it is supported to install Exchange 2007 on a domain controller, we really recommend that you don't do it. Such a combined server is much less resilient to service outages or configuration changes and is much harder to restore in the event of a disaster. If you do go this route, you will have to uninstall Exchange if you ever want to demote the machine from being a domain controller; you cannot run dcpromo once Exchange is installed.

Exchange Version

The final prerequisite you must consider is what mode your legacy Exchange organization is in. By default, these versions of Exchange install in mixed mode even when you did not upgrade from Exchange 5.5. You must upgrade the organization to Exchange 2000 or 2003 native mode. Note that in order to do this, you must ensure the following points:

No Exchange 5.5 servers remain in the organization.
No legacy Exchange Site Replication Service (SRS) instances remain in the organization.
No configured Connection Agreements in the Active Directory Connector (ADC) remain in the organization. In fact, if you still have the ADC in your organization and you have no more Exchange 5.5 servers or legacy Exchange SRS instances, remove the ADC from the organization.

Once you have verified that your Active Directory domains and forest and Exchange organization meet these prerequisites, you can begin the process of installing Exchange 2007 by preparing Active Directory as described in Chapter 4.

Setting the Legacy Routing Server Parameter

In Chapter 4, we briefly mentioned the /LegacyRoutingServer installation option. We'll now cover more about why it exists and what problems it solves.

When you install Exchange 2007 into an existing legacy Exchange organization, you need to address some architectural differences. We said before that Exchange 2007 doesn't use administrative groups or routing groups, and that's almost completely true. Although Exchange 2007 servers don't make use of them, the legacy Exchange servers do require them; in a mixed organization, you're going to have the administrative groups and routing groups created for the older Exchange servers. So far, so good; the Exchange 2007 servers use the new Active Directory site-based architecture and the legacy Exchange servers use the administrative groups and routing groups. Under these conditions, everything is happy until the new Exchange 2007 server tries to interact with a legacy Exchange server.

To deal with this, the Exchange 2007 installer takes several actions to ensure compatibility with legacy Exchange servers:

To facilitate communication with legacy Exchange servers, the Exchange 2007 installer creates a special administrative group the first time it is run in a legacy organization. All Exchange 2007 servers are placed into this special administrative group, which is named Exchange Administrative Group (FYDIBOHF23SPDLT). The Exchange 2007 servers don't use this group, but it will show up, along with all of the Exchange 2007 servers, in the legacy Exchange System Manager.
The installer also creates a special routing group for Exchange 2007 servers, named Exchange Routing Group (DWBGZMFD01QNBJR). As with the administrative group, all Exchange 2007 servers are placed into this routing group, even though they use the native Exchange 2007 and Active Directory site-based routing mechanisms; the group and servers are visible in the legacy Exchange System Manager. The only purpose of this routing group is to force the legacy Exchange servers to use a routing group connector to communicate with Exchange 2007 servers.
The installer also creates a universal security group named ExchangeLegacyInterop in Active Directory. This group is used by Exchange 2007 servers to determine which legacy servers are permitted to submit messages to the default SMTP receive connectors on the Exchange 2007 Hub Transport instances. By default, these connectors require successful authentication and permit message submission only from legacy servers whose computer accounts are in this group, such as the legacy Exchange bridgehead server. We'll go into more detail in Chapter 18 about the various options for Hub Transport receive connectors.
When the first Exchange 2007 Hub Transport role is installed, the installer creates a two-way routing group connector between the Exchange 2007 routing group and a user-selected legacy Exchange bridgehead server. If you use the command-line installer, you use the /LegacyRoutingServer switch to specify which legacy Exchange server to use. You can add additional bridgehead servers to this routing group after the installation is complete, and we'll talk about that in more detail later in the chapter. As with the administrative and routing groups, this connector is visible in the legacy Exchange System Manger.

At first these changes may seem overwhelming, especially if your current Exchange organization consists of only one or two administrative and routing groups. The thought of adding another administrative group and routing group into the mix initially strikes many people as counterintuitive; after all, the point of the move away from them is to simplify things, not clutter them up! Consider for a moment an organization that consists of the following elements:

A single Active Directory forest and domain.
Two sites, imaginatively named Site A and Site B.
A domain controller and global catalog server in each site, for a total of four domain controllers.
An Exchange 2003 organization, consisting of a separate administrative group and routing group for each site. For the sake of argument, we'll say that this administrative and routing group design is a legacy of an earlier upgrade from Exchange 5.5.
Four Exchange 2003 servers in each site: two mailbox servers, a front-end server, and a bridgehead server. This makes a total of eight Exchange 2003 servers.

Now, this organization wants to install Exchange 2007. The goal is to end up with a total of six Exchange 2007 servers: one Mailbox instance, one Client Access instance, and one Hub Transport instance for each AD site. As shown in Figure 5.1, things certainly look messy while they're in the middle of their upgrade.

image from book
Figure 5.1: Logical structures present when Exchange 2007 coexists in a legacy organization

Very scary! They've got administrative groups, routing groups, and Active Directory structures all over the place. Even with at most a total of 18 servers to handle, tracking the multiple overlapping memberships gets ugly. Ah, but when they've completed their upgrade, things are a lot calmer, as shown in Figure 5.2. They've got their two Active Directory sites, a single deprecated Exchange administrative group, and a single deprecated Exchange routing group.

image from book
Figure 5.2: Logical structures simplified when only Exchange 2007 remains

Warning

The names of the Exchange 2007 administrative and routing groups are designed to be unique, something that is not likely to be already present in any legacy organization. Do not rename these groups!

Warning

The Exchange 2007 administrative group and routing group are intended only for Exchange 2007 servers. Do not place legacy Exchange servers in these groups thinking that it will somehow improve interoperability or remove the need for the routing group connector. You will break mail flow because there is no other mechanism for translating between the legacy Exchange routing mechanism and the Exchange 2007 routing mechanism.

Once you've specified the legacy bridgehead server and successfully added the first Exchange 2007 Hub Transport instance into the organization, you can at a later time configure the default routing group connector with additional legacy Exchange bridgehead servers or even create new routing group connectors to simplify the message routing paths in your organization. However, you're going to have to perform these tasks from the Exchange Management Shell; you won't see the legacy routing group connectors listed in the Exchange Management Console.

To see the existing legacy routing group connectors, use the Get-RoutingGroupConnector cmdlet. Its output is shown in Figure 5.3.

image from book
Figure 5.3: Output from the Get-RoutingGroup Connector cmdlet

To add a new legacy bridgehead to an existing legacy routing group connector, use the Set-RoutingGroupConnector cmdlet. Here is an example where we are adding Exchange 2003 servers hnlbh01.somorita.int and hnlbh02.somorita.int and Exchange 2007 servers hnlht03.somorita.int and hnlht04.somorita.int to a routing group connector called E2K7 to E2K3 RGC:

 Set-RoutingGroupConnector -Name "E2K7 to E2K3 RGC" -SourceTransportServers "hnlht03.somorita.int", "hnlht04.somorita.int "-TargetTransportServers    "hnlbh01.somorita.int", "hnlbh02.somorita.int"

This cmdlet ensures that the legacy servers are automatically added to the ExchangeLegacyInterop security group so that SMTP authentication will take place and messages will flow properly.

To create a new routing group connector, use the New-RoutingGroupConnector cmdlet. Here is an example of creating a new routing group connector called E2K7 to Hawaii RG using the Exchange 2003 server hnlbh01.somorita.int and the Exchange 2007 server hnlht01.somorita.net as bridgehead servers.

 New-RoutingGroupConnector -Name "E2K7 to Hawaii RG" -SourceTransportServers "hnlht01.somorita.int" -TargetTransportServers "hnlbh01.somorita.int" -Cost 100 -Bidirectional $True -PublicFoldersEnabled $True

Warning

When you use the New-RoutingGroupConnector and Set-RoutingGroupConnector cmdlets to specify the TargetTransportServers and SourceTransportServers parameters, you need to specify all of the servers you wish to be bridgeheads for the connector. Each invocation of the cmdlet will overwrite the existing parameter.

Connectors

Another area for you to consider as you're getting ready to upgrade to Exchange 2007 is your connectors. In legacy Exchange organizations, you have four basic types of connectors: routing group connectors, SMTP connectors, X.400 connectors, and other foreign connectors to specialized messaging systems such as Lotus Notes and Novell GroupWise. In general, you'll want to treat these connectors in the following fashion:

Routing group connectors Routing group connectors still exist in Exchange 2007 but are meant solely as a means of interoperation with legacy Exchange servers. They will be naturally phased out as you convert your Exchange infrastructure over to Exchange 2007, decommission your legacy Exchange servers, and remove the legacy administrative and routing groups from your organization.
SMTP connectors SMTP connectors provide connections to external SMTP-speaking systems and the Internet; they generally aren't used within legacy Exchange forests unless you have a multiple forest configuration. In Exchange 2007, connectors are divided into receive connectors, which are configured on a per-server basis, and send connectors, which are configured and maintained throughout the organization.

As with the routing group connectors, these legacy SMTP connectors will be phased out as you move your message routing functions off of your legacy Exchange servers to your new Exchange 2007 Hub Transport and Edge Transport servers. We'll talk more about your routing and SMTP connector options, as well as tell you how to configure Exchange 2007 Hub Transport and Edge Transport SMTP connectivity to the Internet, in Chapter 18.
X.400 connectors X.400 connectors are finally gone in Exchange 2007. With the decline and fall of X.400 as a messaging standard, almost all of the X.400 connectors used in legacy Exchange organizations today are used to connect to the MTA service in Exchange 5.5 sites. Since you can't have Exchange 5.5 sites and servers in an organization with Exchange 2007, you'll need to get these sites and connectors removed before beginning your upgrade.

If you've got a non-Exchange X.400 system that you connect to, you'll need to maintain your legacy Exchange server until you can arrange some sort of alternate connection supported natively by Exchange 2007.
Foreign connectors Foreign connectors are dramatically different in Exchange 2007. The new foreign connectors don't try to implement a specific non-SMTP protocol; instead, they require you to define a drop directory on the Hub Transport server or network file share. When messages are routed through this connector, they will be written to the drop directory and the remote gateway software can then pick them up and process them appropriately.

If you're using the Exchange 2000 cc:Mail or MS Mail connectors, or the Exchange 2003 GroupWise or Lotus Notes connectors can't transition to an SMTP connection, then you'll need to keep the relevant legacy Exchange servers in your organization. (Of course, if you're still using cc:Mail or MS Mail, my only question to you is why.)

You'll need to consider your current routing topology, especially if you've got a single routing group in your legacy organization. By default, legacy Exchange servers route messages directly out of their local SMTP virtual server. This default behavior means that, out of the box, Exchange 2000 Server and Exchange Server 2003 servers directly attempt to deliver external messages based on DNS MX record lookups instead of forwarding messages to bridgehead servers. For many small organizations, this behavior is acceptable, and as a result many Exchange administrators never get around to creating an SMTP connector and defining bridgehead servers for their organization.

When you install the first Exchange 2007 Hub Transport instance into your legacy Exchange organization, it creates its own routing group and associated routing group connector, as previously discussed. It also creates a default set of SMTP connectors that are enough to send and receive authenticated SMTP from other Exchange servers in the organization; the send connector is configured with the default SMTP address space of *. You may now find that your organization is suddenly unable to exchange mail with systems outside of your organization.

If this is the case, here's what's happened: You've failed to set an SMTP connector in your legacy Exchange organization. By installing your first Exchange 2007 Hub Transport instance, you've created a routable SMTP connector with the default address space. Your legacy Exchange servers do what they're supposed to do and allow this new SMTP connector configuration to override the SMTP virtual server configuration. Instead of attempting to send externally addressed messages directly to the MX host, the legacy Exchange servers send these messages through the brand-new routing group connector to your new Exchange 2007 Hub Transport server. Even better, the Hub Transport server only has the default connectors, which don't include the configuration necessary to allow unauthenticated traffic to and from the Internet; Exchange 2007 assumes that you'll be using the Edge Transport role to do that, and you'll have to configure it otherwise if you're not going to use the Edge Transport role. Now, all your outbound external mail starts to pile up in the Hub Transport server's queues.

Luckily, the fix for this situation is simple, and you even have three selections from which to choose:

Create an outbound SMTP send connector on your Exchange 2007 Hub Transport server. This may be suboptimal in some instances, but if you're already using an external mail gateway, then you can simply configure Exchange 2007 to pass outbound mail to the appropriate smarthost. We'll cover this option in detail later in Chapter 18.
Deploy an Exchange 2007 Edge Transport server to handle your outbound traffic. If you're upgrading to Exchange 2007 to take advantage of its advanced message hygiene capabilities, we recommend this option; it gets your incoming and outgoing mail going through Exchange 2007 sooner rather than later. Again, we'll talk about this configuration in depth in Chapter 18.
Alternately, create an SMTP connector with the default address space in your legacy Exchange organization before you begin installing Exchange 2007. This option has the advantage that it keeps mail flow in your organization going through a known and trusted set of bridgehead servers until you have your Hub Transport and Edge Transport servers configured and tested. If you have existing legacy Exchange servers configured with mail hygiene solutions, this is probably what you're going to want to select for the short term.

Warning

Don't be afraid or hesitant to continue using your legacy Exchange servers as bridgeheads to the Internet while you're working your way through your Exchange 2007 upgrade. Although we firmly believe that configuring and troubleshooting message flow and routing is much easier with Exchange 2007, you've still got a lot of material to learn and master as you begin to put Exchange 2007 into play. Choose your battles.

Legacy Exchange and Third-Party Services

Another factor you need to consider is whether you are using additional legacy Exchange services that are no longer present in Exchange 2007. We've already covered the case of the various foreign connectors that are no longer part of Exchange 2007, but those aren't the only services and features you need to watch out for.

Previous versions of Exchange included several services that are now supplied by either Windows Server 2003 components or other Microsoft applications. If your organization depends on these, you'll need to keep the appropriate legacy servers around until you can migrate or upgrade the services off the Exchange servers.

Theses services include the following:

Exchange 2000 Conferencing Server
Exchange 2000 Instant Messaging Server
Exchange 2000 Key Management Server
Exchange 2000 Chat Server
Any connectors supported by the legacy Exchange servers but no longer supported by Exchange 2007, such as the X.400 connector and the GroupWise connector

If you are currently using these services and cannot (or will not) upgrade to a Exchange 2007-compatible versions, then you will need to leave the legacy Exchange servers hosting these services intact within your organization.

Warning

If you are keeping legacy Exchange servers in your organization, do not forget to preserve the management consoles and tools necessary to administer the services.

You may also have third-party services that are essential to your organization. Examples of such services include, but by no means are limited to, the following:

Message hygiene add-ins such as spam filters and virus scanners (both for transport and store).
Fax services.
Message discovery, compliance, archival, and retention solutions.
Geo-clustering, mailbox snapshot, and other storage-related solutions.
Transport event sinks, whether commercial or custom. A common event sink is a module to stamp disclaimers on all outbound e-mail.
Conference room and shared resource booking management software.
Mailbox database backup and restore agents.

Of course, there are many other possibilities. The point is that you need to ensure that these products are going to work with Exchange 2007. Some products may work directly with Exchange 2007 already, while others may require an upgrade of their own. In some cases, you may need to switch software packages if your current vendor's product isn't compatible with Exchange 2007 and you require that functionality.

Note

There's always the possibility that you no longer need a given third-party package because new functionality in Exchange 2007 allows you to perform the same task natively.