Microsoft Exchange Server 2010 brings a new set of great technologies. No surprise many are excited and looking forward to plan and deploy this new messaging infrastructure. Today we cover the basic steps that should be performed in organizations currently running Exchange 2003.
Prerequisites that must be met before we start the deployment:
Windows Server 2003 SP2 or later, Global Catalog servers in each site where Exchange Servers are located and Windows Server 2003 forest functional level.
Exchange 2003 Organization must be in native mode, with Exchange 2003 SP2 installed
In place upgrade is not supported, thus new hardware should be installed for the Exchange 2010 Servers. Hardware requirements may be found at the following link:
Operating Systems supported are Windows Server 2008 SP2 64-bit and Windows Server 2008 R2 64-bit Standard or Enterprise. Please note that Exchange Server 2010 is 64-bit only, i.e. there is no 32-bit version available for testing purposes and there are no 32-bit management tools. Management tools should be installed on a 64-bit operating system too.
If the organization has multiple sites, the first site to introduce Exchange 2010 should be the internet facing site. The upgrade then continues with non-internet facing sites.
If the solution design requires installing Exchange 2010 roles on multiple servers, then these should be installed in the following order:
- Client Access Server role
- Hub Transport Server role
- Unified Messaging Server role (optional, may be deployed later)
- Mailbox Server role
- Edge Server role (optional, may be deployed later)
The Installation Process
The installation process requires Active Directory to be prepared. In order to do that, the user should be member of the Schema Admins and Enterprise Admins security groups.
When transitioning from Exchange 2003 to 2010, we transition the Exchange specific permissions using the command that follows.
setup /PrepareLegacyExchangePermissions or setup /pl
The Active Directory schema must be extended with Exchange 2010 specific attributes thus we run:
setup /PrepareSchema or setup /ps
The next command to run is:
setup /PrepareAD or setup /p
This performs multiple tasks. It verifies that the schema has been updated, assigns specific permissions in the configuration partition, creates the Microsoft Exchange Security Groups organizational unit (OU) in the root domain of the forest, and prepares the local domain for Exchange 2010.
The last command of the preparation steps is:
setup /PrepareDomain or setup /pd
This also performs multiple tasks. It creates a new domain global group named Exchange Install Domain Servers in the current domain. Next it adds this group to the Microsoft Exchange System Objects container and to the Exchange Servers group at the root domain.
Note: For detailed Active Directory preparation steps please check:
Prepare Active Directory and Domains
The Exchange 2010 installation steps were discussed in Installing Exchange 2010 Beta. Thus we proceed with the so called coexistence scenario i.e. the moment when there are both Exchange 2003 and 2010 versions present in our organization.
In order to provide message transport coexistence between both versions, the setup will perform the following actions:
Ask for the Exchange 2003 bridgehead server to be identified
Create an Exchange Routing Group RG (DWBGZMFD01QNBJR) to host Exchange 2010.
Create routing group connectors between the Exchange 2003 bridgehead RG and the Exchange 2010 RG.
Create an Exchange Administrative Group AG (FYDIBOHF23SPDLT) to host Exchange 2010.
Since Exchange 2007, administrative groups and routing groups are no longer used. The same also applies to Exchange 2010. Thus the RG and AG are only created to allow coexistence with Exchange 2003. Furthermore the groups are only visible from the Exchange 2003 System Manager console. It is not allowed to make any configuration or membership changes to both of these. Again, same as in Exchange 2007, Exchange 2010 uses Active Directory sites instead of Routing Groups to define the routing topology.
Client Access Server Role Coexistence
So far we completed the Exchange 2010 setup. We now configure the server roles.
During the coexistence phase, we should change some DNS settings to provide a seamless transition. Let's assume our current Exchange 2003 server is accessed by name mail.company.com. After installing Exchange 2010, a legacy name should be assigned to identify the Exchange 2003 infrastructure, for example we use legacyname.company.com. This is done both at the internal and external DNS namespaces. In addition, the current DNS host name (mail.company.com) is assigned to the new Exchange 2010 server. Thus clients won't use the legacy name, they still continue to access their mailboxes without changing settings.
A new certificate should be issued because of Exchange 2003 and Exchange 2010 coexistence. Wildcard certificates and certificates that support Subject Alternative Names may be used.
We will assume that the primary external namespace for virtual directories is configured during the setup (for example mail.company.com). Clients will use this name to connect from the Internet.
Coexistence between Exchange 2003 and Exchange 2010 Client Access will be provided by configuring the URL property on the /owa virtual directory. This is done from the Exchange Management Shell using:
Set-OWAVirtualDirectory "MAIL2010\OWA (Default Web Site)" -Exchange2003URL https://legacyname.company.com/exchange
If our company uses Outlook Anywhere, it should be enabled from the Exchange Management Shell using:
Enable-OutlookAnywhere -Server:MAIL2010 -ExternalHostName:mail.company.com -SSLOffloading $false
In addition, forms-based authentication on the Exchange 2003 front-end server should be configured in order to have single sign-on between both versions.
The Offline Address Book generation service should also be moved to the Exchange 2010 CAS Role. From the Exchange Management Shell use the command that follows:
Move-OfflineAddressBook "Default Offline Address List" -Server MAIL2010
To enable Exchange 2010 and 2003 to communicate using Kerberos authentication, the configuration partition in Active Directory should be changed, so that the attribute msExchAuthenticationFlags of the Microsoft-Server-ActiveSync object is set to value 6.
At this point in time, all clients are connecting to the new Exchange 2010 Client Access Server using the name mail.company.com. The mailboxes are still on Exchange 2003, so the Outlook Web Access experience is actually version 2003. They will connect to the new version of Outlook Web Access once their mailboxes are moved to Exchange 2010.