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.
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
This article Exchange Best Practices: Client Access Namespaces is © 2016 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
