Skip to content

The checklist for preparing your Exchange 2007 infrastructure for Exchange 2013 coexistence | 9#23

In the current article, I would like to review the subject of the required preparation that we will need to implement in the Exchange CAS 2007 environment before or while we are moving to the “new” Exchange 2013 coexistence environment.
In this article, we will briefly review the different “parts” that we will need to relate to when implementing Exchange 2013/2007 coexistence environment and review in more details the specific updates that relate to the legacy namespace that we need to configure the different Exchange CAS 2007 services.

Legacy namespace and the required preparations

The implementation of the legacy namespace in Exchange 2013/2007 coexistence requires us to make the necessary preparations such as different network infrastructures.

The required preparations for the Exchange 2013/2007 coexistence environment not considered as “rocket science.” On the other hand, in case that we are not aware of the required preparation and for the particular setting of the different “parts” the project of the Exchange 2013/2007 coexistence environment could be safer from severe problems.

To be able to assimilate the “new legacy namespace successfully” in the Exchange infrastructure, we will need to implement the following steps:

  1. DNS infrastructure – we will need to add the hostname – “legacy” to the internal + external DNS infrastructure. In the internal DNS infrastructure, the host name legacy will be “mapped” to the internal\private IP address of the Exchange CAS 2007 server and, in the In the external DNS infrastructure; the host names legacy, will be “mapped” to the public IP address of the Public facing Exchange 2007 CAS server.
  2. Public certificate infrastructure – We will need to add the FQDN: legacy.mail.o365info.com to the public certificate that is used by the Exchange infrastructure.
  3. Exchange CAS 2007 infrastructure – we will need to update the internal + external URL address of the Exchange CAS 2007.
  4. Firewall infrastructure – we will need to add new incoming rules that will enable external Exchange 2007 clients to access the Public facing Exchange 2007 CAS server.

Just a quick quote from a Microsoft article:

“In order to support external client coexistence with CAS2007 and legacy Exchange in your “Internet Facing AD Site”, you will (potentially) need to acquire a new commercial certificate. As a best practice, Microsoft recommends utilizing a certificate that supports Subject Alternative Names; however, you can use a wildcard certificate as well.
This commercial certificate that will be leveraged by external clients will contain at a minimum three SAN value (note that other scenarios may require you to add additional values):
mail.contoso.com (your primary OWA/EAS/OA accesses URL)
autodiscover.contoso.com
legacy.contoso.com (your OWA/EAS namespace for legacy mailbox access)”

Source of information: Transitioning from an Exchange 2007 environment to Exchange 2007

Exchange namespace and DNS infrastructure

In the following diagram, we can see an example of the “re-point” concept. Before the implementation of the Exchange 2013/2007 coexistence environment, the public DNS records of the Autodiscover and the Public facing Exchange CAS server host name were pointing to the Exchange 2007 CAS.

Public DNS records points to Public facing Exchange 2007 server-01

After the implementation of the Exchange 2013/2007 coexistence environment, the public DNS records of the Autodiscover and the Public facing Exchange CAS server host name will point to the Exchange 2013 CAS.

Additionally, we will need to add a new record to the existing DNS infrastructure: the legacy namespace record.

In our scenario, the legacy namespace that will point to the Exchange CAS 2007 is: legacy.mail.o365info.com

Reconfigure the records to point Exchange 2013 CAS + legacy namespace record -01

In a Split DNS infrastructure, the updates of the DNS records will need to be implemented for the Internal DNS infrastructure and the External DNS infrastructure,

In the following diagram, we can see an example of the required DNS configuration settings.

Required preparation - DNS Infrastructure - Split DNS -1

Exchange 2013/2007 coexistence environment – Internal Autodiscover infrastructure considerations

Based on the assumption of our scenario, in which the Exchange 2007 Autodiscover namespace infrastructure was based on the concept of a Joint\contiguous namespace, for example – autodiscover.o365info.com, we will need to verify the implementation of the following requirements.

  • DNS Infrastructure – verify that the internal\external DNS infrastructure will be updated by “mapping” the Autodiscover record to the IP address of the Exchange 2013.
  • Verify that the Exchange 2013 CAS will be registered at the Active Directory SCP using the host name: autodiscover.o365info.com
Exchange 2013 - 2007 coexistence - Required preparation - internal Autodiscover 01

In the following diagram, we can see the implementation of the internal Autodiscover infrastructure in an Exchange 2007 environment.

  1. Exchange 2007 client query Active Directory for the name of the Autodiscover Endpoint and the answer is: autodiscover.o365info.com
  2. The Exchange 2007 client query DNS for the IP address of the host: autodiscover.o365info.com and the “DNS answer” include the IP address of the Exchange 2007 CAS.

In the following diagram, we can see the implementation of the internal Autodiscover infrastructure in Exchange 2013/2007 coexistence environment.

  1. Exchange 2007 client query Active Directory for the name of the Autodiscover Endpoint and the answer is: autodiscover.o365info.com
  2. The Exchange 2007 client query DNS for the IP address of the host: autodiscover.o365info.com and the “DNS answer” include the IP address of the Exchange 2013 server.
  3. The Exchange 2007 client will address the Exchange 2013 CAS, and the Exchange CAS server will proxy the request to the Exchange 2013 mailbox server.
Exchange 2013 - 2007 coexistence - Required preparation - internal Autodiscover 02

Public certificate and the subject of legacy namespace

In the previous section, we mentioned that we would need to create a new legacy namespace and in the DNS infrastructure points this record to the Exchange CAS 2007.

In most of the mail client connectivity protocol flow, Exchange 2007 client will try to verify the identity of the Exchange CAS 2007 but checking his public certificate.

For this reason, we will need to purchase a new public certificate or update an existing public certificate to include the legacy namespace. In our scenario: legacy.mail.o365info.com

In the following screenshot, we can see an example of a public SAN certificate that included the legacy namespace host name: legacy.o365info.com

Public certificate with the legacy namespace -01

Other considerations

When implementing an Exchange 2013 coexistence environment, there are many other additional elements and considerations that need to be “included” in the preparation checklist.

Just a little taste of the additional requirements could be:

  • DNS infrastructure and MX records
  • In a scenario of Exchange 2013 coexistence environment, we will need to point to MX records to the “new Exchange 2013 CAS” that configured as the Public facing Exchange CAS server instead of the previous Exchange 2007 CAS.
  • Firewall infrastructure
  • We will need to update the Firewall rule that relates to the mail infrastructure was pointed to the IP address of the Exchange 2007 server to the “new IP address” of the Exchange 2013 server.

Exchange CAS 2007 legacy namespace | Basic concepts

Before we start from the description of the “checklist” list” of the required update in the Exchange 2007 environment, let’s briefly review the concept of the legacy name.

In our scenario, the legacy name whom we choose for “representing,specific” the Exchange 2007 infrastructure will be: legacy.mail.o365info.com

The host name: legacy.mail.o365info.com mapped to the IP address of the Exchange CAS 2007 server.

The new Exchange 2007 legacy namespace

When we say that: “we need to update the Exchange CAS 2007 URL address” the meaning is: replacing the host name part of the Exchange CAS 2007 URL address that is allocated for the different Exchange CAS 2007 services.

The new legacy namespace that we update is related to the part of the FQDN from the URL address of a particular Exchange web service. In other words: we don’t change or update that “structure” of the Exchange CAS 2007 URL address but only the server name.

For example: in case that the URL address of OWA mail services was: https://mail.o365info.com/owa

We will update the URL address to use the “new FQDN”: legacy.mail.o365info.com and the “new URL address” will be: https://legacy.mail.o365info.com/owa

The new OWA URL address with the legacy namespace

Implementing required updates of legacy namespace in Exchange 2007 infrastructure

We can classify the required updates that we will need to implement in the Exchange 2007 infrastructure into two major groups:

  1. Legacy namespace updates – updates in which we will “replace” existing Exchange CAS 2007 hosts names that used up until now, with the “new hostname” meaning the legacy namespace.
  2. “Pointing” Exchange 2007 services to the Exchange CAS 2013 infrastructure – this part relates to additional services: Autodiscover Endpoint name and Outlook Anywhere – external host name (RPC Endpoint name).
    Before the implementation of the Exchange 2013/2007 coexistence environment, these services was “represented” by the Exchange CAS 2007 infrastructure. When we add the Exchange CAS 2013 to the existing Exchange 2007 infrastructureparticularservices should be “pointed” to the Exchange CAS 2013 instead of the Exchange CAS 2007.
Exchange 2007 services infrastructure checklist

Updating the Exchange 2007 URL address to use the legacy namespace

We can divide the required updates in the Exchange CAS 2007 infrastructure, into three “sections”:

1. The Exchange CAS 2007 services that relate to providing Exchange CAS 2007 access to their mailboxes

In the section, we include three different Exchange CAS 2007 services that are used by three different mail clients:

  • Exchange 2007 OWA clients – we will need to update the internal + the external OWA URL address to use the legacy namespace.
  • Exchange 2007 ActiveSync clients – external Exchange 2007 ActiveSync will be served by the Exchange CAS 2013. For this reason, we need to set the external URL address to “empty”.
    Regarding the internal ActiveSync URL, we will need to set the URL address to use the legacy namespace.
  • Exchange 2007 Outlook clients – in case that the Exchange CAS 2007 support Outlook Anywhere services, we can leave the value of the “external hostname” as it is because the value is based on the primary namespace. In case that the Exchange CAS 2007 didn’t include support for Outlook Anywhere services, we will need to enable the Outlook Anywhere services and for the value of the “external host name” use the hostname who will be “mapped” to the Exchange CAS 2013 server.
Providing access to mailbox services - Exchange 2007 clients

2. Exchange CAS 2007 – Exchange web service

As mention before, in Exchange 2013/2007 coexistence environment, the element that provides Exchange web service to the Exchange 2007 clients is the Exchange CAS 2007.

The process in which Exchange 2007 clients are “informed” about the URL address of their Exchange web services, is implemented as part of the Autodiscover process.

The ability of the Exchange CAS 2013 to provide Exchange 2007 client information about the “legacy Exchange CAS 2007 infrastructure” is implemented by using the legacy namespace.

For this reason, we will need to update the Exchange CAS 2007, Exchange, web service value of the internal + the external URL address to use the legacy namespace.

Providing Exchange web service - Exchange 2007 clients -01

3. Exchange CAS 2007 | internal Autodiscover Endpoint name

By default, each of the existing Exchange CAS servers, “register” himself at the Active Directory SCP. In a “pre Exchange 2013 coexistence environment”, the Exchange CAS 2007 is registered in the Active Directory SCP as an “Autodiscover Endpoint”.

In an Exchange 2013/2007 coexistence environment, we need to change the default Autodiscover infrastructure and make sure that the only source for Autodiscover infrastructure will be the Exchange CAS 2013.

Scenario 1: in case that the Autodiscover infrastructure is based on a concept of the identical host name (FQDN) for the Autodiscover Endpoint name such as: autodiscover.o365info.com, there is no need to use an update procedure because the update implemented via the DNS infrastructure. The update performed by using the IP address of the Exchange CAS 2013 instead of the previous setting, which based on the IP address of the Exchange CAS 2007.

Scenario 2: in a scene of “non-identical Autodiscover Endpoint names” in which the internal Exchange server registered in the Active Directory SCP by using an internal name,
For this reason, we will need to implement a procedure in which each of the legacy Exchange CAS servers will “re-register” himself at the Active Directory SCP but now, using the host name of the Exchange CAS 2013.

Providing Autodiscover services - Exchange 2007 clients -01

The Exchange CAS 2007 services URL address and Host name matrix

To be able to successfully manage all the required updates that need to be implemented in the Exchange CAS 2007 infrastructure, we can use the following table as a “checklist list”.

Updating the Exchange 2007 services

The general guideline or concept is the in Exchange 2013/2007 coexistence environment the Exchange CAS 2013 inherits the primary namespace such as: mail.o365info.com

The legacy namespace will be ”attached” to the different Exchange CAS 2007 services and regarding other services such as – Outlook Anywhere and the internal Active Directory address; Exchange 2007 client will use the “primary namespace” that is “mapped” to the Exchange CAS 2013.

In our scenario, the legacy namespace that was chosen for the Exchange CAS 2007 infrastructure is: legacy.mail.o365info.com

OWAWe will update the internal + external OWA URL address to use the legacy namespace. In our scenario, the Exchange 2007 OWA URL will be: https://legacy.mail.o365info.com/owa
ActiveSyncWe will update the internal ActiveSync URL address to use the legacy namespace. In our scenario, the Exchange 2007 ActiveSync internal URL will be: https://legacy.mail.o365info.com/Microsoft- Server-ActiveSync
Exchange web serviceWe will update the internal + external Exchange web service URL address to use the legacy namespace. In our scenario, the Exchange 2007 OWA URL will be: https://legacy.mail.o365info.com/EWS/Exchange.asmx
URL Address summery table - Exchange 2013 -2007 coexistence environment

Outlook Anywhere service

With required setting that relates to Outlook Anywhere service, that we will need to implement in the Exchange 2007 infrastructure are as follows:

1. External host name

Verify if the Exchange CAS 2007 supports the Outlook Anywhere services.
Case 1: if the Exchange CAS 2007 support Outlook Anywhere services, we will need to update the authentication protocol setting.

Case 2: in case that the Exchange CAS 2007 doesn’t support Outlook Anywhere services, we will need to enable the Outlook Anywhere services, and for the value of the external host name choose the host name who is “used by Exchange CAS 2013”. For example, in our scenario, we will configure the external host name as: mail.o365info.com

External host name
Outlook AnywhereWe will need to verify that the value of the external host name uses the primary namespace. In our scenario, the external host name is: mail.o365info.com

2. External client authentication protocol

We will need to verify that the value of the “External client authentication” sets of essential.

3. IIS authentication method

We will need to configure the value of the:” IIS authentication method“ to: basic and NTLM

Exchange 2007 server setting - Outlook Anywhere services

Autodiscover service internal URI.

In Exchange 2013/2007 coexistence environment, the internal (and the external) Autodiscover services should point to the Exchange CAS 2013.

Case 1: in case that the Exchange CAS 2007 was configured to use a standard Autodiscover namespace, such as: autodiscover.o365info.com, there is no need to implement any updates.

Case 2: if the Exchange CAS 2007 were configured to use an internal name as the Autodiscover name, we would need to update this information to point to the Exchange CAS 2013 Autodiscover internal name.

Exchange 2007 server setting - AutoDiscover Service Internal URI

Using PowerShell for updating the Exchange CAS 2007 URL address

Technically, we can use the Exchange CAS 2007 GUI interface for updating some of the URL address such as the OWA URL address but other URL addresses such as the URL address of Exchange web services can be updated only by using PowerShell.

To be able to simplify the update operation, we can use a simple PowerShell script which includes two variables: the Exchange CAS 2007 server name + the legacy namespace.
After we update these variables, we apply the legacy namespace to all the required Exchange CAS 2007 URL addresses.

Set the Exchange CAS 2007 services.

In our example, we will set the following Exchange CAS 2007 services:

  • OWA
  • ActiveSync
  • Exchange web service

The updates will include the legacy namespace that we have chosen for our legacy Exchange 2007 infrastructure. In our scenario, the legacy namespace is: legacy.mail.o365info.com

The Exchange CAS 2007 server name in our scenario is: CAS2007

Set the Exchange CAS 2007 services - Scenario description

In the following diagram, we can see that syntax of the PowerShell syntax that we will need to use

Update Exchange CAS 2007 URL address using the legacy namespace - PowerShell command syntax

1. Set the Exchange 2007 OWA URL address

The PowerShell command that we use for setting the OWA URL address to use the legacy namespace is:

Set-OwaVirtualDirectory "CAS2007\owa (Default Web Site)" -ExternalUrl https://legacy.mail.o365info.com/owa -InternalUrl https://legacy.mail.o365info.com/owa

The PowerShell command that we use for viewing the setting of the OWA URL address is:

Get-OwaVirtualDirectory -Identity "CAS2007\owa (default Web site)" | FL identity, internalUrl, ExternalUrl

2. Set the Exchange 2007 ActiveSync URL address

The PowerShell command that we use for setting the ActiveSync URL address to use the legacy namespace is:

Get-ActiveSyncVirtualDirectory -Server CAS2007 | Set-ActiveSyncVirtualDirectory -InternalURL "https://legacy.mail.o365info.com/Microsoft-Server-ActiveSync" -ExternalURL $null

The PowerShell command that we use for viewing the setting of the ActiveSync URL address is:

Get-ActiveSyncVirtualDirectory -server CAS2007 | FL identity, internalUrl, ExternalUrl

3. Set the Exchange 2007 Exchange web service URL address

The PowerShell command that we use for setting, the Exchange web service URL address to use the legacy namespace is:

Get-WebServicesVirtualDirectory -Server CAS2007 | Set-WebServicesVirtualDirectory -InternalURL "https://legacy.mail.o365info.com/EWS/Exchange.asmx" -ExternalURL "https://legacy.mail.o365info.com/EWS/Exchange.asmx"

The PowerShell command that we use for viewing the setting of the Exchange web service URL address is:

Get-WebServicesVirtualDirectory -server CAS2007 | FL identity, internalUrl, ExternalUrl

Manage and update the Exchange 2007 – Outlook Anywhere settings.

In Exchange 2013/2007 coexistence environment, Exchange 2007 client Outlook client will address the Exchange CAS 2013 and the Exchange CAS 2013 will proxy the communication request to the Exchange CAS 2007.

To be able to “CAS to CAS” communication, we will need to set the value of the IISAuthenticationMethods to: NTLM and basic authentication

Additionally, set the ClientAuthenticationMethod to: basic

Update Exchange CAS 2007 Outlook Anywhere settings -PowerShell command syntax

The PowerShell command that we use for setting the IISAuthenticationMethods authentication to use NTLM and basic is:

Set-OutlookAnywhere -Identity "CAS2007\Rpc (Default Web Site)"
-IISAuthenticationMethods NTLM,Basic

The PowerShell command that we use for setting the ClientAuthenticationMethod authentication to use basic is:

Set-OutlookAnywhere -Identity "CAS2007\Rpc (Default Web Site)" -ClientAuthenticationMethod:Basic

The PowerShell command that we use for viewing the setting of the Outlook Anywhere settings is:

Get-OutlookAnywhere -Server CAS2007

Update the Exchange 2007 Autodiscover Endpoint name registration in the Active Directory SCP

In case that the Exchange CAS 2007 was registered at the Active Directory SCP using an “internal name”, we will need to update the existing value of the Autodiscover Endpoint to point the Exchange CAS 2013 Autodiscover Endpoint name.

The syntax of the PowerShell that we will us for updating and viewing the value of the AutoDiscoverServiceInternalUri is:

Update Exchange CAS 2007 Autodiscover Endpoint name - PowerShell command syntax

In our scenario the Exchange CAS 2013 Autodiscover Endpoint is: autodiscover.o365info.com

Set-ClientAccessServer -Identity "CAS2007" -AutoDiscoverServiceInternalUri "https://autodiscover.o365info.com/autodiscover/autodiscover.xml"

The PowerShell command that we use for viewing the setting of the AutoDiscoverServiceInternalUri URL address is:

Get-ClientAccessServer -Identity CAS2007 | FL identity,AutodiscoverServiceInternalUri
o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has One Comment

  1. Hi Sir,
    I just want to verify one issue,
    I used Quest(Dell) tool to migrate AD user from one forest to another forest, exchange2013/exchange2007 server only in source forest,and during migration, set the source account disabled,
    then after migration, target account exchange service(owa/activesync/outlook) woking fine.
    but for some reason, if I enable source account manually, then both source/target user can not use owa service,
    as showing “tokenmungingexception”, i found the solution to change the target account from linked mailbox to user mailbox, but as migration is still ongoing, and we follow the exchange forest architecture, we do not know whether it’s exchange2013 architecture changed or not, as in same scenario exchange2007 and exchange2010 working fine even both source/target account enabled. it’s very strange why it only impact the owa service in exchange2013.
    Could you help me? it’s actually not the migration tool(Quest migration manager) issue.
    thanks
    Guo Gang

Leave a Reply

Your email address will not be published. Required fields are marked *