Choosing Your Strategy


Now that you've considered the various factors that could affect your upgrade, you need to figure out which strategy you're going to use. As we mentioned earlier, you have two main choices: migration or transition, as Microsoft calls them. Although neither option gives you the relative ease of the traditional in-place upgrade, each option has its own pros and cons. In the following sections, we'll review them briefly and then move on to a more in-depth discussion.

Comparing the Strategies

If you're like many readers, you've probably got at least some preference for your upgrade strategy already in mind. Before you set that choice in stone, though, read through this section and see whether there are any surprises (good or bad) that might allow you to address some aspect of the upgrade that you hadn't previously considered. If, on the other hand, you're not really sure which strategy would be best for you, then this section should help give you enough information to begin making a well-informed decision.

Let's start by taking a look at an overview of how the two strategies stack up. Table 5.1 lists several points of comparison between the migration and transition strategies.

image from book
Table 5.1: Comparison of Exchange 2007 Upgrade Strategies
Open table as spreadsheet

Point of Comparison

Migration Strategy

Transition Strategy

Tools

You will need a combination of free Microsoft tools to manage the multiple sets of data that need to be migrated (Active Directory user information and Exchange mailbox data at a minimum). These tools usually result in at least some minor information loss. Alternately, you can spend extra money to purchase and use third-party tools.

You can use the built-in tools in Exchange 2007 and Windows Server to control all aspects of the transition, from building the new servers, reconfiguring Active Directory, or moving mailbox data.

Hardware

You will usually require a significant amount of new hardware. You may not need to have a complete spare set of replacement hardware, but you'll need enough to have the basic infrastructure of your new Exchange 2007 organization in place.

You can accomplish this strategy with a minimal amount of new hardware, typically no more than one or two extra servers, as long as your existing servers are 64-bit ready. Otherwise, you will need new hardware for your Exchange 2007 servers.

Active Directory and DNS

You must create a new Active Directory forest. Typically, this means that you cannot reuse the same AD and DNS domain names (although you will be able to share the same SMTP domain names).

You can make use of your existing Active Directory and DNS deployment; however, you will first need to upgrade your existing domain controllers and global catalogs to meet the prerequisites.

User accounts

You must migrate your user accounts to the new AD forest or recreate them.

Your users will be able to use their existing accounts without any changes.

Message routing

Your SMTP domains must be split between your legacy organization and your new organization; one of them must be configured to be nonauthoritative and route to the other. This configuration may need to change during the course of the migration. Additionally, you must set up explicit external SMTP connectors between the two organizations or play tricks with name resolution.

Your organization continues to be a single entity, with full knowledge of all authoritative domains shared among all Exchange servers. Message flow between organizations can be controlled by the simple addition of bridgehead servers to the default legacy routing group connector or the creation of additional legacy routing group connectors to meet the needs of your topology.

Outlook profiles

You will either need to create new Outlook profiles (either manually or using the tools found in the matching version of the Microsoft Office Resource Kit) or use third-party tools to migrate them over to the new organization. This may cause the loss of information.

As long as you keep the legacy mailbox servers up and running during an appropriate transition phase, Outlook will transparently update their your users' profiles to their new mailbox server the first time they open it after their mailbox is moved to Exchange 2007.

Single-instance storage

Removing mailbox information from the organization to move it breaks single-instance storage. In order to preserve it, you'll need to look at buying third-party migration tools.

The mailbox movement tools included in Exchange 2007 will preserve single-instance storage as mailbox data is moved to the new Exchange 2007 servers and storage groups.

image from book

For the most part, Table 5.1 speaks for itself; if any point requires more in-depth discussion, we'll address it properly during the detailed sections that follow.

Migrating Your Exchange Organization

From the overview given in Table 5.1, it may seem as if we have a grudge against upgrading to Exchange 2007 by using the migration strategy. Although we have to admit it's not our favorite strategy, we'll hasten to say that migration offers many advantages that a transition upgrade doesn't offer:

  • It is the only realistic way to consolidate two or more separate Exchange organizations into a single organization. This kind of consolidation can happen as the result of a major reorganization inside of one company or as the result of merger or acquisitions.

  • It allows you to set up a greenfield (a term used to denote the ideal state of implementation) deployment of Exchange 2007. No matter how conscientious you are as an admin, any real network represents the product of a number of design compromises. After a while, the weight of those compromises and workarounds add up; the design and structure of your network can reflect imperatives and inputs that no longer exist, or are no longer relevant, in your organization. It's nice to be able to wipe the slate clean, especially if that ends up being less work than trying to start with your current mess and clean it up.

  • It permits you to move your Exchange servers out of your existing Active Directory forest and establish them in their own forest. If you're in an environment that separates administrative control between Active Directory and the Exchange organization, having a separate forest for Exchange can make it a lot easier to accomplish many of the day-to-day management tasks on your servers. (We don't know about you, but we'd much prefer to have control of the OU structure and Group Policy objects that affect our Exchange servers.) If the benefits of a multi-forest deployment outweigh the drawbacks, then this configuration may actually improve the efficiency of the split between directory/account administration and Exchange administration.

  • It gives you the chance to easily define new policies and procedures that apply equally to everyone, from account provisioning to server naming conventions. With the importance of regulatory compliance and strong internal IT controls and auditing rising on a daily basis, this can be a strong motivator.

  • It allows you to perform additional configuration and testing of your new organization before you move the bulk of your live data and users to it. Being able to perform additional validation, perhaps with a pilot group of users, gives you additional confidence in the strength of your design and affords you extra opportunities to spot problems and correct them while you can.

  • It gives you the ability to ensure that the new environment is properly locked down and secured. Exchange 2007 provides support for the Security Configuration Wizard, a new tool included with Windows Server 2003 SP1 and Windows Server 2003 R2 that permits administrators to easily and automatically harden and lock down servers based on what roles they play. When this tool is combined with the ability to define and configure a fresh set of Group Policy objects, a new organization can take advantage of security technologies and techniques that might be extremely difficult to deploy in your current environment while ensuring that your Exchange 2007 servers can still communicate with your legacy Exchange servers, your Active Directory infrastructure, and your users' machines.

Now that we've said that, we should point out that a migration strategy usually involves more work, more money, or both. Sometimes, though, it's what you have to do.

Let's take a look at what a migration might look like:

  1. Deploy a new Active Directory forest and root domain, as well as any additional domains. These will probably be named something different than the domains in use in our current network so that we can operate in both environments (and our users can as well). We could be using this forest as an Exchange resource forest, or we could be moving all of our servers and desktops as well. Because migrations don't happen overnight, we'll probably need some sort of forest trust between our forests so that accounts and permissions will work properly while the work is in progress. This step is outside the scope of this book.

  2. Migrate a suitable set of user accounts to the new forest. Perhaps we're concentrating on one site at one time to minimize confusion; if so, we need to migrate each user account in the site to the corresponding site in the new Active Directory forest. Again, this step is outside the scope of this book.

  3. Install Windows Server 2003 x64 + SP1 and Exchange 2007 on a suitable number of 64-bit servers to form the core of our new Exchange 2007 organization. We don't need to have new servers for everything, but we usually need to have at least a site's worth of equipment on hand. We'll need to configure SMTP connectors between the two organizations, and we'll need to have some sort of directory synchronization going on between the two forests so that as users get moved into the new forest, each global address list (GAL) is properly updated to ensure that internal mail is delivered to the right Exchange organization. We'll probably need to configure public folder synchronization so that free-busy data is shared between the two organizations as well.

  4. Move the mailbox data for the site from the legacy Exchange mailbox servers to the new Exchange 2007 mailbox servers. We'll need to update our users' Outlook profiles so that they can get to their mailboxes, and we'll need to ensure that the GAL information is updated so that mail follows these users to their new mailbox servers. Once everything is working, we can remove the legacy Exchange servers from this site.

  5. Let's not forget that we may need to join our users' desktops, as well as any other Windows member servers (such as file/print, database, and web servers) to the new forest if it isn't being used exclusively as an Exchange resource forest. This step is outside the scope of this book.

  6. Continue this process one site at a time until we've moved all of our user accounts and mailbox data into the Exchange 2007 organization and have decommissioned the remaining legacy Exchange servers.

Now you can see why we consider the migration strategy to be the labor-intensive route. You don't have the luxury of accepting your existing Active Directory structure and accounts. While you can move message data over to a new organization, there's more effort involved in making sure users' profiles are properly updated; or you can rebuild your users' profiles and accept some data loss. If you're upgrading the desktop clients to Outlook 2007, you have the additional worry of whether you need to move the desktop machines into a new forest.

On the other hand, if you have an Active Directory deployment with serious structural problems (whether through years of accumulation or the results of previous mistakes), if you need to extract your Exchange servers into a separate Active Directory forest, or if there is some other reason transitioning your existing organization isn't going to work for you, then migration has a lot to offer.

Migrations require you to keep track of a lot of details and separate types of information. While you can migrate all of the important information - mailboxes, public folders, global address list data - using the freely available Microsoft tools, you'll have a harder time migrating some of the smaller details that aren't mission critical but nonetheless can add up to a very negative user experience. If the users' first experience on the new messaging system is having to reconfigure Outlook with all of their preferences, they're going to be less than happy about the experience. The cost of third-party migration tools may well prove to be a good investment that saves you time, reduces your complexity, and gains you the goodwill of your users.

Transitioning Your Exchange Organization

The process of transitioning your legacy Exchange organization to Exchange 2007 in many ways resembles the process required to upgrade from Exchange 5.5 to Exchange 2000 or Exchange 2003. If you have experience in that particular upgrade, relax; transitioning to Exchange 2007 is much easier. You're using Active Directory, so no directory upgrade or synchronization is required. You're not multiplying the number of organizational structures required, as the transition from Exchange 5.5 sites to Exchange 2000 administrative groups and routing groups did. You're not changing from the X.400-based MTA protocol to SMTP. All you're doing is moving mailboxes and public folder information, so it's easy. Well, as easy as these projects get.

Let's take a closer look at the average transition to Exchange 2007.

An Overview of Transition

Let's imagine that we have an Exchange 2003 organization that has eight mailbox servers, two front-end servers, and two bridgehead servers that handle all SMTP traffic with the Internet. For the sake of illustration, we'll stipulate that all of our existing Exchange servers are already on 64-bit hardware; we have spares that we plan on using during the transition to keep our new hardware costs to a minimum.

In this organization, the transition process would look something like this:

  1. Ensure that our organization meets all the prerequisites, including upgrading at least one Active Directory domain controller in each Active Directory site to Windows Server 2003 SP1 if they're not already at that level. We go ahead and run the Active Directory preparation to upgrade the forest schema with the Exchange 2007 extensions and to create the proper objects in the domains.

  2. Install the first Exchange 2007 Client Access instance into our organization. Once it is configured, we can bring it into production use and decommission the first Exchange 2003 front-end server. We can then reuse this hardware to install the second Exchange 2007 Client Access instance and decommission the second Exchange 2003 front-end server.

  3. Install the first Exchange 2007 Hub Transport instance into our organization. This instance could be on the same 64-bit machine as one of the Client Access instances (or as an intended Mailbox server) or on a separate machine; however, both the Client Access and Hub Transport roles need to exist before we install our first Exchange 2007 Mailbox instance. We also install an Exchange 2007 Edge Transport server on a separate machine. We configure the Edge Subscription connection between the Edge Transport server and the Hub Transport server and establish the send connector. We can now remove the first Exchange 2003 bridgehead server.

  4. Install the second Exchange 2007 Hub Transport instance. We can either install a second Edge Transport server or live with the existing one. Once the second Hub Transport instance (and second Edge Transport server, if deployed) is in production, we reconfigure our SMTP connectors so that our Edge Transport servers are now handling all external SMTP traffic. We then retire the second Exchange 2003 bridgehead server.

  5. Install Windows Server 2003 x64 + SP1 on our spare 64-bit mailbox server hardware. Install Exchange 2007 on it as the first Exchange 2007 Mailbox instance in the organization.

  6. Move the mailboxes from the first Exchange 2003 mailbox server onto the first Exchange 2007 Mailbox server. Remove the first Exchange 2003 mailbox server from the organization.

  7. Perform a clean install of Windows Server 2003 x64 + SP1 on this server and then install the Exchange 2007 Mailbox instance. Move the mailboxes from the second Exchange 2007 server onto this new Mailbox instance.

  8. Continue the process in Step 7 one server at a time until we've moved all mailboxes onto Exchange 2007 Mailbox instances and we have no remaining Exchange 2003 mailbox servers left in the organization. At this point, we'll have the same number of spare servers we started with. If they are 64-bit machines, we can install some other Exchange 2007 role on them.

It sounds like a lot of work, but there are many people who have favored this kind of approach even in previous upgrades to Exchange. It gives you the advantage of having a clean installation of Windows to work with and allows you to ensure that the configuration of the operating system is exactly the way you want it.

Order of Installation for Exchange 2007 Roles

Microsoft makes some specific recommendations on the order in which you should install the various roles. Technically, you can install your roles in any order you like. However, following Microsoft's recommendations allows you to minimize the deployment of new server hardware and get the most reuse value from your existing servers if that's a major consideration in your upgrade plans.

Note 

Microsoft's recommended order ensures that as each role is installed it can locate the prerequisite roles it depends on for proper function. You do not, however, need to install all instances of a particular role before beginning to deploy instances of the next role. You can always go back and install additional instances of any role as you scale up a site.

Client Access Servers

The Client Access role should be the first Exchange 2007 instance you install into a legacy Exchange organization. The reason for this is simple: once you actually have mailboxes on Exchange 2007 servers and your users attempt to access them using any protocol other than MAPI over RPC, you will need to have an Exchange 2007 Client Access instance to provide that protocol access. The Exchange 2007 Client Access role can also provide access to legacy Exchange mailboxes in much the same fashion that an Exchange 2003 front-end server provides access to both Exchange 2003 and Exchange 2000 mailbox servers. This allows you to switch client and web protocol access to Exchange 2007 and decommission your legacy front-end servers. In contrast, a legacy Exchange server cannot provide front-end or client protocol access to a server running a newer version of Exchange.

In smaller organizations, it is common to deploy the Client Access, Hub Transport, and Mailbox roles on the same physical server. In fact, this is the standard Exchange 2007 installation option when you use the GUI setup.

Tip 

Upgrading the front-end servers first has long been an Exchange best practice; even when applying service packs, you always want the front-end server running the most recent version of Exchange. Although the Client Access role isn't exactly the same thing as a front-end server, this rule of thumb still applies in Exchange 2007.

Warning 

The Client Access role cannot be placed on clustered hardware. If you plan to use a clustered Mailbox server configuration, you must place this role on a separate non-clustered machine (which can of course be shared with other roles such as Hub Transport).

When you are determining the number of Client Access instances you need, remember that you must have at least one Client Access instance in each Active Directory site where you will have an Exchange 2007 mailbox. Although any Client Access instance can answer an incoming request, if the requested resource is on a Mailbox server that is not in the same site as the initial Client Access instance, it will redirect the request to an available Client Access instance in the Mailbox server's Active Directory site.

This role is mandatory in an Exchange 2007 organization - unless you never plan on using any protocol to access your mailboxes other than Outlook in MAPI over RPC mode. If you use POP3, IMAP, or any of the HTTP-based protocols (OWA, Outlook Anywhere/RPC over HTTPS, or Exchange ActiveSync), you must have the Client Access role in your organization.

Hub Transport Servers

The Hub Transport role is the next logical role to install. Under the new Exchange 2007 architecture, Mailbox servers are no longer responsible for transporting messages directly. This task is now handled by the Hub Transport role. Likewise, all SMTP traffic with other routing groups and external systems is routed through Hub Transport instances. Even if you installed Exchange 2007 Mailbox servers first, they would literally be unable to communicate with any other Exchange servers until an Exchange 2007 Hub Transport instance was installed in the same site. If multiple Hub Transport instances are available in the same site, Exchange 2007 will automatically load-balance SMTP traffic across the available instances.

In smaller organizations, it is common to deploy the Client Access, Hub Transport, and Mailbox roles on the same physical server. In fact, this is the standard Exchange 2007 installation option when you use the GUI setup.

Tip 

If you are considering colocating the Hub Transport role on the same physical server as the Mailbox role, remember that Mailbox instance will always attempt to use the Hub Transport instance that is on the same physical server and only connect to other Hub Transport instances if there is a problem. This can cause problems with the automatic load balancing in a site with multiple Mailbox servers.

Warning 

The Hub Transport role cannot be placed on clustered hardware. If you plan to use a clustered Mailbox server configuration, you must place the Hub Transport role on a separate machine (which can of course be shared with other roles).

When you are planning the number of Hub Transport instances you need, remember that you must have at least one Hub Transport instance in each Active Directory site where you will have an Exchange 2007 Mailbox server. As messages are routed to recipients in the organization, the Hub Transport instance that is processing the message looks up the mailbox data in Active Directory. If the mailbox is in the same site, the Hub Transport instance will directly pass the message along; if the recipient's mailbox is in a different site, the Hub Transport instance will transmit the message to an available Hub Transport instance in the recipient's Active Directory site.

The Hub Transport role is mandatory in an Exchange 2007 organization.

Mailbox Servers

After you have suitable Client Access and Hub Transport roles in a given site, you can begin deploying the Mailbox role. Until you have mailboxes hosted on Exchange 2007, the advanced features of Exchange 2007, such as Unified Messaging, cannot be used.

The Mailbox role is the only role that can be used in a clustered configuration.

In smaller organizations, it is common to deploy the Client Access, Hub Transport, and Mailbox server roles on the same physical server. In fact, this is the standard Exchange 2007 installation option when you use the GUI setup.

Note 

When moving mailboxes to Exchange 2007 Mailbox servers, only use the Exchange 2007 Exchange Management Console Mailbox Move Wizard or the Exchange Management Shell Move-Mailbox cmdlet. In particular, do not use the wizard in legacy versions of Exchange or you could break the mailboxes.

The Mailbox role is mandatory in an Exchange 2007 organization. Well, we suppose that technically it's not - but if you're not going to have mailboxes, why bother to upgrade?

Edge Transport Servers

The Edge Transport server role can be deployed once you have a Hub Transport instance in your organization. Since the Edge Subscription process is initiated and controlled by Hub Transport instances, and Edge Transport servers should not be part of the same Active Directory forest as the rest of the Exchange organization, there are no requirements for site affinity.

The Edge Transport role must be placed on its own physical server and cannot be colocated with any other roles.

Note 

The Edge Transport role is designed to be placed in perimeter networks with limited connectivity to the internal network. Although there are no requirements for where you place the Edge Transport server, for best performance it should be placed so that it has a low-latency, high-bandwidth connection to the Internet, as well as one or more Hub Transport instances, through the appropriate firewalls.

Unified Messaging Servers

Although the Unified Messaging role is not within the scope of this book, we can make a few general observations about deploying it. This is probably the last role to deploy in your organization; it requires working Hub Transport and Mailbox instances in the organization; it also requires a Hub Transport instance to be placed in the same Active Directory site that the Unified Messaging server will be placed in. This Hub Transport instance will transmit messages created by the Unified Messaging server instance to recipient mailboxes in the organization.

Depending on the number of recipients and the hardware configuration, you can combine the Unified Messaging role with any (or all) of the Client Access, Hub Transport, or Mailbox roles on the same physical server.

The Unified Messaging role is, of course, optional.

Note 

For your users to make use of the UM functionality, you must have sufficient Enterprise Client Access Licenses (CALs) for those users.




Mastering Microsoft Exchange Server 2007
Mastering Microsoft Exchange Server 2007 SP1
ISBN: 0470417331
EAN: 2147483647
Year: 2004
Pages: 198
Authors: Jim McBee

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net