• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint Online
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Videos
    • Interview Videos
    • How To Guide Videos
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

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

Exchange Best Practices: Client Access Namespaces

January 13, 2016 by Paul Cunningham 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:

  • Namespace Planning in Exchange Server 2013 (Exchange Team blog)
  • Avoiding Server Names in SSL Certificates for Exchange Server
  • Exchange Server 2013 Client Access Server High Availability
  • Exchange Server 2016 Client Access Namespace Configuration
  • PowerShell Script to Configure Client Access URLs

Exchange Server Best Practices, Client Access, Exchange 2013, Exchange 2016, Namespaces, SSL

Comments

  1. Min says

    September 26, 2019 at 8:37 pm

    Hi Paul,
    When i read your article, i have already configured my SSL certificate to tied with https://server.domain.com

    Is it too late for me to change all of my namespace become https://mail.domain.com?

    Reply
  2. RavindraR says

    November 5, 2018 at 5:35 pm

    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

    November 8, 2017 at 2:17 am

    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
    • Rad says

      November 8, 2017 at 2:44 am

      Just realised that i can’t connect to migrated mailbox via Outlook. So only locahost/owa from active dag member works. I’ve definitely messed up something with Virtual Directories…

      Reply
      • Paul Cunningham says

        November 8, 2017 at 6:13 am

        What guidance are you following for the migration? During coexistence you need to migrate the namespaces to point to the highest version of Exchange in the org.

        https://www.practical365.com/exchange-server/exchange-server-2016-migration-preparing-for-coexistence/

        https://blogs.technet.microsoft.com/exchange/2015/10/26/client-connectivity-in-an-exchange-2016-coexistence-environment-with-exchange-2010/

        Reply
  4. Gustavo says

    March 19, 2016 at 1:04 am

    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

    January 29, 2016 at 5:15 am

    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

      January 29, 2016 at 8:29 am

      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

        January 29, 2016 at 11:19 pm

        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

          January 30, 2016 at 7:51 am

          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
  6. opsmexc says

    January 13, 2016 at 6:32 pm

    “Clients will receive inconsistent Autodiscover responses and profile configurations” >> this is really an important point and could produce unpleasant situations… >> see also my comments here in Ross IV article yesterday: http://blogs.technet.com/b/exchange/archive/2015/11/18/exchange-ad-deployment-site.aspx

    Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Microsoft Launches Group Ownership Governance Policy
  • Making the Case for Identity Governance in Azure Active Directory
  • Prepare an Office 365 migration plan assessment using PowerShell
  • Microsoft Releases May 2022 Exchange Server Security Updates
  • New Future of Work for Microsoft 365, IOT and more: Practical 365 Podcast S3 Ep. 2

Copyright © 2022 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland