Home » Exchange Server » Exchange Best Practices: Client Access Namespaces

Exchange Best Practices: Client Access Namespaces

When deploying Exchange Server 2013 or 2016 there are some best practices to be aware of for your namespace configuration.

  • Servers within an Active Directory site should have the same namespaces configured
  • Namespaces should not contain server fully qualified domain names (FQDNs)
  • Exchange namespaces should be domain names that your organization owns (this is important for DNS resolution, and for SSL certificate requirements)

When Exchange is first installed it is configured with namespaces (URLs) for each virtual directory that match the server’s FQDN.


This default configuration presents some issues:

  • A server’s FQDN can’t be load-balanced across multiple servers
  • Clients will receive inconsistent Autodiscover responses and profile configurations
  • SSL certificates for the server’s FQDN can’t be acquired from a public CA, if the domain name isn’t owned by the organization (such as a .local domain or a generic “corp.com” domain)
  • Migrating to new servers or versions of Exchange will be complicated

After installing the server you should configure the client access namespaces.


Note that each service (OWA, Outlook Anywhere, ActiveSync, Autodiscover, etc) can have a unique namespace. However, using the same namespace for all services is often the simplest, and therefore easiest, configuration to use.

For multi-site deployments of Exchange the namespace model will depend on your database availability group (DAG) design:

  • The “Unbound” namespace model uses the same namespace across both datacenters in a site-resilient pair, with the DAG configured in an Active-Active topology
  • The “Bound” namespace model uses a different namespace for each datacenter in a site-resilient pair, with the DAG configured in an Active-Passive topology
  • The “Regional” namespace model uses different namespaces for different regional datacenters or datacenter pairs (whether those are bound or unbound)

What about single server deployments? Should the namespaces on those also be changed to not use the server FQDN?

Yes. Even for a single server these best practices apply. Consider that even for a single server deployment:

  • The server will one day be replaced by a new server, so the namespace will need to be migrated
  • The deployment might expand to a multi-server deployment later, requiring a namespace that can be load-balanced
  • The SSL certificate requirements still apply
  • The server might be integrated with Office 365 in a Hybrid configuration, which requires the namespace and SSL certificate configuration to be correct

More information about Exchange Server 2013/2016 namespace configuration:

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. Mike says:

    Paul, I have replaced my multi role Exchange 2010 SP2 with a new multi role Exchange 2010 SP3. I had issues that almost no Outlook profile realized that there is a new server. I had to repair or even renew most of the Outlook profiles. Could you explain to me what happened there? Thank you.

    • Sounds like you hadn’t considered the RPCClientAccessServer namespace, also known as the CAS Array. If that namespace was implemented correctly, you could simply switch it over to the new server via DNS and not require profiles to be repaired.

      • Mike says:

        Yes, the old server was created before my time, of course without a CAS array. What confuses me is that I had a similar migration from 2010 to 2013, also no CAS array but I had no problems with the Outlook profiles. Any pointers for the future for these scenarios? Thank you.

        • When a mailbox is moved from 2010 to 2013 the Outlook client stops connecting to RPC over TCP (to the 2010 server) and starts using Outlook Anywhere (RPC over HTTP), which at the time of the migration should already be pointing at the 2013 server.

          So there’s no problems in that case because the RPCClientAccessServer (or CAS Array) for 2010 is no longer relevant.

  2. Gustavo says:

    Hi Paul,

    I have a doubt,

    I Have a client with 2 sites (SiteA and SiteB) eahc in different geographic locations.
    1 Exchange 2013 per site obviously each in different location
    1 DAG between them.

    I have configured:

    but my client not have a load balancer, so i configured the following:

    MX1 and OWA = mail.contoso.com > IP-1 in siteA
    MX2 and OWA = mail1.contoso.com > IP-1 In siteB
    MX3 and OWA = mail2.contoso.com > IP-2 in siteA
    MX4 and OWA = mail3.contoso.com > IP-2 In siteB

    CNAME SiteA = OwaSiteA.contoso.com > IP-2 in siteA (different from first IP in mail with S-NAT to exchange)
    CVNAME SiteB = OwaSiteB.contoso.com > IP-2 in siteB (different from first IP in mail with S-NAT to exchange)

    So, when the users cant have access to OwaSiteA.contoso.com or OwaSiteB because an ISP goes offline, it goes through OwaSite”A or B”.contoso.com, but if have a datacenter switchover, users will semi-automatically and internal (between AD sites) redirected to your mailbox in another SiteB, of course, if it´s alive.

    but how can be the right setup if i have 2 different Public IP address (obviously) 1 for each site and namespace ? Because if i dont be wrong, it can be the same FQDN mail.contoso.com with 2 Public IP Address if dont have a Load Balancer right ?? If i setup this way, its a round robin right ?

    So, for that reason it was implemented in that way.

    What you thinks about my configuration ??

    And what about SSL Certificate ?? i have imported same certificate to SiteB exchange, but is this right ? or i have to implement different certificate with the same SAN subjects contents. Let me explain better, two CA request, one for each exchange ?

    Thanks Paul !!

    Kind Regards,


Leave a Reply

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