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.
I am also having a problem in connecting to exchange server on site A when we shut the server in site B , even the exchange server on site A which is hosting the mailboxes of site A users is operational.
Outlook clients from site A also could not connect to their mailboxes .
When i checked the connection status on their outlook , i realized that they try to connect over the exchange server on site B.
How can i make each outlook clients to connect directly to their exchange server on their own sites , not using the remote proxy ?
Hi, What will happen if i use new auto discover URL and mail URL for exchange 2013 which are different that of exchange 2010.
Example: Exchange 2013: autodiscover.domain.global and mail.domain.global
Exchange 2010: autodiscover.contoso.com and mail.contoso.com
So, when 2010 outlook client user try to configure profile, how does he/she connects to exch 2010…. Can you please explain what exactly happens here?
Note: My exchange 2013 is split brain DNS and autodiscover.domain.global and mail.domain.global are same URLs for internal and external. Customer already planned this and hosted and now am in a dilemma of what happens if we bring 2013 with different autodiscover and mail URL and how 2010 client will be proxied to 2010 CAS.
Thanks for your help and needless to say that your articles are very well structured.
Paul,
Great series! Any chance you’ve got a WBS available for download?
The Real Person!
The Real Person!
A WBS?
A work breakdown structure – kind of a step-by-step instruction list in MS Project, Word, Excel that could be customized for our environment. I’ve been preparing one for our team based on your series here and thought I’d ask if you already had one to save some time. Thank you!
The Real Person!
The Real Person!
Ok. No I don’t have anything like that to share.
Hi Paul,
Thanks for nice series, what about if there are multiple branch sites with single CAS & Mailbox servers. In this scenario don’t we need server names in certificate?
Thanks
The Real Person!
The Real Person!
No. Don’t put server names on SSL certs.
https://www.practical365.com/avoiding-exchange-2013-server-names-ssl-certificates/
Ok I installed Exchange 2013 in my lab and I migrated a few users over. However I cannot connect Outlook 2007 to exchange 2013 , Outlook is @Sp and that patch. I guess my question is do I need that ssl cert and that’s why my outlook 2007 clients are not connecting? Just trying to figure out why or what am I’m missing. Just for lab purposes who can I get around using the SSL cert that comes with Exchange 2013. Thanks.
The Real Person!
The Real Person!
Use an internal CA if you don’t want to buy a cert.
https://www.practical365.com/exchange-2013-ssl-certificate-private-certificate-authority/
Pingback: Exchange 2010 to 2013 Migration – Configuring Client Access Servers
Hi Paul,
Can I use this solution for exchange 2010? I need to design and request active/active same name space certificate, but only found active/active different name space solution in msexchange.org.
Thanks,
Jose Perez
Why we need SMTP.exchangeserverpro.net ?
The Real Person!
The Real Person!
In this example scenario smtp.exchangeserverpro.net is the DNS alias used by other apps/devices that need to connect to an SMTP service to send email.