Practical 365

You are here: Home / Exchange Server / Exchange Best Practices: Client Access Namespaces

Exchange Best Practices: Client Access Namespaces

by 12 Comments

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.

exchange-best-practices-namespaces-01

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.

exchange-best-practices-namespaces-02

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:

Comments

  2. RavindraR says

    Hello Paul,
    We want to split mailboxes across two different AD Sites, physically separated.

    Currently we have 02 CAS 2013 with WNLB & 02 MBX 2013 server with 01 DAG with access point as https://mail.domain.com/

    Now we have deployed new exchange 2013 setup @ new AD site with 02 CAS 2013 with WNLB & 02 MBX 2013 server with 01 DAG.

    Can we have new access point namespace for new AD site for the mailbox been moved.
    Currently mail.domain.com is proxying the request to other AD site.

    Also please suggest in regards to the separate OAB

    Reply

  3. Rad says

    Hi Paul,

    I’m in the process of migrating from single EX2010 to 2016 DAG (2 members). 2016 Servers are in same AD site but different network – another office linked via lease line (all pingable via IP and DNS etc). At the moment I’ve got all Virtual directories pointing to webmail.client.com. This internally and externally points to EX2010 box. Now, after migrating test user to 2016 i can access it fine via Outlook client – no issues with internal and external mail flow. I can also access this via localhost/owa from server where active mailbox with test user is. But when trying to access this from second DAG member via localhost/owa or webmail.client.com/owa (internally or externally) i got “A server configuration change is temporarily preventing access to your account…” hope that makes sense 🙂
    Any help appreciated
    Thx
    Rad

    Reply

  4. 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,

    Gustavo

    Reply

  5. 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.

    Reply

    • Paul Cunningham says

      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.

      Reply

      • 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.

        Reply

        • Paul Cunningham says

          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.

          Reply

Leave a Reply

You have to agree to the comment policy.