In two earlier articles (part 1 and part 2) I explained the steps on how to move from Exchange Server 2003 to Exchange Server 2010. Although the installed base of Exchange Server 2007 is not as big as Exchange 2003, it is still absolutely worth exploring the transition from Exchange Server 2007 to Exchange Server 2010.
Exchange Server 2007
Our fictitious company, called Inframan, has approximately 500 employees. Most of them are located on the internal network, but there are also quite a number of employees who access the Exchange 2007 environment from the Internet. On the internal network, a mix of Outlook 2003 as well as Outlook 2007 is being used, and remote workers have a laptop with Outlook 2007, and a mix of mobile devices using ActiveSync to keep in sync with the Exchange Server 2007 environment. Being a typical customer, Inframan also uses Public Folders, not only for free/busy information and to download the Offline Address Book, but also for storing company wide documents, digital invoices, etc.
From a message hygiene perspective, an Exchange Server 2007 Edge Transport Server is used between the Internet and the internal network. The Edge Transport Server has anti-spam enabled; Real-time Block Lists (RBL) are used in conjunction with Content Filtering to minimize the amount of spam coming in from the Internet, and a Threat Management Gateway (TMG) was recently installed. All clients now connect to the TMG Server and from the TMG Server, and client requests are forwarded to the Client Access Server.
The externally accessible fully qualified domain names (FQDN) that are in use at Inframan are webmail.inframan.nl and autodiscover.inframan.nl. These FQDN’s are used internally as well, but to prevent internal Outlook 2007 client to be rerouted to the TMG server a “split DNS” is used. Factoring in this internet-facing security, the external IP address for webmail is the external address of the TMG server, while the internal IP address for webmail is the IP address of the Exchange 2007 Client Access Server. To achieve this, a DNS zone is created on the internal DNS server for ‘inframan.nl’, where the internal Address (“A”) records are stored.
Figure 2. The internal DNS zone for the split DNS implementation
All external IP addresses for inframan.nl must be stored in the internal DNS zone. If you forget to, for example, include the Address record of the external webserver, then internal clients cannot resolve its IP address, and accessing the site via an internet browser will fail!
This setup has been working successfully for a couple of years now, but since Inframan needs to upgrade their hardware, it was decided to upgrade to Exchange Server 2010 SP1 at the same time.
Exchange Server 2007 – 2010 coexistence
I won’t go into design-specific details on Exchange Server 2010 in this article; please check my first 2003 -> 2010 article on how to design the Exchange Servers, especially the Mailbox Server role. However, it’s worth noting here that Exchange Server 2007 and Exchange Server 2010 can coexist in one Active Directory, but there are a couple of caveats in such a scenario:
- An in-place upgrade is not supported, so you cannot install Exchange Server 2010 SP1 on top of any of the existing Exchange Server 2007 servers;
- The Internet-facing Active Directory site has to be upgraded first. In the Inframan scenario this is not important since there’s only one site, but you have to be mindful of this fact;
- Exchange Server 2007 CAS & HUB servers will not work against an Exchange Server 2010 Mailbox Server;
- Likewise, Exchange Server 2010 CAS & HUB servers will not work against an Exchange Server 2007 Mailbox Server.
The implications are this are fairly clear; Inframan needs to install a new Exchange Server 2010 Mailbox Server and a new combined Exchange Server 2010 CAS and HUB Server into the existing Exchange Server 2007 environment.
However, the Exchange Server 2007 Edge Transport Server can work against an Exchange Server 2010 Hub Transport Server, and can be replaced by an Exchange 2010 Edge Transport Server after the installation of the Exchange Server 2010 Hub Transport Server.
The upgrade path
The upgrade path for the Inframan scenario is as follows:
- Upgrade the Active Directory Schema;
- Upgrade the Active Directory Forest Configuration;
- Upgrade the Active Directory Domain(s) Configuration;
- Install the combined Exchange 2010 CAS/HUB Servers;
- Install the new Exchange 2010 Mailbox Server;Move the access methods from Exchange 2007 CAS to Exchange 2010 CAS;
- Change the message flow from the Internet to the Exchange 2010 Hub Server;
- Move all resources from Exchange 2007 to Exchange 2010;
- Install the Exchange 2010 Edge Transport Server;
- Decommission Exchange Server 2007 from the Exchange organization.
Of course, before you try and upgrade, you need to make sure you have all of the prerequisites in place for Exchange 2010 SP1 with respect to Active Directory, which are:
- The Schema Master has to be Windows Server 2003 SP2 or later;
- The Global Catalog Servers need to be Windows Server 2003 SP2 or later;
- Active Directory needs to be running in at least “Windows Server 2003 Native mode” and it needs to be in at least “Windows 2003 Forest Functional Level”.
Microsoft has a Supportability Matrix where you can quickly check all requirements for Exchange Server 2010, which can be found on the Microsoft TechNet site:. As far as Exchange 2007 is concerned, it needs to be on at least an Exchange Server 2007 Service Pack 2 level. Assuming you’ve got all the prerequisites in place, let’s take a look at the steps of the upgrade.
Active Directory Upgrades
Changing the Active Directory Schema isn’t that different than in the Exchange 2003 to Exchange 2010 upgrade path, so I won’t go into detail about that. It’s just a matter of running the setup.com /PrepareSchema command to achieve this.
However, bear in mind that when you change the Active Directory configuration in step 2 of the upgrade, you’re actually changing quite a lot. The Exchange 2010 configuration is stored in the same Administrative Group as the Exchange 2007 configuration, called Administrative Group (FYDIBOHF23SPDLT), but quite a lot of things have changed under the hood. When you dive into the Configuration Partition using tools like LDP or ADSIEdit, you’ll notice many changes And, because of these changes, the Exchange 2007 Administration Tools will not or cannot see the Exchange Server 2010 Server objects.
So, you’ll need both the Exchange 2007 and Exchange 2010 versions of the Administration Tools to manage a coexistence scenario with Exchange Server 2007 and Exchange Server 2010, and thankfully both versions of the Administration Tools can coexist on the same Management Server or Management Workstation. Background aside, you can accomplish the changing of the Active Directory Forest Configuration using the setup.com /PrepareAD command.
Next, when running the setup.com /PrepareDomain (or /PrepareAllDomains if you want to change all of the domains with Exchange Server objects in one command), the Active Directory Domain is finally prepared for Exchange Server 2010.
Of course, there’s no actual need to change the Active Directory manually as outlined above. You can also start the graphical setup program (setup.exe on the installation media) and just install the first server, which automatically invokes the Active Directory changes, assuming you have sufficient permissions of course.
Installing the Servers
After the Active Directory is updated, it’s time to install the actual Windows servers that will host the Exchange Server 2010 Server Roles. Personally, I always recommend using Windows Server 2008 R2. It is, quite simply, a better product than Windows Server 2008 SP2, and is also more efficient, especially within the network stack. Speaking of efficiency, you also don’t need to install the 85 hotfixes required when installing Windows Server 2008 SP2.
So, we are going jump ahead to after the installation of Windows Server 2008 R2 is complete, and the following prerequisites are now required before installing the first Exchange Server 2010 Server role:
- .NET Framework 3.5.1;
- Office 2010 Filter Pack (needed for attachment filtering);
- Hotfixes KB982867, KB979744, KB983440 and KB977020.
Internet Information Server is part of the prerequisite software as well, but this feature will be installed as part of the actual Exchange Server role installation, so it’s not really worth mentioning here. Additionally, over time, the last bullet won’t be a manual step anymore, as the Windows Server 2008 R2 Server will eventually be automatically updated using Windows Update (or your own patch management solution in the future, of course).
When the fresh server is fully updated, it’s time to install the Exchange Server 2010 SP1 Client Access Server and Hub Transport Server roles.
- Logon to the freshly installed and updated Windows 2008 R2 server as an Enterprise Administrator, and navigate to the installation media. Start the graphical setup application, setup.exe
- Follow the installation wizard (download the additional language packs if needed), but do not select the Typical Setup option (which will install the Client Access, Hub Transport and Mailbox Server role on the same server). Instead, select the Custom Setup, which will allow you to select exactly which Server Roles you want to install.
- In the Server Role Selection Window, select the Client Access Role and the Hub Transport Role, and right under the file path you have to check the Automatically install Windows Roles and Features required for Exchange Server option. If you do this, then the additional necessary Server Roles (like Internet Information Server) will be automatically installed.
Click Next to continue;
- 4. The next step is to enter the external domain name which, in our example, is webmail.inframan.nl. This FQDN is used in all ExternalURL properties on objects like the OWA Virtual Directory, ECP Virtual Directory, Exchange Web Services Virtual Directory, etc.
Click Next to continue the wizard;
- If all goes well you’ll reach the readiness checks, which should complete successfully. If something goes wrong, then the setup application will tell you exactly what is wrong and what to do to correct the issue(s):
This is obviously a drastic error message
This error message is quite obviously Stating that the Active Directory and Windows Server prerequisites are fine, but the Inframan environment is still running an older version of Exchange Server 2007. When there are minor issues, there’s the option to correct them on the fly, although personally I’m not a great fan of doing this. In any case, every now and then updates will not be processed correctly, or the server needs to be rebooted, but the setup application unfortunately doesn’t notice this. If you continue regardless, you can end up with all kinds of strange issues when the setup is finished (if it finishes at all). So, the Inframan Exchange 2007 servers need to be upgraded first, at least to Exchange Server 2007 SP2. When this is finished, the Exchange Server 2010 SP1 setup program can be started again;
- When the issues are resolved, the server is rebooted and the Exchange 2010 SP1 setup program is started again. Just like in the previous steps, follow the wizard and install the combined Hub Transport and Client Access Server. If requested reboot the server;
- When these server roles are installed, the Exchange Server 2010 SP1 Mailbox Server can follow. The requirements for this machine are the same as the first server we installed, so we just need to ensure the prerequisites described at the start of this Server Installation section are applied. Once that’s been done, just logon to this new server as an Enterprise Administrator, navigate to the installation media and start the (graphical) setup program.
- Follow the wizard as before, but this time select a typical setup, and in the Server Role Selection window, select only the Mailbox Server role. Just like in Figure 3, check the Automatically install Windows Roles and Features required for Exchange Server checkbox to have the prerequisites automatically installed.
- Follow the rest of the wizard and install the Exchange Server 2010 SP1 Mailbox Server Role. If possible, install the latest Update Rollup Fix for Exchange Server 2010 SP1 on both servers.
After preparing the two new Exchange 2010 servers, it is time to think about moving resources from Exchange 2007 to Exchange 2010. The following steps need to be performed:
- Change the message flow from Exchange 2007 to Exchange 2010;
- Change the external client access from Exchange 2007 to Exchange 2010;
- Configure the Exchange 2010 Mailbox Server and configure the Public Folder replication;
- Move mailboxes from Exchange 2007 to Exchange 2010;
- Move other resources to Exchange 2010;
- Decommission the old Exchange 2007 servers.
There’s no real need to follow the first three steps in this specific order; it is also possible to, for example, configure the Exchange 2010 Mailbox Server and setup Public Folder replication first. It’s really up to you to choose what to do first.
Changing Message Flow
After installing both servers, the environment now has two Exchange Server 2007 servers and two Exchange Server 2010 servers, with all message flow and all client access is still going through the Exchange Server 2007 HUB server. If messages need to go from an Exchange 2007 Mailbox to an Exchange 2010 Mailbox, they are picked up by the 2007 HUB Server, sent to the 2010 HUB Server using SMTP, and from there delivered into the Exchange 2010 Mailbox.
When messages are delivered from the Internet, through the 2007 Edge server, and destined for an Exchange 2010 Mailbox, they are also delivered to the 2007 HUB Server, sent to the 2010 HUB server using SMTP, and then delivered to the appropriate Exchange 2010 Mailbox.
So, we have to figure out a way to change the message routing and the client access methods with as little downtime as possible.
Thankfully, changing the message flow is relatively straightforward, as an Exchange 2010 Hub Server can cooperate with an Exchange 2007 SP2 or SP3 Edge Transport Server. To accomplish this, the existing Edge Synchronization (between the Exchange 2007 Edge Server and Exchange 2007 Hub Server) needs to be removed, and a new Edge Synchronization between the Exchange 2007 Edge and Exchange 2010 Hub Server needs to be created.
Later on, a new Exchange 2010 Edge Server can be installed in the DMZ, and an Edge Synchronization between that Exchange 2010 Edge Server and the Exchange 2010 Hub Server can be created. When this is accomplished, the mail flow from the firewall can be redirectedto the new Exchange 2010 Edge Server, and the old Exchange 2007 Edge Server can be removed. I’ll get back to this particular subject in my last article on upgrading Exchange Server 2007 to Exchange Server 2010.
To create a new Edge Subscription between the Exchange 2007 Edge Server and the Exchange 2010 Hub Transport Server, follow these steps:
- Logon to the Exchange 2007 Edge Server and an administrator, open the Exchange Management Shell, and enter the following command:
1New-EdgeSubscription -FileName C:\New-Edge.XML
- Copy the New-Edge.XML file to the local disk of the Exchange 2010 Hub Transport Server;
- On the Exchange 2010 Hub Transport Server, open the Exchange Management Console, navigate to the Organization Configuration, select Hub Transport and select the Edge Subscription tab;
- Delete the existing Edge Synchronization between the Exchange 2007 Hub and Exchange 2007 Edge Transport Server;
- New Edge Subscription
- In the New Edge Subscription wizard, enter the Active Directory site which the Edge Subscription has to use, and select the New-Edge.XML file that was created in step 1 And, finally, click New. The Edge Subscription is now created, but it is not yet active;
- Open an Exchange Management Shell and enter the following command:
- The synchronization process is started, and all SMTP transport is now sent between the Exchange 2007 Edge Transport Server and the Exchange 2010 Hub Transport Server.
For the normal SMTP message flow, only port 25 needs to be opened on both firewalls. For the synchronization to take place from the internal Exchange 2010 Hub Transport Server to the DMZ Exchange 2007 Edge Transport Server, port 50636 needs to be opened, but only from the inside out -There’s no need to open this port from the DMZ back to the internal network.
This can easily be checked by examining the header information of a new message. It should read something like:
Received: from 2010CASHUB.infra.local (192.168.0.237) by
2007cashub.infra.local (192.168.0.232) with Microsoft SMTP Server (TLS) id
126.96.36.199; Sat, 6 Nov 2010 13:01:59 +0100
Received: from 2007edge.inframan.nl (192.168.0.234) by 2010CASHUB.infra.local
(192.168.0.237) with Microsoft SMTP Server (TLS) id 188.8.131.52; Sat, 6 Nov
2010 13:01:51 +0100
This sample SMTP message was delivered at the Exchange 2007 Edge Transport Server (2007Edge.inframan.nl), sent to the Exchange 2010 Hub Transport Server (2010CASHUB.infra.local) and then to the Exchange 2007 Hub Transport Server (2007cashub.infra.local). From there it is delivered into a mailbox.
Changing the External Client Access
Before the external client access can be changed we need to dive into some of the Client Access Server internals. For starters, be aware that the Exchange 2010 Client Access Server cannot work directly with the Exchange 2007 Mailbox Server role. This is especially true for the Outlook Web App; when a client, for example Internet Explorer, enters the Exchange 2010 Client Access Server and needs to access an Exchange 2007 mailbox, the client is silently redirected to the Exchange 2007 Client Access Server!
The problem this creates is that both the Exchange 2007 CAS and the Exchange 2010 CAS server cannot use the same FQDN, i.e. webmail.inframan.nl. Therefore, when changing the client access, the ‘old’ Exchange 2007 Client Access Server must now be accessible using an FQDN like legacy.inframan.nl.
If you’ve done this correctly, then when clients access the Exchange 2010 CAS Server using
https://webmail.inframan.nl/owa</strong, and their mailbox is still on Exchange Server 2007, they are silently redirected to
https://legacy.inframan.nl/owa, which is actually the Exchange 2007 CAS Server. This therefore means that the current publishing rules on the TMG Server need to be changed as well for this upgrade to work:
- The Unified Communications certificate has to include the legacy.inframan.nl FQDN. Instead of using a new Unified Communications Certificate it is also possible to use a wildcard certificate, which is fully supported in Exchange Server 2010.
- The webmail.inframan.nl publishing rule needs to be changed to point to the new Exchange 2010 Client Access Server;
- The legacy.inframan.nl FQDN needs to be created, and it has to point to the Exchange 2007 Client Access Server;
- The autodiscover.inframan.nl publishing rule needs to be changed, and it has to be pointing to the Exchange 2010 Client Access Server.
Walking through all of that is a little outside the scope of this article, so we’ll have to come back to that in part 2.
In this first part of the “upgrading Exchange 2007 to Exchange 2010” article series, we’ve seen how to upgrade the Active Directory and install the Exchange 2010 servers into the existing environment. We also changed the message flow from the Exchange 2007 Edge Transport Server to the Exchange 2010 Hub Transport Server, and touched upon some of the steps we’re going to need to take to make the upgrade of the Client Access Server role as smooth as possible.
In the next article I will explain in more detail how to configure the Exchange 2010 Client Access Server and Exchange 2010 Mailbox Server, and how to move resources from Exchange 2007 to Exchange 2010.
Now for those pesky PSTs…
When you are installing Exchange Server 2010, you are likely to have a headache with locating and migrating all the old PST files, including calendars, contacts and tasks. Red Gate’s PST Importer 2010 makes quick work of the whole process of finding and importing PSTs into Exchange mailboxes or user’s Online Archives. Try it for free for 14 days and find where all your PSTs are hiding.