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

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

Introduction

We’ve successfully set up our mailbox databases, created and tested accounts on Exchange 2013 and we’re almost ready to go. To round off the previous articles in this series, we’ve began to configure the all-important step that will enable a smooth migration, coexistence. So far we’ve enabled the new SSL certificates on our TMG and Exchange 2007 servers, created additional records in DNS to support coexistence and updated Outlook Web App on Exchange 2013 to support pre-authentication on our TMG server.

In this part of the series we’ll complete the configuration of coexistence, updating Exchange 2007 to correctly support using a legacy namespace, update internal DNS records to point our main names for Exchange at our new server, then configure TMG so that Exchange 2013 is published alongside Exchange 2007. Finally we’ll test to make sure everything is working as expected.

Configuring Coexistence Continued

Updating Exchange 2007 URLs

Our next step is to update the URLs that will be provided to clients by AutoDiscover, and used by Exchange 2013 to proxy or redirect requests to Exchange 2007. For each virtual directory on Exchange 2007, we’ll need to update the URLs in place to instead use the Legacy names we’ve chosen and added to our SSL certificate.

We can do this using the Exchange Management Console for most Exchange Virtual Directories. To do this, navigate to Server Configuration>Client Access and then after selecting the Exchange 2007 server, open the properties for each virtual directory:

Image
Figure 1: Navigating to the OWA virtual directory in the Exchange 2007 management console

As you’ll see in the example below, we’ll simply update the Internal URL and External URL substituting legacy.exchange.co.uk for the existing values:

Image
Figure 2: Updating Internal and External URLs to use the legacy namespace

As always though there’s a couple of exceptions.

The first is ActiveSync. ActiveSync clients do not handle redirection very well, and when prompted to redirect will, in many cases, simply break. Therefore we’ll want to ensure that Exchange 2013 proxies the request to ActiveSync and the client is not made aware of the change.

We’ll accomplish this very simply by setting the External URL to be blank, and filling in the Internal URL with the legacy name. Exchange 2013 will recognize this is set, and act accordingly:

Image
Figure 3: Updating ActiveSync-specific settings to ensure proxying of mobile clients

The second exception is Exchange Web Services. Like other virtual directories this is critical for client communications – and the updated value will be used by Outlook clients during coexistence, behind the scenes. However, it’s not a virtual directory we can update using the Exchange Management Shell. Therefore, we’ll need to open the Exchange Management Shell and use a command in the format below, substituting legacy.exchangelabs.co.uk for your legacy HTTPS namespace:

Set-WebServicesVirtualDirectory -Identity “E12M01\ews (Default Web Site)” -InternalURL “https://legacy.exchangelabs.co.uk/EWS/Exchange.asmx” -ExternalURL “https://legacy.exchangelabs.co.uk/EWS/Exchange.asmx”

Image
Figure 4: Updating the Web Services virtual directory

Naturally you can accomplish all namespace changes using PowerShell and if you’d prefer, you can use the following script to make the change across all services for the server:

$Server = “E12M01”   

$HTTPS_FQDN = “legacy.exchangelabs.co.uk”

Set-OWAVirtualDirectory -Identity “$($Server)\owa (Default Web Site)” -InternalURL “https://$($HTTPS_FQDN)/owa” -ExternalURL “https://$($HTTPS_FQDN)/owa”

Get-OABVirtualDirectory -Server $Server | Set-OABVirtualDirectory -InternalURL “https://$($HTTPS_FQDN)/oab” -ExternalURL “https://$($HTTPS_FQDN)/oab”

Get-ActiveSyncVirtualDirectory -Server $Server | Set-ActiveSyncVirtualDirectory -InternalURL “https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync” -ExternalURL $null

Get-WebServicesVirtualDirectory -Server $Server | Set-WebServicesVirtualDirectory -InternalURL “https://$($HTTPS_FQDN)/EWS/Exchange.asmx” -ExternalURL “https://$($HTTPS_FQDN)/EWS/Exchange.asmx”

Image
Figure 5: Using PowerShell to update all Exchange 2007 virtual directory settings

After making these changes, clients like Outlook will, as part of their regular AutoDiscover process, begin to use the new URLs rather than the existing ones.

Updating Internal DNS records

To switch over to coexistence for internal clients, all that is now left to do is to update the existing mail and autodiscover records within DNS to point at the Exchange 2013 server instead of Exchange 2007.

You’ll see the records that require changing by opening DNS Manager on a Domain Controller, and locating both records. You’ll see both highlighted in the example below, both aimed at E12M01, our Exchange 2007 server:

Image
Figure 6: Updating internal DNS records to ensure clients use Exchange 2013 servers

Simply update each to use the IP address of the Exchange 2013 server. As soon as the cached address client use expire, they’ll begin to access Exchange 2013 – initially only for AutoDiscover and proxied requests.

Configuration of Forefront TMG

Our last step to enable client coexistence with Exchange 2013 and 2007 is to update the methods used to publish Exchange to the internet. This will vary slightly if you organization doesn’t use TMG, but in essence we’ll make the following changes:

  • Requests to the legacy URLs will go to Exchange 2007.
  • Requests to the mail and autodiscover URLs will go to Exchange 2013.
  • TMG pre-authentication SSO will be used across both names so that clients access Exchange 2007 won’t need to log in a second time after Exchange 2013 redirects them to the legacy URL.
  • A single IP address and SSL certificate (both already in place) will be used to publish, using our existing listener.

Before we begin making major changes to TMG – first, take a backup. Second – bear in mind that many TMG configurations are different. Depending on the organizations requirements, it’s likely you’ll see some differences between the configuration shown here and within other environments.

In our example organization’s TMG setup, we’ve got three rules for publishing Exchange 2007. One publishes Outlook Anywhere, Exchange Web Services, the Offline Address Book and AutoDiscover. A second publishes Active Sync and a third one uses forms-based pre-authentication to publish OWA:

Image
Figure 7: Existing TMG policies for Exchange 2007

We’ll first edit the OA, EWS, OAB and AutoDiscover rule. The first change describes what we’ll be doing to it – we’ll change the name to EWS and OAB. The other protocols can, and will be published only via Exchange 2013:

Image
Figure 8: Altering basic settings for existing TMG rules

Next, we’ll navigate to the To tab and update the server name we’re publishing:

Image
Figure 9: Updating Exchange 2007 rules to use the legacy name

We’ll also update on the Public Name, the actual externally published name that we’ll associate with this rule, again setting it to just our Legacy name:

Image
Figure 10: Replacing the external name TMG uses for Exchange 2007

Finally on the Paths tab, we’ll remove the paths that aren’t required to be published via Exchange 2007 any longer, just leaving the Exchange Web Services related URL paths and the Offline Address Book:

Image
Figure 11: Reducing the number of paths published for Exchange 2007

The next rule we’ll edit is the one that publishes ActiveSync. As we’ve mentioned, all ActiveSync access whilst we coexist will go via Exchange 2013, therefore we’ll be editing the existing ActiveSync rule. First we’ll change the name of the rule to something more appropriate:

Image
Figure 12: Updating the ActiveSync publishing rule to point to Exchange 2013

Then we’ll alter the internal IP address of the server that’s published. For our single ActiveSync rule we don’t need to alter any other settings, simply because it is still published with the same external HTTPS name URL and paths.

Image
Figure 13: Changing the internal IP address from Exchange 2007 to 2013

The final rule that we’ll update is the rule that publishes Outlook Web Access in Exchange 2007. As with the previous rules, update the name of the rule to something more appropriate, and then on the To tab, change the name of the site to our legacy name:

Image
Figure 14: Updating the Exchange 2007 OWA rule to use the legacy name

Then, on the Public Name tab, remove the existing name, and replace it with our legacy HTTPS name, as shown below:

Image
Figure 15: Changing the external name for OWA to only use the legacy name

Existing rules altered (but crucially not applied yet), we’re now ready to create our additional rules for Exchange 2013.

We’ll begin by creating a new publishing rule that will publish Exchange Web Services, the Offline Address Book, Outlook Anywhere, AutoDiscover and Outlook Apps. To get started, we’ll select Firewall Policy and choose New>Exchange Web Client Access Publishing Rule from the menu:

Image
Figure 16: Creating our first Exchange 2013 publishing rule

On the first page of the wizard, we’ll choose an appropriate name:

Image
Figure 17: Specifying the name and purpose of our first new Exchange 2013 rule

Next, we’ll choose to publish Exchange 2010. This might be a surprising option, however with TMG there is no Exchange 2013 option and nonetheless, this will fulfil our requirements. To get the base settings, we’ll choose to publish Outlook Anywhere with the Publish Additional Folders option:

Image
Figure 18: Selecting the type of Exchange publishing rule to create

We’ll then need to specify the details for the Exchange 2013 server that we’re publishing. Because both the internal and external names used Exchange 2013 are the same, enter the main HTTPS name (in our example organization’s case mail.exchangelabs.co.uk) and the internal IP address of the Exchange 2013 server:

Image
Figure 19: Specifying the Exchange 2013 server name and IP address

Next, we’ll specify the external name that TMG will associated with this rule. We’ll only want it to respond to specific names (remember, some of these paths are being used with the legacy name on the same external IP address, with the same SSL certificate) so choose Accept requires for this domain name, and then enter our main HTTPS name (again in our example organization’s case, mail.exchangelabs.co.uk), as shown below:

Image
Figure 20: Specifying the main HTTPS name for Exchange 2013

If you’re wondering where we’ll specify the Autodiscover name – fear not. We’ll add that later. For now though, we’ll continue with just the main HTTPS name and on the next page of the wizard, associate the new rule with our single listener for Exchange, as used by Exchange 207 and bound to our updated SSL certificate:

Image
Figure 21: Selecting the existing Exchange listener

On the Authentication Delegation page of the Publishing Wizard, we’ll be given the option to specify the type of pre-authentication in use. We’ll specifically choose not to use pre-authentication for the services we are publishing through this rule.

There’s a number of reasons for that – first and foremost, it’s not supported with the Outlook App publishing we’ll use with this rule. Additionally, it can also cause problems if you’re looking to implement a Hybrid Exchange configuration at a later date, publish calendars to the Internet or use Exchange’s Federation features. More importantly, when we’ve finished migrating users and tear down the coexistence setup, we’ll remove TMG anyway and publish Exchange 2013 directly, so why add any extra complexity?

Image
Figure 22: Ensuring pre-authentication is not used for rich client access

Complementing our Authentication Delegation configuration, make sure you choose All Users rather than the default of All Authenticated Users. This ensures that because we’re not using pre-authentication for this particular rule all traffic will be passed directly to Exchange for authentication:

Image
Figure 23: Ensuring our new rule by-passes pre-authentication

After completing the wizard, it’s time to open the properties for our new web publishing rule and make a few customizations to ensure it meets our needs for Exchange 2013. First, navigate to the Public Name tab and add a new name to ensure our Autodiscover HTTPS name is listed within the rule, as shown below:

Image
Figure 24: Adding our Autodiscover external name to our new rule

We’ll then need to add a single additional path to ensure Outlook Apps can be published. Outlook Apps use OAuth authentication and reside within the Outlook Web App virtual directly. Because the OWA virtual directory will use TMG pre-authentication, we’ll need to specify the exact path used by Outlook Apps for OAuth authentication in this rule to ensure that those requests bypass pre-authentication.

Microsoft have provided detailed guidance concerning this on the Exchange Team Blog, and we’ll use the relevant guidance to find the exact path to add.

The path to publish uses a special GUID within the path unique to our Exchange 2013 environment. We’ll find this GUID attached to one of our Arbitration System Mailboxes. Use the following command at the Exchange Management Shell to find the GUID:

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like “OrganizationCapabilityClientExtensions”} | fl exchangeGUID, PrimarySmtpAddress

Image
Figure 25: Locating the GUID to use in our Outlook App path

You’ll see the GUID, similar to as shown above. Note down this GUID, and add a new Path within the TMG rule in a format similar to below, prepending /owa/ before the GUID, and then the email domain followed by /* after the GUID, for example:

/owa/[email protected]/*

Image
Figure 26: Adding our Outlook App path to our new publishing rule

After making this change, our first Exchange 2013 rule is ready to go.

We’ll now create our second and final new rule, which will publish Exchange 2013 Outlook Web App. As before create a new Exchange Publishing rule, and choose an appropriate name to describe it’s purpose:

Image
Figure 27: Entering an appropriate name to use when publishing OWA

Next, choose Exchange 2010 from the list of options, then select to publish Outlook Web Access:

Image
Figure 28: Selecting the correct type of Exchange publishing rule to create

Using the same settings as the previous rule, we’ll enter the main HTTPS name for Exchange 2013, and enter the internal IP address of the Exchange 2013 server on the Internal Publishing Details page and Public Name Details pages of the wizard. As before select the same listener used for the previous rule.

As we’re going to continue to use pre-authentication (as per Exchange 2007 OWA) we’ll need to configure the appropriate settings on the Authentication Delegation page of the wizard. Choose NTLM authentication here to match the internal setting of OWA (Integrated Windows Authentication):

Image
Figure 29: Specifying NTLM authentication to ensure pre-authentication is used

To complete the wizard, leave the default of All Authenticated Users as-is.

Before applying our changes within Forefront TMG, we’ll double check that the new configuration looks OK. For each new rule, consider opening the properties for the rule and then using the Test Rule option.

We’ll also need to make sure the order of rules is set correctly. The Exchange 2007 and 2013 rules can come before or after each other as they do not conflict or override each other. However, our Exchange 2013 Outlook Web App rule must be second to our combined rule. This is because the rule for publishing Outlook Apps (the one that uses the GUID) includes a sub-directory of OWA, and we’ll want this rule to match before the main OWA rule.

You’ll see an example of the rules complete and in place below. Once you’re happy with your configuration, press Apply:

Image
Figure 30: Verifying new TMG rules before applying changes

Testing Coexistence

With Exchange 2007 and 2013 now functioning together, it’s time to re-test everything works as expected. At this stage some of the following tests should be conducted to ensure that the experience for clients during coexistence is as expected, including:

  • Testing OWA login for Exchange 2007 internally and externally
  • Testing OWA login for Exchange 2013 internally and externally
  • Testing AutoDiscover, EAS, EWS and Outlook Anywhere functionality using the Remote Connectivity Analyser for both Exchange 2007 and Exchange 2013 mailboxes
  • Testing setup of internal clients and ensuring the AutoDiscover process works as expected internally.

Summary

In this article we’ve completed the configuration of coexistence and at this point all clients accessing Exchange will make use of Exchange 2013 in some form, whether that’s for AutoDiscover, proxying for ActiveSync or en-route to access Outlook Web App. Theoretically, we’re ready to go so in the next part of this series we’ll prepare to migrate.

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

About The Author

2 thoughts on “Planning and migrating a small organization from Exchange 2007 to 2013 (Part 14)”

  1. It appears your directions are requiring TRG for coexistence. What if we are not using a TRG server and our firewall rules are pointing all external mail traffic to the Exchange 2007 server?

  2. Thanks for this usefull tutorial.
    I have a rule error regarding the legacy Exchange 2007.
    It says Error details: 0x80090322 – The target principal name is incorrect.
    In my SAN certificate I have all URL access :
    mail.domain.com (as principal)
    autodiscover.domain.com
    legacy.domain.com
    Exchange2007Server
    Exchange2013Server
    Exchange2007Server.internaldomain
    Exchange2013Server.internaldomain

    I don’t see what i’m missing

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