Home » Exchange Server » Exchange Server 2016 Client Access Namespace Configuration

Exchange Server 2016 Client Access Namespace Configuration

When you first install Exchange Server 2016 it is pre-configured with default URLs for the various HTTPS services such as OWA (Outlook on the web), ActiveSync (mobile device access), Exchange Web Services (the API used for a variety of client communications), and others.

The default URLs contain the fully qualified domain name of the server. So for example if your server name is “exchange01.domain.com” then the default URL for OWA will be “https://exchange01.domain.com/owa“.

These default URLs allow the services to function but they are not suitable for production deployments for several reasons such as:

  • They are difficult for end users to remember (this primarily impacts Outlook on the web, where users tend to find it easier to remember a URL such as “webmail.domain.com“)
  • A URL containing a specific server name can’t be load-balanced across multiple servers in a high availability deployment
  • The internal AD namespace for many organizations is not a valid domain name on the internet, for example domain.local, which makes it impossible to acquire SSL certificates for Exchange 2016 (I’ll cover SSL certificates in a separate article coming soon)

The recommended practice is to change the URLs configured on your Exchange 2016 servers to aliases or generic host names such as “mail.domain.com” after you first install the server.

While there are a variety of namespace designs that apply to different deployment scenarios I will demonstrate here the simplest approach, which is to configure the same namespace (URL) for all services. I’ll be demonstrating with a single Exchange Server 2016 server, but this approach can also be used if you have multiple Exchange servers that you want to load balance (which I’ll cover in a future article).

In my example scenario:

  • The server’s real name is demoex16.exchange2016demo.com
  • The namespace I’ll be using is mail.exchange2016demo.com
  • Internal and external namespaces will be the same

Using my GetExchangeURLs.ps1 script I can see the current configuration of the server.

In this article we’ll look at:

  • Configuring DNS records for the new namespace
  • Configuring the namespaces via the Exchange Admin Center
  • Configuring the namespaces via PowerShell
  • Using a PowerShell script to speed up the configuration of Client Access namespaces

Configuring DNS Records for the Client Access Namespaces

Before changing your server’s namespace configuration you should make sure that the DNS records for the new namespaces already exist in DNS. Some of the virtual directory configuration tasks can fail if the name you specify isn’t resolvable in DNS.

In this example scenario I’ll be using split DNS, which is a recommended practice for Exchange Server 2016 deployments. Split DNS means I will host a DNS zone on my internal DNS servers, and use that to resolve mail.exchange2016demo.com to the internal IP address of my Exchange server (or load balancer if this was a high availability deployment).

Meanwhile, the public DNS zone also has a mail.exchange2016demo.com record that resolves to the public IP address of my firewall or router, which will then NAT any external connections to the Exchange server’s internal IP.


Add the records to both of the zones in your split DNS configuration and make sure they are resolving correctly before you continue.

Configuring Exchange Server 2016 Namespaces Using the Exchange Admin Center

After logging in to the Exchange Admin Center in your organization navigate to Servers -> Virtual Directories and select the server you want to configure. There are two approaches you can take. The first is clicking the wrench icon to configure the external namespace for one or more servers.


A window appears that allows you to add one or more servers and specify an external namespace to use.


The outcome of this approach is that all of the external URLs are configured to use that namespace, but the internal URLs remain untouched. This is not ideal for our goal of configuring all services to use the same internal and external namespace.

Instead you can edit the configuration of each virtual directory listed in the Exchange Admin Center by clicking the edit icon.exchange-2016-configure-namespaces-03

From here you can edit both the internal and external namespaces for the virtual directory, as well as additional settings such as authentication.


This will achieve the desired outcome, but it is a slow and tedious task. For a single server it would be annoying, for multiple servers it would be downright frustrating. Also, if you ever needed to reconfigure the server you’d need to manually repeat the task.

Instead let’s look at using PowerShell to make the namespace configuration changes.

Configuring Exchange Server 2016 Namespaces Using PowerShell

In a previous article on avoiding server names in SSL certificates I demonstrate how to configure each virtual directory in Exchange Server using PowerShell. You can read that article for a full demonstration but in summary you can run cmdlets such as Set-OWAVirtualDirectory to configure the OWA virtual directory internal and external URLs. Each of the other virtual directories has its own cmdlet for configuring settings, including the Autodiscover virtual directory even though we don’t actually need to configure that one (instead we configure the AutodiscoverServiceInternalUri on the Client Access server).

For example, to configure the same URLs for OWA as shown in the screenshot above:

As with the Exchange Admin Center this task can become quite tedious as you move through each virtual directory on every server. But of course if the task can be performed in PowerShell it can be scripted!

Using a PowerShell Script to Configure Exchange Server 2016 Client Access Namespaces

Automating boring tasks is one of PowerShell’s great strengths, and this task is no different. Since every virtual directory (and the Autodiscover service URI) can be configured in PowerShell we can write a script to perform the task quickly.

In your own environment you could manually write out each of the PowerShell commands for your server names and simply save them in a script file. Or you can use my ConfigureExchangeURLs.ps1 script with a few easy to use parameters.

Here’s an example of how I can apply my desired namespace configuration to my Exchange 2016 server using ConfigureExchangeURLs.ps1.

Now let’s look at the output of GetExchangeURLs.ps1 again.

Now that the namespaces are configured the next step is to configure an SSL certificate for the server. I’ll cover that in an upcoming article.


In this tutorial we looked at the default namespace configuration of a newly installed Exchange 2016 server, and discussed why we should configure Client Access namespaces for the server. As you can see there are several methods available for making the configuration changes, with the PowerShell script being the easiest by far. If it is your first time configuring a server it is worth doing the task manually the first time to gain some understanding of what is involved, but if you’re planning to deploy multiple servers then using a script such as ConfigureExchangeURLs.ps1 is highly recommended.

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. Gabriele Massari says:

    Hi Paul,
    why not add a control that allows the script to configure the autodiscover scp as autodiscover.domain.com (if specified as parameter) instead of sharing the URL with all the others virtual directories?

    Already edited the script 😉


  2. Alpesh says:

    Hello Paul,

    We have a unique requirement where we do have same internal and external URLs however we want to block a certain set of users from accessing from internet, however at the same time allow others.

    If I used Set-CASMailbox UserEmailAddress -MAPIBlockOutlookRpcHttp $true I am unable to connect even within the org.

    The above command per my understanding and discussions with Microsoft should only block connections coming from internet however, it blocks from internal as well and outlook client gets disconnected even when on LAN. Is there any way to achieve what I am trying to? We are using UAG to publish Outlook Anywhere however we cannot join UAG to our internal Production domain because of some company policies.


    • All Outlook connectivity to Exchange 2013 and 2016 is RPC over HTTP (Outlook Anywhere), unless you’ve also deployed MAPI over HTTP. But either way, there’s no distinction between internal and external protocols now, it’s the same protocol being used for both.

      So in your case, you’ll need to work out a way to pre-authenticate users coming in externally and allow/block before they reach Exchange.

  3. SLJ says:

    Paul, you are simply THE MAN! I’ve been using your articles for years. Whenever I’m googling around for an Exchange solution, I always append exchangeserverpro to the search term. Thanks for everything you do!

  4. Mat says:

    Thank you Paul for the post.
    If my Internal and external namespaces are not the same as your example, What is the Best practice for the Client Access Namespace Configuration ? For instance, suppose that I have demo.local as my internal domain name and company.com as external namespace and I have 3 exchange servers in DAG: exch01.demo.local, exch02.demo.local and exch03.demo.local
    I assume I can have for Internal url https://mail.demo.local/owa or ecp or oab ect… and for External url https://mail.company.com/owa or ecp or oab ect.. What do you say about it ?

    • Your internal Exchange URLs don’t need to match the AD namespace. They can be whatever you want them to be.

      The recommended practice is to use the same internal and external namespace, with split DNS.

      I don’t recommend trying to use any .local or other domain that you don’t own, because it is going to complicate things with your SSL certificates.

      • Jack says:

        Dear Paul,

        I am facing the same issue with the above post.

        I have a domain “x.com” that was deployed in the past, and the external domain is x.com.lb.

        I am facing issues with the internal users as the Outlook is asking for credentials every time the user opens it. if I remove the outlook profile and recreate it it works for the first time, then when i close outlook and then reopen it, it asks for credentials again, and providing the credentials doesn’t work.

        I have Exchange 2016 MBX role, and have configured split DNS.

        Please advise.

      • Tomasz says:

        simply create new forward lookup zone in your DNS named mail.company.com and create an empty A record, pointing to IP address of exchange.
        Works for me also with round robin 🙂

    • Tomasz says:

      simply create new forward lookup zone in your DNS named mail.company.com and create an empty A record, pointing to IP address of exchange.
      Works for me also with round robin 🙂

  5. Chris Trevino says:

    In the article you show using GetExchangeURLs.ps1 to pull the current server info. The link points to ConfigureExchangeURLs.ps1. I do not see the GetExchangeURLs.ps1 on your github. These scripts should help clean up our current problems.

  6. Wesley Hader says:

    Hey Paul,

    Great article! I have used it as a reference twice when setting up Exchange environment.

    My question is related to certificate warnings when I am attempting to configure Outlook 2013 to connect to my Exchange mailbox.

    I have Split-DNS configured and have used the script ConfigureExchangeURLs to set internal and external URLs to the same name (e.g. mail.company.com).

    When setting up Outlook account, the certificate warning shows (servername.company.local).

    What am I missing? Is there an AD setting that determines where the autoconfiguration of Outlook should look to find the Exchange Server name?

    Keep doing what you do!


  7. Marcel says:

    Thanks for this article. We want to use separate urls for services OWA and ECP. We want to do that because we want to go trough a Kemp reverse Proxy (in DMZ) and have Internet users and Internal users have the same OWA/ECP experience (use same forms based logon page)
    Would it be possible to configure internal DNS to point owa and ecp to the Kemp reverse proxy and the other services to the Exchange Server directly?

    Configure Internal DNS and Exchange Internal URLS:
    owa.company.com -> Kemp in DMZ
    ecp.company.com -> Kemp in DMZ
    mail.company.com -> Exchange server directly for all other services like rpc, autodiscover and ews.

    Configure External DNS and Exchange External URLS:
    mail.company.com -> NAT’ed internet IP to Kemp in DMZ.

      • You can use separate URLs for each service, and on each service you can also use separate internal and external URLs. So there is complete flexibility when it comes to how you want to design your namespaces.

        However, everything you do that adds complexity will make your configuration harder to implement, manage, and troubleshoot.

  8. prasant says:

    If I am using same name to services on active server to passive server. Do I need to export SSL certificate from active server and apply imported certificate to imap, pop, audiscover etc? Or it is not required after I changed connection point to mail.domain.com as defined on active server and certificate will automatically recognize it.

    Also, I would like to included a question about the another forum about DNS round robin of CAS service on two exchange with all roles –

    Do I also need round robin in internal DNS zone for mail.domain.com along with external round robin

    • Yes, you should use the same SSL certificate on all servers that are configured with the same namespaces.

      DNS round robin, or any load balancing for that matter, is not mandatory. You should use DNS round robin or load balancing wherever you want high availability. So if you want high availability for your internal network clients connecting to Exchange, then yes you should use DNS RR or load balancing.

  9. prasant says:

    Thanks for the reply Paul. I applied certificate and services with same name on passive server. During the process I realized that IMAP was the only service that did not have common FQDN, therefore, I did not change in on passive either.

    The only issue I noticed was Outlook 2011 for MAC was unable to connect after the above change. Therefore, I have shut passive server down to restore client connection for Outlook 2011 for MAC

  10. jos says:

    Thank you for the post !!!
    I have 2 mail box servers load balanced by KEMP.The internal and external url s are same. Now I am planning to deploy 1 edge transport server, so what all changes I need to take care for internal and external DNS?

    Currently external DNS have A record mail.xyz.com which will NAT to my KEMP, also MX associated with it.

    I can’t find the name space design for an environment with Edge transport server. It will be helpful if u can guide me on the name space, DNS and certificate requirement s for an environment with Edge server also.

    • Edge transport and client access namespaces are two different things. There’s lots of guidance available for setting up Edge Transport if you search on Google or TechNet. If you want to use mail.xyz.com for your MX record, and that currently NATs to your Kemp, then you just need to have Kemp send the SMTP traffic to your Edge Transport server.

  11. David says:


    Thanks very much for the article, it was very thorough and helpful. This is our first install of Exchange 2016 and I have a few bridges not yet crossed.

    Our previous Exchange 2013 environment was a split DNS .local implementation and it had a few pain points when it comes to internal/external DNS resolution. I’ve seen an abundance of documentation suggest abandoning the .local naming convention for AD namespaces and using a subdomain of the .com – or in our case, ad.domain.com.

    What are the internal/external DNS implications of this setup? Our domain host is resolving mail.domain.com to our public IP. Our firewall forwards traffic on that IP to the private IP of our Exchange server, which has a FQDN of EXCH.ad.domain.com. Does that create any issues with internal DNS resolution or with certificate naming? I have a UC Certificate with 3 SAN’s but I haven’t researched which SAN’s we’ll need in this go around.

    Any advice to get us off on the right foot?

  12. Maurice says:

    Hi Paul

    I have set the internal and external URLs to be the same, however all Outlook internal user traffic is going out to the internet to retrieve there email.

  13. movi says:

    As you know exchange 2010 use rpc cliient access array, and exchange 2013/2016 use https,
    how the name mail.abc.com of client access of 2013/2016 will communicate with that rpc client access array name of mail.abc.com during migration if we wantto use the same name/ssl cert ?
    kindly clarify.

  14. Peter says:

    Hello, GetExchangeURLs.ps1 doesn’t run on our Exchange 2010 Server. We receive the following error in the Management Shell:
    [PS] D:Tools>.GetExchangeURLs.ps1 -server rzsrv21
    < : Der Operator "<" wird noch nicht unterstützt.
    + CategoryInfo : ParserError: (<:OperatorToken) [], ParseException
    + FullyQualifiedErrorId : RedirectionNotSupported
    Any idea, Thanks

  15. CK says:

    How would this work if you have several AD sites in a single forest and a distributed Exchange deployment with a 2016 server in each site? One server is internet facing, the rest are just internal.

  16. filip says:

    Hope you can and will answer my question.
    – Is it wise to keep internal & external authentication on VDIR the same and what is most common configuration (keep the same)?

    And if we have a KEMP or TMG or F5 reverse proxy for external users and we just NLB the CAS servers internally , should we keep internal & external authentication the same?

  17. Raed M says:

    Hi Paul,

    I have Exchange 2013 MB & CAS server with same URL for both internal and external.

    I am adding Exchange 2016 [DAG configuration] to existing environment to be able to migrate the mailboxes from Exchange 2013 to Exchange 2016.

    I will install the new Exchange 2016 on 2 servers.
    Create the DAG
    Create the Exchange 2016 server round robin DNS [internal DNS]
    Install the external SSL certificate.
    Update the virtual directories with the external and internal URL.
    Start the mailbox move

    Is this the right approach without causing any issues to the existing 2013 environment.

    Thank You in advance and we multiple Exchange 2016 articles.


  18. SJ04 says:

    Hi paul,

    I have bought your Migration book for exchange server 2010 to exchange 2013 and planning to make the migration according it.

    I have a question about the Namespaces. currently we have exchange 2010 Servers.
    1: cas server
    2: mailbox and hub transport server.

    and the external name space is mail.domin.com and internal namespace is https://svv-ex2010.domain.com.

    so before i start the migration i do need to change the Internal name space and make standard internal namespace.

    and then i have to start the migration of it.?


  19. SJ04 says:

    Hi paul,

    thanks for your Quick response.
    just one more singal question about changing the internal URL on the exchange 2010 Server.
    can i use this your script to Change only the internal URL and if i change the Internal URL for the running system , how is going to affect the running enviroment?
    will there be any Security warning or Connection time out error ?



    • The script is a basic tool for setting URLs on new servers that are being deployed. In your situation, you’re changing an existing server in production, so there’s more at stake.

      I would suggest that you first document all of your client access URLs, internal and external. Then, create two scripts of your own. The first is going to make the changes to your server configuration. The second is to revert the changes to their original settings. The scripts don’t need to be fancy, it’s just a set of PowerShell commands. But that gives you a rollback method if something goes wrong. Next, double check that your SSL cert includes the name you’re about to change the internal URLs to (just to be sure).

      When you’re ready to make the change, run the first script, then check the results. Recycle the Autodiscover app pool in IIS, and test with your clients. If there’s any issues, you can run the second script to roll back (and recycle the app pool again). Do all this at a low impact time for your customers, and all should be fine.

  20. Sascha Kuemmel says:

    Hello Paul,

    great series you have provided. Many thanks for that.
    You may want to update your cmdlets, as Exchange 2016 CU1 has recommended to use “Get-ClientAccessService” and “Set-ClientAccessService” instead of “Get-ClientAccessServer” / “Set-ClientAccessServer”. Cmdlets are marked to be removed in future releases.


  21. Britton Johnson says:

    I’m unable to get the GetExchangeURLs script to run properly. Do I need to have some Java Script engine installed on the server?

    Below is the Red errors that show when trying to run it.

    At C:tempGetExchangeURLs.ps1:119 char:13
    + <a href="/open-source" class="js-selected-navigation-item nav-item n …
    + ~
    The '<' operator is reserved for future use.
    At C:tempGetExchangeURLs.ps1:121 char:13
    + <a href="/business" class="js-selected-navigation-item nav-item nav- …
    + ~
    The '<' operator is reserved for future use.
    At C:tempGetExchangeURLs.ps1:123 char:13
    + <a href="/explore" class="js-selected-navigation-item nav-item nav-i …
    + ~
    The '<' operator is reserved for future use.
    At C:tempGetExchangeURLs.ps1:125 char:11
    + ~
    The ‘<' operator is reserved for future use.
    At C:tempGetExchangeURLs.ps1:138 char:8
    + <!– –><form accept-charset="UTF-8" action="/cunningh …
    + ~
    The '
    + ~
    The ampersand (&) character is not allowed. The & operator is reserved for future use; wrap an ampersand in double
    quotation marks (“&”) to pass it as part of a string.
    At C:tempGetExchangeURLs.ps1:1065 char:11
    + © 2016 <span title="0.04655s from github-fe165-cp1-prd.iad.github …
    + ~
    The ampersand (&) character is not allowed. The & operator is reserved for future use; wrap an ampersand in double
    quotation marks ("&") to pass it as part of a string.
    At C:tempGetExchangeURLs.ps1:1065 char:23
    + © 2016 <span title="0.04655s from github-fe165-cp1-prd.iad.github …
    + ~
    The '<' operator is reserved for future use.
    At C:tempGetExchangeURLs.ps1:1065 char:29
    + © 2016 GitHub’ in expression or statement.
    At C:tempGetExchangeURLs.ps1:1065 char:100
    + … “>GitHub, Inc.
    + ~
    Missing argument in parameter list.
    Not all parse errors were reported. Correct the reported errors and try again.
    + CategoryInfo : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : RedirectionNotSupported

  22. TLN says:

    Hi Paul,
    I installed the Exchange 2016 in an existing Exchange 2010 environment with split DNS, when I update the webmail.domain.com and autodiscover to point to Exchange 2016 server, mailbox on 2010 took 2 to 3 minutes to startup.

  23. Nicholas says:

    Hi Paul,

    This is invaluable and thank you! One question – aside from the difficulty configuring/troubleshooting – is there any other reason to NOT use separate internalURL and externalURL

    Our company policy is to not use internal namespaces externally so we were planning to setup like,

    InternalURL : mail.contoso.com
    ExternalURL: mail.contosogroup.com

    • The most common reason is if you want different internal and external authentication methods to be used.

      If you have a company policy to comply with that’s fine. I’d suggest it’s probably just as simple in your case to use the external URL for both, but if the internal URL is what people are used to using for OWA access internally then stick with that.

      Keep in mind that both names will need to be on the SSL certificate anyway, so it’s not like you’ll be completely hiding your internal namespace from the world.

  24. Stefan Desira says:

    We have an existing Exchange 2013 environment with 2 Exch2013 servers having different internal and external namespaces.

    I am currently deploying a third and fourth Exchange 2016 servers and would like to standardise namespaces to match, both internal and external for all servers.

    Eventually all Exch 2013 mailboxes will be moved onto the Exch 2016 servers with a DAG.

    If I change all existing servers to have the internal and external namespaces matching, what will be the impact on existing connections from Outlook clients? And what can I do to mitigate any issues?

    Many Thanks and keep up the good work! Bought the Exch Server 2016 Quick start guide which I’m finding really helpful.

  25. Phuong, Nguyen Van says:

    Hi Paul,
    When I run script ConfigureExchangeURLs.ps1 to config owa, ecp,..
    When configuration step mapi script ask IISAuthenticationMethods[0]:
    Which authentication values ?


  26. Chris says:

    Hi Paul

    I realized today that no available servers appear in the menu -> configure external access domain -> select the servers to use with the external URL and then click on + sign. No servers appear their

    this is exch 2016 CU3

    is it a bug?

  27. Joe says:

    Paul, this article was exteremely helpful, especially since we have been chewing up three out of 4 names in our Digicert SAN.

    Your config script generates an error for the External MAPI url assignment. It wants an authentication method. Any suggestion as to what to use: NTLM, oAuth, Negotiate?

    Thanks >> Joe

  28. ndfan77 says:

    If the Internal URL and the External URL’s are exactly the same (i.e. because we implemented the split DNS approach) for:


    Is there actually any purpose for, or benefit to, setting both the ExternalURL and the InternalURL? What purpose does it serve? Are these not, in essence, setting different paths (URL’s) for IIS to recognize these various Exchange functions — so what benefit is there in having a second path (the ExternalURL) defined that has exactly the same value as the first (the InternalURL)?

    I’ve read through all the questions & answers on this thread, and on some of the other threads, and can’t see where this question was asked or answered.

    I’m in the process of setting up a like-for-like migration and so far I’ve only configured the internal URL for these settings on the new server (to use the commercial certificate via split DNS for internal access) and it seems to be working fine. Outside access is working, and no certificate errors from inside hosts.

    Many thanks again for providing this site and service!

    • IIS doesn’t care what the URLs are.

      The internal and external URLs are provided to clients via Autodiscover. The ability to have separate URLs means that all scenarios are catered for, whether the org needs them to be the same or different.

  29. Chad says:

    Hey Paul,

    I have a company that has been renamed. They want to change their OWA link to represent the new company name. I understand how to change the internal and External URL’s and am using split DNS. They are currently using a Wildcard cert for all URLs. I have purchased a new mail.newcompanyname.com cert that I want to use for the OWA. My understanding is that in order to assign the new cert it needs to be assigned to the IIS services via ECP. In doing so it will change the cert for OWS, as well as ECP, active-sync and outlook anywhere.

    My concerns are, if I assign the new cert the IIS services and change the URLs, will the Outlook clients pick up those changes automatically? And for any mobile devices, users will need to change their server settings to mail.newcompanyname.com in order to connect without a cert error.

    Trying to minimize the end user impact as much as possible.

    Thanks in advance!!

    • I think the best approach will be to generate a new certificate that has both the old and new names on it (a SAN or UCC certificate, depending on who you buy it from they might call it different things).

      That way you can get the cert in place and deal with the transition without risking users connecting to the wrong name at the wrong time.

  30. Gary says:

    Hey Paul,

    Just a note. I was fighting with my external clients not being able to connect after enabling MAPI over HTTP while installing E2016 into my E2013 environment. My servers have Active Directory names ending in .local, while I’m using a .edu name for my internal and external URLs. For a couple hours, it appears my autodiscover was somehow still feeding my .local names to my clients. Then suddenly, as I was beginning to type up the question to you, I tried one more time and things started working. Is there some kind of update delay when changing these URLs before the clients actually see the changes?

    I’m not actually at work right now to test it, but I’m hoping my internal clients will finally stop trying to use the .local names as well and stop giving my users those annoying certificate name mismatch errors.

  31. Darren says:

    Hi Paul,
    Great article and very helpful.
    I am currently in the migration process from 2 Exchange 2010 servers to 4 Exchange 2016 servers in different sites. All Exchange servers are Internet facing.
    I do not have any DAGs set up.
    Should the namespaces for both internal and external be the same for all Exchange servers?
    How do clients access their mailbox?

    • Not enough info to give advice for your situation, but generally speaking you can choose one namespace for all sites, or choose unique namespaces for each site. It’s up to you, and depends on many factors such as available bandwidth, whether you’re doing HA across the sites, and so on.

      • Darren says:

        Hi Paul,

        Thanks for the prompt response.
        All sites but 1 has a 20/20 Fibre connections, the other 1 has a 50/50 Fibre connection.
        At the moment there is no HA set up, but might set this up in the future if that will change how to configure it in the first place.
        At the moment, we have migrated some users to the new Exchange 2016 servers do some testing, but are having issues with some accounts and not with others.
        Some users Outlook profile setups are trying to point to the old Exchange 2010 server, however others work fine.
        At the moment I have set all Exchange servers up with the same internal and external namespaces (mail.domain.com.au) and and set up internal DNS to point to the site with the 50/50 Fibre connection.
        All users in the 50/50 site are fine but some users in the other sites are having issues.

        • There’s a few things that you need to consider for co-existence.

          For Autodiscover, there should either be one Autodiscover namespace for all sites, and that DNS record should resolve to the 2016 server(s) only. Or, there should be one Autodiscover namespace per site, and the Autodiscover site scopes configured appropriately. In each site the AutoD namespace should resolve in DNS to the highest version of Exchange.

          For other namespaces, check that your Outlook Anywhere namespace is not the same as the RPCClientAccessServer name for each of the 2010 databases (aka, the CAS Array namespace). If so, you’ve got an ambiguous namespace issue (search that term and you’ll find Microsoft’s blog post for what to do).

          Also, if there’s 2010 public folders, the 2016 mailbox users will still connect to 2010 for PF access. If you’ve got Kerberos auth enabled, there’s additional config required for legacy PF access (again, Google for Microsoft’s guidance).

          Aside from that, you’d need to be more specific about the issues you’re seeing.

  32. Dan says:


    A great article, thank you for this. I have question about split-dns. I’ve setup autodiscover.companyname.com and mail.companyname.com on our Internal DC DNS to point to the Exchange 2016’s internal IP. Externally, the same names point to the external IP. InternalURL and ExternalURL’s are set to the same name on all services.

    Our Exchange server is at our HQ and all our branch users have site to site VPNs to the HQ. If a VPN goes down then users will still be able to resolve the Exchange/Autodiscover names due to each site having a DC running DNS, however the internal IP of the Exchange server wont’ be available. Will clients Outlook somehow figure out to go externally (Like Outlook Anywhere is used by our field based staff)? If not, do I need to create different Internal and External URLs? I was just trying to get away from that is all since we can’t (Or can’t soon) have both Internal and External Domains on a SAN cert I believe and I didn’t want too many Certs to complicate things.

  33. Thomas T says:

    Hi Paul,
    I have a test lab with 2 Exchange 2016’s EX01 & EX02 in DAG and RoundRobin DNS. My goal is to test a failover solution if fx. one of them is taken offline.
    What is the best practise for setup if EX01 is offline and I want EX02 automatically to take over all functions until EX01 is back online??

    Have searched the entire web, but no actual sites describes in detail what to setup other than Mailbox availability DAG.


    • The DAG provides the mailbox HA. Your client access namespace design and load balancing (or DNS RR) provides the client access HA. There’s also transport (mail flow) HA to consider, which you control through your inbound routes (MX records, NATing on firewall/edge router) and outbound routes (send connectors), as well as any internal SMTP relay (e.g. a receive connector that permits specific devices to relay mail).

  34. robert says:

    Hey Paul

    In you CAS – Load Balancer video on pluralsight, you say that a L4 loadbalanced VIP cannot check more than 1 CAS service using the healthcheck.htm check.

    I understand how to work around it (multiple namespaces or use L7). But does that limitation exist? how come a L4 VIP cannot check more than 1 service?


    • It’s not a question of whether the load balancer can check multiple services or not for a L4 service (maybe some can, I don’t know, there’s a lot of load balancers out there).

      Layer 4 means all the LB can see is the server IP and port that the client is requesting. It has no awareness of individual vdir that the client is requesting. So no matter what awareness the LB might have about individual service health, it can’t know what the client is requesting, so it can’t make accurate per-protocol/per-service decisions about where to send that client connection.

      So in L4, you have the LB health check a single service, and if that service is down, treat the entire server as unhealthy, because you can’t tell whether the client is requesting that service or another one.

      tl:dr – if you want per-protocol health awareness in your load balancing, use L7.

  35. Tim says:

    First can I say that having just done an Exchange 2010 to 2016 migration, your website is a mine of well presented and useful information.

    I’m hoping that you might be able to help on a specific namespace issue we are having difficulty understanding. We have two Ex 2016 servers – (Bill and Ben for arguments sake). We have all our external URLs pointing at Ben and the internal ones pointing at themselves – so Bill on Bill and Ben on Ben.

    Internally this works just fine – Outlook opens a raft to connections to Bill and/or Ben as it sees fit – there seems to be no pattern.

    Externally however, despite the fact that all externals are pointing at Ben, Outlook running on a laptop outside the company still opens connections to Bill.

    This is only an issue because we don’t want Bill to be visible on the internet and therefore the connections will fail.

    Why does Outlook not just use the external addresses when on an external network?

    • If the connections to Bill (or Ben) by their real server name are possible externally, that suggests that they are publicly resolvable DNS names. If that’s the case, the client will connect to them, because it’s going to try the internal namespace first. If you don’t want internal namespaces being used externally, you should config DNS so that they are not externally resolvable.

      Also, it’s not recommended to leave server names as internal URLs. You should still use an alias.

      • Tim says:

        As a test we blocked access to Bill on the firewall and our external test machine running Outlook 2016 just hung – even after restart it didn’t try and access Ben at all.

        Does it require that Bill is not resolvable externally to force it to try the alternate?

          • Tim says:

            Correct, as usual, making it un-resolvable forces Outlook to put all connections to Ben.

            Not sure why Microsoft didn’t use the same logic when something is un-reachable, probably the same rationale as making an Outlook phone app that won’t allow you to update Contacts.


          • The logic is fine. Internal names shouldn’t be externally resolvable. And there’s a difference between something being completely unresolvable vs being resolvable but not contactable (which could just be a transient issue).

  36. nashwa says:

    hi Paul

    i really appreciate your articles ,it’s very detailed,helpful , organized ,thanks for your great explanation .

    i just have some question regarding the ConfigureExchangeURLs.ps1 script

    why you assign the externalclientauthenticationmethod parameter with the value of the variable $outlookanywhwre as long as the external method already had the same value as the variable $outlookanywhwre in configuring outlookanywhere

    as long as we can configure url of autodiscover with the internal url variable in case we didn’t specify a value to the variable $AutodiscoverSCP what the need of dedicating a variable like $AutodiscoverSCP to configure the autodiscover or you use this variable in case you want to use a url name that differ from the internal url name

    • The -ExternalClientAuthenticationMethod parameter needs to be used when running Set-OutlookAnywhere to set URLs, so it’s included in the command and it just sets it to whatever the configuration setting is already set to (in other words, it doesn’t change the setting that is already in place).

      The $AutodiscoverSCP parameter is optional. Some environments set a different Autodiscover URL, some don’t. That is a design decision for you to make.

  37. James says:

    Hey Paul

    Does this still apply if you are using GSLB in a multi site configuration with a DR?
    If databases are activated on the DR servers, without shutting down the exchange servers in the primary site, will this cause relay or proxy issues for mail access?

    Should we be keeping the DR External URL blank until performing a Datacenter failover?

  38. Does what still apply? Configuring namespaces? Sure. I don’t know your environment or requirements, but I don’t see why you would complicate your DR solution by requiring extra steps for a site failover.

  39. Hazem says:

    Hi Paul
    I have scenario that I migrating exchange 2010 to 2016 at two sites, and I need to use bound model.
    I have the following:
    1. VIP on site A
    2. VIP on site B
    3. Name spaces are “autodiscover.domain.com, mail.domain.com, mail.sitea.domain.com, mail.siteb.domain.com”
    My quarries are:
    1. Should I use one autodiscover name space for two sites, and if so which VIP should I point it for DNS record.
    2. Should I use Mail.domain.com name space, and if so which VIP should I point it for DNS record.
    3. Should I use SRV record for autoiscover, and if so which VIP or DNS record should I point it for DNS record.

Leave a Reply

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