For this Exchange Server 2013 migration scenario we’ve already covered the decision to deploy the Preferred Architecture for Exchange 2013, and gathered information about the existing environment.
This article will cover namespace planning for Exchange Server 2013.
Namespace planning refers to the decisions that need to be made for the DNS names that will be used by clients such as Outlook and mobile devices when they are connecting to Exchange 2013 services.
When you install Exchange Server 2013 it is pre-configured with default namespaces matching the servers fully-qualified domain name (FQDN). For example, a server named sydex1.exchangeserverpro.net would be pre-configured with an Outlook Web App (OWA) URL of https://sydex1.exchangeserverpro.net/owa.
Even the simplest, single server deployment of Exchange Server 2013 should include namespace planning and reconfiguration of URLs to use an alias instead of the server’s FQDN. This has a number of benefits, such as allowing the namespace to be moved during server replacement, scale out, or migration in the future. It also gives end users easy to remember aliases for services such as OWA. After all, they are more likely to remember an alias such as “webmail.company.com” than a real server name of “consydexc01.company.com“.
The Microsoft Exchange Team blog has a comprehensive article on namespace planning that covers the unbound vs bound model, internal vs external namespaces, regional namespace considerations, legacy namespace considerations (for Exchange 2007 -> 2013 migration), and the changes in namespace requirements since Exchange Server 2007.
Namespace Planning
For this deployment that is aligning with the Preferred Architecture the unbound model will be used, which means a unified namespace for both datacenters that allows clients to connect to either datacenter under normal conditions. DNS round robin will be used to direct traffic to servers in both sites, with the option later to add hardware load-balancers at each site to make the solution more reliable by only performing DNS round robin between the two load-balanced VIPs instead of four server IP addresses.
To simplify the namespace configuration and certificate provisioning the following namespaces have been chosen. These are based on the existing namespaces deployed in the Exchange Server Pro organization, collected during the information gathering stage using the Get-VirDirInfo.ps1 script.
- autodiscover.exchangeserverpro.net (HTTP – Autodiscover)
- mail.exchangeserverpro.net (HTTP – Outlook Anywhere, OWA, ECP/EAC, ActiveSync, EWS, OAB)
- imap.exchangeserverpro.net (IMAP)
- pop.exchangeserverpro.net (POP)
- smtp.exchangeserverpro.net (SMTP)
Certificate Planning
With the namespaces chosen we can plan the SSL certificates for Exchange Server 2013. Even though Exchange Server 2013 installs with a self-signed certificate automatically, this certificate is unsuitable for client connectivity to Exchange because it will fail the validity check on at least two counts:
- That it doesn’t match the hostname the client is connecting to (after we’ve configured the new namespaces shown above)
- That it hasn’t been issued by a trusted certification authority
The third validity check is whether the certificate has expired or not, which is unlikely as the self-signed certificate is valid for 5 years.
Again, aligning with the Preferred Architecture and following the certificate planning and best practices advice from Microsoft we can arrive at a configuration involving one SSL certificate that will:
- include the HTTP, SMTP and POP/IMAP namespaces (a SAN certificate)
- does not include any server host names
- be installed on all Client Access servers (ie, same certificate for all servers, not separately provisioned certificates for each)
- be issued by a trusted third party certification authority such as Digicert
In the next article in this series we’ll look at reviewing Autodiscover configurations for the existing environment.
This article Exchange Server 2010 to 2013 Migration – Namespace and Certificate Planning is © 2014 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
