Exchange 2003 to Exchange 2010 Step by Step Deployment Guidance
Step 1: Verify prerequisites
I recommend that you run the Exchange Pre-Deployment Analyzer (ExPDA) to perform an overall topology readiness scan of your environment. ExPDA provides a detailed report that will alert you if there are any issues within your organization before you install Exchange 2010. If ExPDA reports any warnings or errors, take care of those issues before you proceed any further.
To get ExPDA from the Microsoft Download Center, see: Exchange Pre-Deployment Analyzer
Learn more at: Understanding Exchange 2003 Upgrade Prerequisites
To successfully install Exchange 2010, the following components are required.
- Schema master The latest 32-bit or 64-bit edition of the Windows Server 2003 Service Pack (SP) 1 Standard or Enterprise operating system or later or the latest 32-bit or 64-bit edition of the Windows Server 2008 Standard or Enterprise operating system or later.
- Global catalog server In every Active Directory site where you plan to install Exchange 2010, you must have at least one global catalog server that is either the latest 32-bit or 64-bit edition of Windows Server 2003 SP1 Standard or Enterprise, the latest 32-bit or 64-bit edition of Windows Server 2008 Standard or Enterprise, or the latest 32-bit or 64-bit edition of Windows Server 2008 R2 Standard or Enterprise.
- Active Directory Forest The Active Directory forest must be Windows Server 2003 forest functional mode.
- Domain Controller You must have the latest 32-bit or 64-bit Windows Server 2003 Standard Edition or Enterprise Edition with SP1 or later operating system or the latest 32-bit or 64-bit edition of the Windows Server 2008 Standard or Enterprise or later operating system or the Windows Server 2008 R2 Standard or Enterprise or later operating system or the Windows Server 2008 Datacenter or Windows Server 2008 R2 Datacenter.
One of the following operating systems is required:
- 64-bit edition of Windows Server 2008 Standard Service Pack 2
- 64-bit edition of Windows Server 2008 Enterprise Service Pack 2
- 64-bit edition of Windows Server 2008 Standard R2
- 64-bit edition of Windows Server 2008 Enterprise R2
Operating System Components
- .NET Framework 3.5 SP1
- Internet Information Services (IIS)
Windows Management Framework
- Windows PowerShell V2.0
- Windows Remote Management V2.0
Step 2: Install the Client Access server role
The Client Access role is one of five server roles in Exchange 2010. It’s also typically the first server role that is installed. The Client Access role enables access to mailbox data through a variety of clients, such as Microsoft Office Outlook, Outlook Anywhere, Outlook Web App, POP3, and IMAP4, and it also hosts Exchange Web services, such as the Autodiscover service and the Availability service.
Learn more at: Understanding the Client Access Server Role
How do I do this?
You’ll use the Exchange Server 2010 Setup wizard to install the Client Access role.
|When you install the first Exchange 2010 server role, Exchange 2010 prepares your Windows schema and forest before installing the server role. The amount of time that forest preparation and replication takes depends on your Active Directory site topology.|
- Insert the Exchange 2010 DVD into the DVD drive. When the AutoPlay dialog appears, click Run Setup.exe under Install or run program. If the AutoPlay dialog doesn’t appear, navigate to the root of the DVD and double-click Setup.exe. Alternatively, browse to the location of your Exchange 2010 installation files and double-click Setup.exe.
- The Exchange Server 2010 Setup welcome screen appears. In the Install section, the software listed for Step 1: Install .NET Framework 3.5 SP1 and Step 2: Install Windows PowerShell v2 was installed with the Exchange 2010 prerequisites. If these prerequisites aren’t already installed, click the appropriate step to install them.
- When Step 1, Step 2, and Step 3 are listed as Installed, click Step 4: Install Microsoft Exchange.
- On the Introduction page, click Next.
- On the License Agreement page, review the software license terms. If you agree to the terms, select I accept the terms in the license agreement, and click Next.
- On the Error Reporting page, select Yes or No to enable the Exchange Error Reporting feature, and click Next.
- On the Installation Type page, select Custom Exchange Server Installation. For Exchange 2010 SP2, you can select to automatically install all required Windows roles and features for this server. If you want to change the installation path for Exchange 2010, click Browse, locate the appropriate folder in the folder tree, and then click OK. Click Next.
- On the Server Role Selection page, select the Client Access Role, (or other server roles you want to install) and click Next. The Management Tools option, which installs the Exchange Management Console and the Exchange Management Shell, will also be selected and installed.
- Use the Configure Client Access Server external domain page to configure an external fully qualified domain name (FQDN). This is the FQDN that you give to Outlook Web App, Outlook Anywhere, and Exchange ActiveSync users to connect to Exchange 2010. Select the check box, enter your FQDN, and then click Next.
- On the Customer Experience Improvement Program page, optionally join in the Exchange Customer Experience Improvement Program (CEIP). The CEIP collects anonymous information about how you use Exchange 2010 and any problems that you encounter. To join the CEIP, select Join the Customer Experience Improvement Program, choose the industry that best represents your organization, and then click Next.
- On the Readiness Checks page, review the Summary to determine if the system and server are ready for the Client Access role to be installed. If all prerequisite checks completed successfully, click Install. If any of the prerequisite checks failed, you must resolve the displayed error before you can proceed with installing Exchange. In many cases, you don’t need to exit Setup while you’re fixing issues. After you resolve an error, click Retry to run the prerequisite check again. Also, be sure to review any warnings that are reported.
- The Progress page displays the progress and elapsed time for each phase of the installation. As each phase ends, it’s marked completed and the next phase proceeds. If any errors are encountered, the phase will end as incomplete and unsuccessful. If that happens, you must exit Setup, resolve any errors, and then restart Setup.
- When all phases have finished, the Completion page displays. Review the results, and verify that each phase completed successfully. Clear the check box for Finalize this installation using the Exchange Management Console, and then click Finish to exit Setup.
- When you’re returned to the Setup welcome screen, click Close. On the Confirm Exit prompt, click Yes.
- Restart the computer to complete the installation of the Client Access role.
Step 3: Add digital certificates on the Client Access server
For secure external access to Exchange, you’ll need a digital certificate. This certificate will include an exportable private key in X.509 format (DER encoded binary or Base-64 encoded). We recommend you procure, import, and enable a Subject Alternative Name (SAN) certificate that contains the names for the current namespace, a legacy namespace, and the Autodiscover namespace.
The names you need to include in your Exchange certificate are the fully qualified domain names (FQDNs) used by client applications to connect to Exchange.
There are three steps to adding certificates to your Client Access server(s):
- If you don’t already have a digital certificate, you can use the New Certificate Request Wizard in Exchange 2010 to generate a certificate request file, which you can then submit to your selected Certification Authority.
- After you have the digital certificate from your Certification Authority, you then complete the certificate request process by importing the certificate into your Client Access server.
- After the certificate has been imported, you assign one or more client access services to it.
Before proceeding with these steps, we recommend that you review this topic: Understanding Digital Certificates and SSL
In addition, the configuration settings used in the Deployment Assistant assumes that you’re using split DNS for client access. Learn more at: Understanding DNS Requirements
Finally, if your Exchange 2003 server isn’t currently configured to use SSL for client access, you’ll need to enable SSL to secure the communications between the client messaging applications and the Exchange front-end server. You’ll also need to install the SSL certificate on the Exchange 2003 front-end server. Learn more at: Exchange Server 2003 Client Access Guide.
How do I create a certificate request file for a new certificate?
You can use the New Exchange Certificate wizard to create your certificate request.
- In the Console tree, click Server Configuration.
- From the Actions pane, click New Exchange Certificate to open the New Exchange Certificate wizard.
- On the Introduction page, enter a friendly name for the certificate (for example, Contoso.com Exchange certificate) and then click Next.
- On the Domain Scope page, if you plan on using a wildcard certificate, check the box for Enable wildcard certificate, enter the root portion of your domain (for example contoso.com or *.contoso.com), and then click Next. If you’re not using a wildcard certificate, just click Next.
|It’s a best practice to not use wildcard certificates because they represent a potential security risk. Like a SAN certificate, a wildcard certificate (for example, *.contoso.com) can support multiple names. There are security implications to consider because the certificate can be used for any sub-domain, including those outside the control of the actual domain owner. A more secure alternative is to list each of the required domains as Subject Alternative Names in the certificate. By default, this approach is used when certificate requests are generated by Exchange.|
- On the Exchange Configuration page, expand and configure each area as follows:
a) Federated Sharing Federated Sharing allows you to enable users to share information with recipients in external federated organizations by creating organization relationships between two Exchange 2010 organizations, or using a sharing policy to allow users to create sharing relationships on an individual basis. If you plan on using this feature, expand Federated Sharing and select the Public certificate check box.
b) Client Access server (Outlook Web App) Expand this option and select the check box(es) that are appropriate for your Outlook Web App usage (Intranet and/or Internet). If you’re using Outlook Web App internally, then in the Domain name you use to access Outlook Web App internally field, remove the existing server names and enter the FQDN you configured for external access to the Client Access server during Setup of the Client Access server (for example, mail.contoso.com). This is the same FQDN that is listed in the domain name field for Outlook Web App on the Internet.
c) Client Access server (Exchange ActiveSync) Exchange ActiveSync should already be selected and the domain name field should be configured with the same FQDN used for Outlook Web App.
d) Client Access server (Web Services, Outlook Anywhere, and Autodiscover) Exchange Web Services, Outlook Anywhere, and Autodiscover on the Internet should already be selected. Outlook Anywhere should already be configured to use two FQDNs: one that is the same FQDN used by Outlook Web App (for example, mail.contoso.com) and one that is the root domain for that FQDN (for example, contoso.com). Autodiscover should already be configured to use a long URL, which should automatically be configured as autodiscover.rootdomain (for example, autodiscover.contoso.com).
e) Client Access server (POP/IMAP) If you plan on using secure POP or secure IMAP internally or over the Internet, expand this option and select the appropriate check box. In the domain name field for each protocol, remove the individual server names and enter the same FQDN you’re using for Outlook Web App.
f) Unified Messaging server If you plan on using Unified Messaging (UM) features, you can use a certificate that is self-signed by an Exchange 2010 UM server (which is the default option). If you’re integrating UM with Office Communications Server (OCS), you’ll need to use a public certificate. We recommend using a separate certificate for UM and OCS integration.
g) Hub Transport server Hub Transport servers can use certificates to secure Internet mail, as well as POP and IMAP client submission. If you plan on using mutual TLS or if you’re using POP or IMAP clients and want to secure their SMTP submissions, select the appropriate check box and in the FQDN field, enter the same FQDN you’re using for Outlook Web App.
h) Legacy Exchange Server This option is used to add the legacy namespace to the certificate, which will be used only during the period of coexistence between Exchange 2010 and the legacy version(s). Expand this option, select the Use legacy domains check box, and in the FQDN field, enter the FQDN you are using for your legacy namespace.
- On the Certificate Domains page, review the list of domains that will be added to the certificate. If the names are correct, click Next. If any names are missing or incorrect, you can click Add to add missing names, or select a name and click Edit to modify the name. Click Next.
- On the Organization and Location page, fill in the Organization, Organization unit, Location, Country/region, City/locality, and State/province fields. Click Browse and browse to the location where you want the certificate request file created. In the File name field, enter a name for the request file (for example, Exchange Certificate Request.req) and click Save. Click Next.
- On the Certificate Configuration page, review the configuration summary. If any changes need to be made, click Back, and make the necessary changes. If everything is correct, click New to generate the certificate request file.
- On the Completion page, review the output of the wizard. Click Finish to close the wizard.
- Transmit the certificate request file to your selected Certification Authority, who will then generate the certificate and transmit it to you. After you have the certificate file, you can use the Complete Pending Request wizard to import the certificate file into Exchange 2010.
- In the Console tree, click Server Configuration.
- In the Work pane, right-click the certificate request you created and click Complete Pending Request.
- On the Introduction page, click Browse to select the certificate file provided to you by your selected Certification Authority. Enter the private key password for the certificate, and then click Complete.
- On the Completion page, verify that the request completed successfully. Click Finish to close the Complete Pending Request wizard.
How do I assign services to the certificate?
You can use the Assign Services to Certificate wizard to assign the appropriate services to the imported certificate.
- After the certificate has been successfully imported, you can assign services to it. Select the certificate in the Work pane, and then from the Actions pane, click Assign Services to Certificate to open the Assign Services to Certificate wizard.
- On the Select Servers page, the Exchange server into which you imported the certificate is shown. Click Next.
- On the Select Services page, select the check box for each service you want assigned to the selected certificate and then click Next. For example, select the check box for Internet Information Services (IIS) to assign services for Outlook Web App, Exchange ActiveSync, and other Exchange services that are integrated with IIS.
- On the Assign Services page, review the configuration summary. If any changes need to be made, click Back. If the configuration summary is correct, click Assign to assign the specified services to the selected certificate.
- On the Completion page, verify that each step completed successfully. Click Finish to close the wizard.
How do I install the certificate on the legacy Exchange server?
In addition to installing the SSL certificate on the Exchange 2010 Client Access server, you’ll also need to install the certificate on the Exchange 2007 Client Access server or the Exchange 2003 server so that users with mailboxes on Exchange 2007 or Exchange 2003 can use SSL to connect to their mailboxes.
|If you’ll be moving all mailboxes from Exchange 2003 or Exchange 2007 to Exchange 2010 over a short period of downtime, such as a weekend, you can skip these steps.|
Before you install the digital certificate on the legacy Exchange server you must first export it from the Exchange 2010 Client Access server. To export your digital certificate, use the following steps.
- Export the digital certificate to the variable $file using the following command.
$file = Export-ExchangeCertificate -Thumbprint 5113ae0233a72fccb75b1d0198628675333d010e -BinaryEncoded:$true -Password (Get-Credential).password
- The following command uses the Set-Content cmdlet to write data stored in the variable $file to the file htcert.pfx.
Set-Content -Path “c:\certificates\htcert.pfx” -Value $file.FileData -Encoding Byte
To install a digital certificate on an Exchange 2003 server, use the following steps.
- Copy the exported certificate to a location that can be accessed from the Exchange 2003 server.
- Click Start, Run, type MMC, and then click OK.
- In the left hand pane, expand Certificates (Local Computer), and then select the Personal node.
- Right-click Certificates, click All Tasks, and then click Import to launch the Certificate Import Wizard. Click Next.
- Enter the password you used when you exported the PFX file, select the Mark the private key as exportable check box and then click Next.
- Select Automatically select the certificate store based on the type of certificate, click Next, and then click Finish.
To install a digital certificate on an Exchange 2007 server, use the following steps.
- Copy the exported certificate to a location that can be accessed from the Exchange 2007 server.
- Using the Exchange Management Shell, run the following command.
Import-ExchangeCertificate -Path c:\certificates\import.pfx -Password:(Get-Credential).password
Step 4: Configure Outlook Anywhere
Outlook Anywhere eliminates the need for users in remote offices or mobile users to have to use a VPN to connect to their Exchange servers. Although Outlook Anywhere is an optional component of Exchange 2010, we recommend its use if you have external clients that will connect to Exchange 2010. Outlook Anywhere provides access to a user’s mailbox via RPC over HTTPS.
As with any external client access method, there are security implications to consider when deploying Outlook Anywhere. Before making the decision to deploy Outlook Anywhere, you should read: Understanding Security for Outlook Anywhere
How do I do this?
The Enable Outlook Anywhere wizard helps you with this task.
- In the console tree, navigate to Server Configuration > Client Access.
- In the action pane, click Enable Outlook Anywhere.
- On the Outlook Anywhere tab:
- Type the external host name or URL for your organization in External host name. The external host name should be the FQDN you entered when installing the Client Access server role, which is the existing host name. For example, mail.contoso.com.
- Select either Basic authentication or NTLM authentication.
|Don’t select Negotiate Ex authentication. It’s an authentication type that’s reserved for future Microsoft use. If you select this setting, authentication will fail.|
- If you’re using an SSL accelerator and you want to use SSL offloading, select Allow secure channel (SSL) offloading.
|Don’t use this option unless you’re sure that you have an SSL accelerator that can handle SSL offloading. If you don’t have an SSL accelerator that can handle SSL offloading, and you select this option, Outlook Anywhere won’t function correctly.|
- Click Enable to apply these settings and enable Outlook Anywhere.
Step 5: Configure OAB and Web Services virtual directories
To enable Outlook Anywhere clients to discover and automatically connect to Exchange 2010, you must configure the offline address book (OAB) and Exchange Web Services virtual directories. This step is only necessary if you’ll be using Exchange Web Services, Outlook Anywhere, or the offline address book.
How do I do this?
You must use the Exchange Management Shell to configure OAB and Exchange Web Services virtual directory settings.
If you’re unfamiliar with the Shell, learn more at: Overview of Exchange Management Shell
- Configure the external URL for the offline address book using the following syntax.
Set-OABVirtualDirectory -Identity “CAS01\OAB (Default Web Site)” -ExternalUrl https://mail.contoso.com/OAB -RequireSSL:$true
- Configure the external URL for Exchange Web Services using the following syntax.
Set-WebServicesVirtualDirectory -Identity “CAS01\EWS (Default Web Site)” -ExternalUrl https://mail.contoso.com/EWS/Ex
To verify that these steps were completed successfully, run the following commands to verify the ExternalURL property is set correctly on both virtual directories.
Get-OABVirtualDirectory -Identity “CAS01\OAB (Default Web Site)”
Get-WebServicesVirtualDirectory -Identity “CAS01\EWS (Default Web Site)”
- Rockin’ the CASB – What you need to know about Cloud Access Security Brokers …
- Cloud Tweaks Blog … What Do You Know About Cloud Security?
- Security Awareness @ ISC2 Security Congress 2015
- Secure the Power of the Cloud … (and get certified while doing it)
- Announcing Exchange Server 2016 Preview!
- VMware Scripting Overview – A quick look under the hood
- Checklist: Use AD FS to implement and manage single sign-on with Server 2012/R2
- Checklist: Setting up a Federation Server (ADFS) for use with Office 365 on Windows Server 2008/R2
- The (ISC)² CISSP Domain Refresh … Are you prepared?
- vSphere 6.0 is on the way !!! …. Are you ready???