Planning and migrating a small organization from Exchange 2007 to 2013 (Part 11)

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

• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 1)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 2)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 3)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 4)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 5)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 6)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 7)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 8)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 9)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 10)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 12)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 13)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 14)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 15)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 16)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 17)

Introduction

With Exchange 2013 installed, we’ve successfully introduced the latest version of Exchange Server into our organization and have ensured that the new server is up to the job by testing thoroughly using JetStress. We’re now ready to begin completing the tasks that ensure we’re ready for coexistence with Exchange 2007 and ready to move mailboxes. In this part of the series we’ll make sure Exchange 2013 isn’t introduced to clients prematurely and generate new SSL certificates.

Post-Installation Configuration Changes

After successfully installing Exchange Server 2013, a non-essential change worth making is to update the Service Connection Point (SCP). The SCP is registered in Active Directory and used, alongside the Exchange 2007 SCP, as a location Domain-Joined clients can utilize to find the Autodiscover URL on the Exchange Server.

By default, the SCP will be in the form https://ServerFQDN /Autodiscover/Autodiscover.xml; for example https://e15m01.exchangelabs.co.uk/Autodiscover/Autodiscover.xml.

The name above however won’t be suitable for two reasons – firstly, no trusted SSL certificate is currently installed on the new Exchange 2013 server, and the SSL certificate we’ll replace it with in the next section won’t have the actual full name of the server.

This can cause certificate errors on domain-joined clients, most commonly manifested by Outlook showing the end user a certificate warning shortly after you install a new Exchange Server.

Therefore, we’ll immediately update the Service Connection Point to use the same name as the Exchange 2013 server, which is also the name we’ll move across later on whilst implementing co-existence.

Updating the Service Connection Point for AutoDiscover

To update the Service Connection Point, we’ll use the Set-ClientAccessServer cmdlet from the Exchange Server 2013 Management Shell, using the AutoDiscoverServiceInternalURI parameter to update the actual SCP within Active Directory.

First, we can check the SCP currently in use by the Exchange 2007 Server by using the Get-ClientAccessServer cmdlet:

Get-ClientAccessServer -Identity <Exchange2007Server> | fl AutoDiscoverServiceInternalURI

After confirming that the URL is as expected (https://autodiscover.domain.com/Autodiscover/Autodiscover.xml), update the SCP on the new Exchange 2013 Server using the Set-ClientAccessServer cmdlet:

Set-ClientAccessServer -Identity <Exchange2013Server> -AutoDiscoverServiceInternalURI https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

You’ll see this in action against our Exchange Labs environment below:

Figure 1: Configuring the Service Connection Point

After making this change, any clients attempting to use the Exchange 2013 Service Connection Point before we implement co-existence will continue to use the Exchange 2007 Server.

New SAN/UCC SSL Certificate Generation

Now we’ve ensured that our clients aren’t going to start automatically attempting to contact our new Exchange 2013 server, we can carry on with important setup tasks. First, we’ll approach one of the key tasks – making sure the server has a valid, trusted SSL certificate containing the names we’ll be using both for the new Exchange 2013 server, and for co-existence with Exchange 2007.

Considerations when changing certificate vendors

Many organizations upgrading will already have a valid certificate in place and will choose to remain with the same certificate authority. This may be because it’s free to add additional names and re-key the SSL certificate, or because the organizations has chosen to use a single vendor across the organization for certificates.

However if your organization doesn’t have a preferred certificate vendor or is using the upgrade to Exchange 2013 to switch to a lower cost certificate authority, it’s important to be aware that you may cause client issues.

Most modern browsers, operating systems and mobile devices are up-to-date with certificate authorities, however if you have a mix of old mobile devices – particularly older Android or Windows Mobile phones; or Windows XP computers that do not make use of the Update Root Certificates features within Windows Update then changing to a new certificate vendor may cause issues. Therefore make sure you add additional time to plan and test the new certificates with devices to catch any potential problems.

Additionally, most certificate vendors require a certificate chain installed and provide specific instructions for installation. If you’re staying with your regular vendor you are likely to have already installed the correct chaining certificates; so make sure if you’re changing certificate authorities you install the chaining certificates not only on the Exchange 2013 server, but also other servers that will use the same SSL certificate, like the Exchange 2007 server and Forefront TMG server.

Generating the new certificate CSR

The CSR is the Certificate Signing Request. This is generated by the Exchange 2013 Server and is the first part of a process to generate a certificate for the server. As part of a the CSR, a new Private Key is generated on the Exchange 2013 server, along with a text-based CSR. The CS can then be passed to a Certificate Authority who in response can provide a certificate.

Earlier in the series we defined the names we’d need at this point when creating our CSR. For reference, the names we’ll need are repeated below. As you’ll see we’ve got a name for Exchange HTTPS services like OWA, the standard AutoDiscover name, a name to use for coexistence with Exchange 2007, and because POP3/IMAP or SMTP are in use we have a name (which is the same as the HTTPS name) to use for those services:

Table 1

To begin the Certificate Signing Request generation process, we’ll open up the Exchange Admin Center, which will be available at the following URL on our Exchange 2013 server:

https://<servername>/ecp/?exchclientver=15

A quick point – you’ll notice in the example above we’ve appended exchclientver=15 to ensure that although we’re using an Exchange 2007 administrator account at this stage, the server knows we wish to administer Exchange 2013.

After login, navigate to Servers>Certificates and then choose the Add button, as shown below:

Figure 2: Navigating the the Certificates section of the EAC

After choosing Add, the New Exchange Certificate wizard will be displayed. Because we’ll be using a third-party trusted certificate, we’ll choose Create a request for a certificate from a certification authority on the first page of the wizard:

Figure 3: Creating a new CSR using the Certificate Wizard

Follow the next steps of the wizard, entering the following information when requested:

• The Friendly Name for your certificate that will help you to identify it – for example Exchange 2013 Co-existence.
• The Server to store the certificate on. This will be your new Exchange 2013 server, in our example E15M01
• When you’re asked to Specify the domains to use on the certificate, simply choose next. We already know which domains we’ll use, so after making sure you’ve not missed anything, just press next.

At this point you’ll be shown the list of the domains that will be included on your certificate in order. As shown below, simply remove unnecessary domains – such as the local domain name and server name. Replace those with your equivalent of the table shown above, reducing the names simply to our HTTPS namespace, AutoDiscover name and Legacy name. You’ll see in the example below we’ve also ensured that the main HTTPS name (mail.exchangelabs.co.uk) is also the Subject Name – in other words the primary name on the certificate:

Figure 4: Specifying all names used for Exchange, including legacy names

Complete the wizard by specifying information about your organization, such as it’s legal name and address, then on the final page of the wizard enter a location to save the certificate request.

In a departure from the method used in preivous versions of Exchange, where you can specify a local path to save the certificate request; in Exchange 2013’s Exchange Admin Center you now need to specify a network path.

This network path needs to be a location that the Exchange Trusted Subsystem, i.e the Exchange Server Computer Account, can access. This is because the request will be executed by the Exchange Server itself rather than as you, the logged in user.

In our example, we’ve chosen to save the certificate to a location we know the Exchange Serer has access to – it’s local C: drive, and specified a sub-directory to store the certificates in that is simpleto type in:

Figure 5: Defining the network share path used to store the CSR file

The resulting request file can be opened in a text editor, so feel free to give the CSR an extension of TXT rather than REQ if it makes your life easier.

Armed with the CSR file, we’ll then visit our Certificate Authority’s online request portal and upload our CSR as part of the certificate generation process:

Figure 6: Importing the CSR into a third-party CA

After uploading the CSR, most certificate authorities will provide an opportunity to check the names found on the CSR and give you an opportunity to correct or add additional names.

Figure 7: Validating all Subject Alternative Names are correct on the CA website

After carefully checking the names you wish to use on the certificate, match both the names you plan to use – and are actually correct, then pay fo make your certificate request.

Applying the certificate to the Exchange 2013 Server

After we’ve received the certificate, the next step is to complete the request on the Exchange 2013 server. As with the request process, we can’t just upload the certificate via the web browser – so we’ll first need to copy the certificate we’ve received to the server to a location we can easily type in or remember.

After copying the certificate to the server, open the Exchange Admin Center and navigate back to Servers>Certificates, and find your Pending request in the list of certificates. Choose Complete, as highlighted below:

Figure 8: Using the EAC to begin the CSR completion process

After choosing Complete, the Complete Pending Request wizard will display, providing the opportunity to enter the network path to the certificate:

Figure 9: Completing the pending request using a certificate file from a network share

After completing the request, the certificate should change from the Status Pending to Valid. Armed with our valid certificate we can now assign it to relevant services on our Exchange 2013 server. This will ensure that when clients access the server, the correct SSL certificate is presented to those clients rather than the default self-signed certificate.

To do this, select the new certificate from the list and then choose the Edit button as shown below:

Figure 10: Selecting the valid certificate to assign services to

After choosing Edit, the Exchange Certificate dialogue should show. Select Services, then select each service that the new SSL certificate will be used for on the Exchange 2013 server – in our case IMAP, POP and IIS, then press Save:

Figure 11: Enabling the new certificate for IIS and additional services

After saving the changes, the certificate should take effect for IIS shortly after. As our example organization uses POP and IMAP, those changes will take effect when we enable those services to start later on.

Exporting the certificate as PFX format

Although our certificate is in place and enabled on the Exchange 2013 server, we also have to consider the other places where the certificate will be used. In our example organization that includes:

• The Exchange 2007 Server
• The Forefront TMG 2010 Server

Therefore we’ll need to export a copy of the certificate, along with the associated Private Key, to import into each of the above servers. This will be exported in the Personal inFormation eXchange format (note the capitalization) otherwise known as PFX.

We’ll accomplish this in the Exchange Admin Center, again within Servers>Certificates by selecting the certificate from the list, then selecting the … drop-down menu and then selecting Export Exchange Certificate:

Figure 12: Launching the Export Certificate wizard from the EAC

Just in the same way as when we created a CSR and imported the Certificate, we’ll need to specify a network share to save the PFX file onto. As you’ll see below, we’re again using a convenient location on the Exchange 2013 server. As the PFX file contains the very sensitive Private Key as well as the certificate, we need to specify a secure password to ensure the PFX cannot be re-used unless the password is known:

Figure 13: Specifying a network location and password for the PFX file

After exporting the file, we’ll then be ready to apply it to both TMG and Exchange Servers. If the location you’ve exported the PFX file to isn’t accessible by those servers, you’ll either need to move it to a network location that is accessible, or copy the certificate up to each server temporarily.

Summary

In this article we’ve updated our SCP record to make sure clients don’t get certificate warnings, and now have our new SSL certificate enabled on Exchange 2013 and exported to PFX.

In the next part of this series we’ll import the PFX file into our TMG and Exchange 2007 server, and then configure client access and transport components.

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

• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 1)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 2)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 3)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 4)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 5)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 6)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 7)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 8)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 9)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 10)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 12)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 13)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 14)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 15)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 16)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 17)