Home » Exchange Server » Exchange Server 2016 Migration – Reviewing Client Access Namespaces

Exchange Server 2016 Migration – Reviewing Client Access Namespaces

During your review of your existing environment as you prepare to migrate to Exchange 2016, you should take the opportunity to review your client access namespace configuration.

The client access namespaces for Exchange are the DNS names that clients connect to with Outlook, web browsers, mobile devices and so on. Most client connectivity to the Exchange namespaces occurs over HTTPS and therefore requires correctly configured SSL certificates. POP and IMAP use their own secure login that is also encrypted using SSL certificates. Namespace configuration and SSL certificates go hand in hand, because the namespaces in use for Exchange need to be included on the SSL certificates being used on the server.

A mis-configured namespace makes a migration to a new Exchange server more difficult, and can result in poor user experience during the transition. So if there is a namespace problem, it’s best to discover it up front.

During the initial deployment of your existing Exchange environment the namespaces should have been reconfigured to use DNS aliases instead of real server names, even for single server deployments. Using DNS aliases allows the namespace to be moved during server replacement, load-balanced across multiple servers if the environment scales out to a high availability deployment, and also allows the namespace to be migrated to a new version of Exchange during an upgrade project. Using DNS aliases is also simpler for end users to remember. Typically users only need to know the URL for Outlook web access, with names such as webmail.notrealuniversity.com or mail.notrealuniversity.com commonly used.

If you named your Exchange server “mail” or “webmail” because that was the URL that you wanted your users to use when accessing Outlook Web App, that’s going to be a problem now that you are upgrading to a new Exchange server. Two Exchange servers can’t have the same name, and you can’t do an in-place upgrade of the existing server to Exchange 2016. You also can’t rename the existing Exchange server. So you may need to switch to a temporary namespace while you perform the migration, and then re-implement the preferred namespace later.

For the Not Real University environment there is an Exchange 2010 server, and an Exchange 2013 server. This provides us with the opportunity to demonstrate the process of reviewing namespaces for both of the versions of Exchange that you can migrate to Exchange 2016 from.

Reviewing HTTPS Namespace Configurations

Both Exchange 2010 and 2013 have the following HTTPS services:

  • Outlook Anywhere
  • Outlook Web App (OWA)
  • Exchange Control Panel (ECP)
  • Offline Address Book (OAB)
  • Exchange Web Services (EWS)
  • Exchange ActiveSync (EAS)
  • Autodiscover

Exchange 2013 also has the MAPI-over-HTTP service, sometimes referred to simply as MAPIHttp.

The client access namespaces for HTTPS services in Exchange are configured in several places, depending on the version of Exchange being used. A simple way to retrieve the client access namespaces is to use the GetExchangeURLs.ps1 script. For Exchange 2010 servers you can expect the Outlook Anywhere external URL to be empty, as well as the MAPIHttp URLs. For Exchange 2013, all servers should return URLs.

In the output above we can see that the client access namespaces being used for HTTPS services are:

  • mail.notrealuniversity.com
  • autodiscover.notrealuniversity.com (for Autodiscover)

In some environments you might see different namespaces for each service, if they are not using a unified namespace. It’s also common to see a different Autodiscover namespace being used, as is the case with Not Real University. By default, namespaces use the fully-qualified domain name of the server. For example, the default URL configured on an OWA virtual directory for a server named NREXCH10 in the notrealuniversity.com domain is https://nrexch2010.notrealuniversity.com/owa. If you see any real server FQDNs being used, that is an example of a mis-configured namespace, and it should be corrected before the migration project continues, by re-configuring the server to use a DNS alias as the namespace.

Note: The URL for the Autodiscover service, also referred to as the Autodiscover SCP, is configured on the Client Access server role by running the Set-ClientAccessServer cmdlet for Exchange 2010, or the Set-ClientAccessService cmdlet for Exchange 2013. The Get- cmdlets are used to view the current configuration. The Autodiscover virtual directory itself, which is visible in IIS Manager and also when running Get-AutodiscoverVirtualDirectory, is not used to configure the Autodiscover namespace. You can ignore any URLs configured on the Autodiscover virtual directory.

Reviewing MAPI/RPC Namespace Configuration for Exchange 2010

In addition to the HTTPS namespaces, the RPCClientAccessServer (or CAS Array) configuration for Exchange 2010 should be reviewed. First, check the RpcClientAccessServer attribute for the Exchange 2010 mailbox databases, which is the RPC endpoint that internal Outlook clients connect to for mailbox access.

If the results show a real server name being used as the RpcClientAccessServer, then it’s likely a CAS Array was never implemented (you can still check anyway, which we’ll look at next). If the results show a DNS alias, such as “casarray.notrealuniversity.com”, then a CAS Array was implemented. You can check for the CAS Array object itself by running the Get-ClientAccessArray cmdlet. There should also be a corresponding DNS entry for the CAS Array name, which resolves to the single Exchange 2010 server’s IP address, or resolves to a virtual IP address on a load balancer. In some environments the CAS Array IP address is found to resolve to the IP address of a database availability group, which is not a valid configuration (although it does happen to work, just badly).

The key issue with the CAS Array is whether the namespace used is different to that used for other Exchange servers, such as Outlook Anywhere. The CAS Array namespace should be unique. If it is not unique, then you have what is known as an ambiguous namespace. Under this condition the migration to Exchange 2016 from Exchange 2010 can’t begin until some remediation work is performed first. Microsoft has documented the solutions to fixing an ambiguous namespace for Exchange 2010 environments here.

The CAS Array, if one was implemented, will continue to be used by Outlook for Exchange 2010 mailbox users until they are migrated to Exchange 2016. The CAS Array itself is not required after the migration has been completed, as there is no CAS Array for Exchange 2016 (although you can still load-balance the client access namespaces across multiple servers, there’s just no CAS Array object used). Outlook clients use Outlook Anywhere or MAPIHttp for internal connectivity to Exchange 2016 instead of MAPI/RPC.

Reviewing POP/IMAP Configurations

Because the POP and IMAP services are not enabled by default, it’s possible they aren’t even being used in your environment. You can use Get-Service to review the POP and IMAP service status for your Exchange servers.

If POP or IMAP services are running, you can inspect the settings to try and determine what namespaces are used by clients for POP, IMAP, and SMTP. For POP and IMAP, the internal and external connection settings can be reviewed by running Get-PopSettings or Get-ImapSettings. You can also get a hint from the X509CertificateName setting, which should be configured to a DNS alias that has been included on an SSL certificate installed on the server. For example, to view the POP settings for the Exchange 2013 server in Not Real University, the following command is used.

The values configured in the POP/IMAP settings are visible to end users in OWA, but are not used by Autodiscover, and it’s common to find that they have not been configured even though other DNS names are used for clients to connect. Either way, clients still need to be manually configured. In the example above, the default values are present, which indicates that either POP clients are connecting to the server’s real name, or another DNS alias is used that has not been added to the POP settings on the server. In this case, Not Real University simply does not use POP or IMAP, and the services themselves are not running as you saw earlier.

For SMTP settings used by POP/IMAP clients, you can check the receive connector settings on the Exchange servers to determine whether they are advertising their FQDN for client configuration. For example, on an Exchange 2013 server the following command is used.

On an Exchange 2010 server, a similar command is used.

As with the POP/IMAP settings, the values for SMTP are advertised in OWA and are not used by Autodiscover. Clients are still manually configured for SMTP settings, and could be connecting to a DNS alias instead.

No matter what results you get for POP/IMAP and SMTP as shown above, it’s still worth checking your DNS zone for any obvious DNS aliases that might be in use by your clients, such as pop.notrealuniversity.com. Similarly, reviewing the configuration of some POP/IMAP users (if you know of any) would also be useful. If you need to identity some POP/IMAP users, you can temporarily enable protocol logging and look for usernames that are logging on. For example, to enable protocol logging for POP, use the following command.

Warning: Don’t leave POP or IMAP protocol logging enabled longer than you need to. There is no automatic log retention for POP/IMAP protocol logging, so the log files will simply continue to grow until they consume all available disk space.


In this article we looked at reviewing the namespace configuration of your existing Exchange servers. We looked at how to retrieve the namespaces used for HTTPS services, RPC access in Exchange 2010, and also how to determine the namespaces that may be in use for POP, IMAP, and SMTP. In the next part of this series we’ll look at how to review your SSL certificates when planning a migration to Exchange 2016.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. MikaelJones says:

    Great writeup. If a company is on E2010 using mail.company.com (everthing correctly configured) and at the “same time” when moving to E2016 want to change this URL to mail.othername.com (becausr of re-branding), would you recommend doing so before or after the mailbox migration?

  2. TLN says:

    Hi Paul,
    When I ran the “Get-MailboxDatabase” again the Exchnage 2016 databases, the “RPCClientACcessServer” point to the Exchange 2010’s CAS array, is this correct or I have to remove it.

      • DEV says:

        I see the same result when I do Get-MailboxDatabase, however I have clients specifically over VPN that are unable to connect to Exchange 2016. I believe it has to do with the CAS Array as that is the URL that resolves even if I put the FQDN of exchange 2016 into Outlook.

        I have verified DNS resolves correctly to both Exchange 2010 and 2016. Do I need to remove the cas array config to get my users back working with Outlook over VPN?

        We are almost done with our migration Public Folders is moving soon then decommission.

          • DEV says:

            I miss spoke. the casarray.contoso.com and exch16.contoso.com both resolve correctly. We do not have DNS that resolves to both.

            I believe we found our problem. Once we removed the cas array on Exch 2010, this allowed our users to autodiscover over VPN and connect successfully to 2016. I’m not sure if this is related to the bug that makes 2016 CAS members of the array or not, but def removing the array corrected our issue.

  3. Tom says:

    Hey Paul,

    great article!

    I have one question, if the autodiscoverSCP is configured to https://autodiscover.domain.tld/autodiscover/autodiscover.xml for exchange 2010 and also for exchange 2016. That’s not working in my opinion and the autodiscoverSCP must be different if you migrate from exchange 2010 to exchange 2016. Otherwise the Outlook connectivity will fail for mailboxes are still in exchange 2010.

    Am I right?

    Thanks in advance

    • The Autodiscover SCP should be the same for all servers within an AD Site. The Autodiscover SCP must resolve in DNS to the highest version of Exchange in the site as well. So in a 2016/2010 coexistence scenario where both servers are in the same AD Site, they should have the same Autodiscover SCP configured, and that DNS record should point to Exchange 2016, not Exchange 2010. Exchange 2016 proxies Autodiscover requests to the appropriate server, so in effect it can answer Autodiscover queries for mailbox users on both 2016 and 2010. Exchange 2010 can’t proxy Autodiscover requests to Exchange 2016, so if you have Autodiscover resolving in DNS to the Exchange 2010 server, any Exchange 2016 mailbox users will not be able to use Autodiscover.

Leave a Reply

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