A Practical Look at Migrating From Exchange 2003 to Exchange 2007 (Part 1)

If you would like to read the other parts in this article series please go to:

 

 

 

Introduction

 

In this multi-part article I want to walk you through the process that I used recently to transition an existing Exchange 2003 environment to Exchange 2007, including the methods I used to build the new Exchange 2007 environment. I won’t have space within this article to detail every configuration option that was made, since some of these configuration changes are made for a reason; background discussions had taken place before these decisions were reached. Neither will I cover every single installation option but I will take some time to go over the installation and configuration of the new environment before any migration information is supplied. My main goal is to give you an appreciation of the installation order, how the servers were installed, some of the configuration changes that were made, and some of the issues that were faced along the way. If you are facing a similar migration, hopefully this article will give you some key pointers that you can use in your planning. You will want to supplement this with additional reading, of course.

 

Infrastructure

 

The existing Exchange 2003 environment was fairly typical in that it consisted of two Exchange 2003 back-end servers as well as a single Exchange 2003 front-end server. Although the back-end servers were separate physical servers, the decision had been made to move to a Clustered Continuous Replication (CCR) environment on Exchange 2007 as messaging had become vital to the company’s business. An Edge Transport server was deployed to replace an aging MailSweeper server. An existing ISA Server was used to publish mobility solutions such as Outlook Web Access (OWA) and Exchange ActiveSync (EAS) externally, thereby allowing users to access their mailboxes when not connected directly to the company’s internal network.

 

Since high availability had been designed for the Mailbox server role, it was also decided to deploy high availability for the Hub Transport and Client Access Server roles. As you likely know, fault tolerance and redundancy are built into the Hub Transport role by default and therefore the decision was made to deploy two Hub Transport servers. However, this same default redundant configuration does not apply to the Client Access Server role which is typically made highly available via the introduction of additional technologies such as hardware or software load balancing. As it turned out, only OWA and EAS were used remotely by users and as both of these are based on the Hypertext Transfer Protocol (HTTP) it was possible to use ISA Server to perform the Client Access Server load balancing. To reduce the overall server count, the Hub Transport and Client Access Server roles were combined onto a single server and then two of these combined servers deployed for fault tolerance and redundancy.

 

Also worth mentioning is the subject of virtualization. In this particular design, the combined Hub Transport and Client Access Servers, as well as the Edge Transport server, were implemented on virtual servers. The two cluster nodes were implemented using physical hardware. The various server names that will be referenced throughout this article are:

 

 

  • NODE1 and NODE2. These are the names given to the actual cluster nodes.
  • CLUSTER1. This is the name of the cluster itself.
  • EX2007. Although the cluster nodes are called NODE1 and NODE2 and the cluster itself is called CLUSTER1, none of these names are used by Outlook. The name that is used by Outlook is referred to as the Clustered Mailbox Server (CMS) name which in this case is EX2007.
  • HUBCAS1 and HUBCAS2. These are the names given to the combined Hub Transport and Client Access Servers.
  • EDGE1. This is the single Edge Transport server.

 

I should also note that all servers were installed manually rather than via any scripted method. This is mainly because there were a small enough number of servers to warrant this approach.

 

Server Preparation

 

All servers had been prepared by the customer with the Windows 2003 operating system and the relevant Service Packs and other updates applied. I spent quite some time ensuring that all servers had correct configuration items such as server names, domain membership and drive letter allocations. I am actually glad that I did this as during this time I discovered that the Edge Transport server had incorrectly been made a member of the internal Active Directory domain so this server was removed from the domain and placed back into a workgroup.

 

Other key settings that were applied to all servers were:

 

 

  • Page file. The ‘rules’ from Microsoft are that if the server has less than 8GB of memory, set the page file size to be 1.5 x the amount of memory. If the server has 8GB or more, set the page file size to be the amount of memory plus an additional 10MB. Each server was set according to these rules.
  • Another key page file consideration is the scenario where you have a dedicated drive for the page file. In these cases, make sure that the drive containing the operating system is configured with a 100MB page file so that a kernel dump can be performed.
  • I confirmed that the SMTP and NNTP services were not installed on these servers, as the presence of these services blocks the installation of Exchange 2007.
  • I addressed the Windows 2003 Scalable Networking pack issues as detailed on the Exchange team blog.
  • Locales. I took the time to ensure that the operating system locales were set to the relevant setting, which in this case was the UK.
  • Application event log sizes. Before installing Exchange 2007, I made sure that all application event log sizes were at least 40MB, with the option to overwrite events as needed configured. The Exchange Best Practices Analyzer (ExBPA) will flag this issue so it’s worth configuring the application event log sizes up front.

 

The first servers that were to be installed into the existing Exchange 2003 organization were the combined Hub Transport and Client Access Servers so these servers were prepared with the installation of the following required components:

 

 

  • .NET Framework
  • Windows PowerShell
  • IIS World Wide Web Publishing Service
  • RPC over HTTP Proxy service. Since Outlook Anywhere was to be used this component is required on the Client Access Server

 

When transitioning from Exchange 2003 to Exchange 2007, Microsoft recommends that you deploy your Exchange 2007 servers in the following order:

 

 

  • Client Access Server
  • Hub Transport server
  • Mailbox server
  • Unified Messaging Server

 

In this particular design, the Client Access Server and Hub Transport server roles were combined onto a single server and therefore these combined servers were the first to be deployed. From the above list you will notice that the Edge Transport server role is not listed. Since this server role exists in a perimeter network and is thus not part of your internal Active Directory domain, it can be installed at any point, although in practice it is best deployed after the Hub Transport server role so that the Edge Subscription process can be completed.

 

Schema Preparation

 

The decision was made to prepare the Active Directory schema as a separate process to the installation of the first Exchange 2007 server. If you start the installation of the first Exchange 2007 server, the Active Directory schema will be updated anyway but you have the choice of doing this important step as a separate task. I have detailed the Active Directory preparation process in depth here on MSExchange.org so I will not be going into huge detail within this article but for the purposes of this article what you need to know is that the setup.com program with the /PrepareLegacyExchangePermissions, /PrepareSchema, /PrepareAD and /PrepareDomain switches was run at this point. There are several additional things worth noting here:

 

 

  • The schema was updated directly on the schema master which at the time was running a 32-bit version of Windows 2003. Therefore, the 32-bit version of Exchange 2007 SP1 was used. Although Microsoft does not support the 32-bit version of Exchange 2007 SP1 in production, it does support it for the purposes of extending the Active Directory schema.
  • The setup.com /PrepareDomain command was also run in the child domain, since the root domain had already been prepared during the setup.com /PrepareAD process.
  • The Exchange 2007 SP1 software is available as a slipstreamed installation. In other words, the SP1 software was the only version used to prepare the Active Directory schema and also to directly install the servers within this infrastructure; at no point was the Release To Manufacturing (RTM) version used followed by an upgrade to SP1. This is one of the nice new features of Exchange 2007.

 

Summary

 

That concludes part one of this article which has mainly dealt with setting the scene for the remainder of the parts of this article as well as the overall server preparation process. In part two of this article, we will start to look at the installation process as we cover the Hub Transport and Client Access Server role installation as well as the preparation of the CCR environment.

 

If you would like to read the other parts in this article series please go to:

 

 

 

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top