Certificate Planning in Exchange 2013
Published Mar 19 2014 06:00 AM 54.1K Views
Microsoft

Now that we understand the load balancing and namespace planning principles and how clients connect in an Exchange 2013 environment that has Exchange 2007 and/or Exchange 2010 deployed, the proper certificates can be constructed and deployed as part of the upgrade process.

Of course it goes without saying that there are a few rules you should follow in crafting your certificates:

  1. Use as few certificates as possible.
  2. Use as few host names as possible.
  3. Utilize the Subject Alternative Name (SAN) attribute on the certificate.
  4. Use the Exchange Certificate Wizard within the Exchange Admin Center to request certificates.
  5. Deploy the same certificate across all CAS in the datacenter pair.
  6. Deploy Vista SP1 or later clients so that you do not have to worry about the certificate principal name value.

Wildcard certificates are an option as well. A wildcard certificate for *.contoso.com results in a certificate that will work for mail.contoso.com, legacy.contoso.com, and autodiscover.contoso.com namespaces.

To understand what host names should be included in the certificate request, three scenarios will be considered that leverage the architecture principles discussed in the prior articles.

Scenario 1

Contoso has offices in Redmond, WA and Portland, OR. Contoso’s users utilize Outlook Anywhere, ActiveSync, Outlook Web Access, and IMAP clients connecting to an Exchange 2007 platform deployed in both sites.

They have recently completed a network upgrade that increases the available bandwidth between datacenters and removed single points of failure for the end users, allowing the end users to connect to either datacenter in the event of a WAN failure. With respect to load balancing, Contoso will continue to terminate SSL at the load balancer.

As part of the upgrade to Exchange 2013, Contoso will deploy a site resilient Database Availability Group in an active/active configuration.

As a result of these choices, Contoso will require the following namespaces:

  1. autodiscover.contoso.com – necessary to support client configuration.
  2. legacy.contoso.com – necessary to support Exchange 2007 clients during coexistence.
  3. mail.contoso.com – the primary namespace for OWA, ActiveSync, and Outlook Anywhere.
  4. smtp.contoso.com – the namespace used by SMTP clients (e.g., IMAP clients).
  5. imap.contoso.com – the namespace used by IMAP clients.

Scenario 1
Figure 1: Scenario 1 - Layer 7 Load Balancing with Unbounded Model

Contoso completes their planning and pre-deployment testing and deploys Exchange 2013 Client Access and Mailbox servers. The certificate wizard is used to craft the certificate request, including the namespaces identified above. Once the certificate is received from the certificate authority, Contoso utilizes the Certificate wizard to import the certificate across all Client Access servers in both datacenters and enables the certificate for the IIS, SMTP and IMAP services.

Scenario 2

Contoso has offices in Redmond, WA and Bel Air, MD. Contoso’s users utilize Outlook Anywhere, ActiveSync, Outlook Web App, connecting to an Exchange 2010 platform deployed in both sites.

Contoso has sufficient bandwidth to replicate databases between datacenters; however, Contoso prefers that the users access their data out of their local datacenter, unless there is a failure event.

As part of the upgrade, Contoso decides to leverage the enhancements in Exchange 2013 by disabling SSL termination on the load balancers. As a result, Contoso recognizes they will need to deploy client specific namespaces so that they can manage the health correctly on the load balancers.

As a result of these choices, Contoso will require the following namespaces:

  1. autodiscover.contoso.com – necessary to support client configuration.
  2. mail-wa.contoso.com – the primary namespace for OWA in the Redmond, WA datacenter.
  3. mail-md.contoso.com – the primary namespace for OWA in the Bel Air, MD datacenter.
  4. mailfb-wa.contoso.com – the failback namespace for OWA in the Redmond, WA datacenter.
  5. mailfb-md.contoso.com – the failback namespace for OWA in the Bel Air, MD datacenter.
  6. eas-wa.contoso.com – the primary namespace for EAS in the Redmond, WA datacenter.
  7. eas-md.contoso.com – the primary namespace for EAS in the Bel Air, MD datacenter.
  8. oa-wa.contoso.com – the primary namespace for Outlook Anywhere in the Redmond, WA datacenter.
  9. oa-md.contoso.com – the primary namespace for Outlook Anywhere in the Bel Air, MD datacenter.
  10. ews-wa.contoso.com – the primary namespace for Exchange Web Services in the Redmond, WA datacenter.
  11. ews-md.contoso.com – the primary namespace for Exchange Web Services in the Bel Air, MD datacenter.
  12. oab-wa.contoso.com – the primary namespace for the Offline Address Book in the Redmond, WA datacenter.
  13. oab-md.contoso.com – the primary namespace for the Offline Address Book in the Bel Air, MD datacenter.

Scenario 2
Figure 2: Scenario 2 - Layer 4 Load Balancing with Bounded Model

Contoso completes their planning and pre-deployment testing and deploys Exchange 2013 Client Access and Mailbox servers. The certificate wizard is used to craft the certificate request, including the namespaces identified above. Once the certificate is received from the certificate authority, Contoso utilizes the Certificate wizard to import the certificate across all Client Access servers in both datacenters and enables the certificate for the IIS service.

Scenario 3

Contoso has offices in Redmond, WA and Portland, OR. Contoso’s users utilize Outlook Anywhere and Outlook Web App connecting to an Exchange 2007 platform deployed in both sites.

They have recently completed a network upgrade that increases the available bandwidth between datacenters and removed single points of failure for the end users, allowing the end users to connect to either datacenter in the event of a WAN failure. With respect to load balancing, Contoso has decided to not utilize SSL termination at the load balancer once the namespace is moved to Exchange 2013.

As part of the upgrade to Exchange 2013, Contoso will deploy a site resilient Database Availability Group in an active/active configuration.

As a result of these choices, Contoso will require the following namespaces:

  1. autodiscover.contoso.com – necessary to support client configuration.
  2. legacy.contoso.com – necessary to support Exchange 2007 clients during coexistence.
  3. mail.contoso.com – the primary namespace for OWA clients.
  4. oa.contoso.com – the namespace used by Outlook Anywhere clients.
  5. ews.contoso.com – the namespace used by EWS clients.
  6. oab.contoso.com – the namespace used for Offline Address Book downloads.

Scenario 3
Figure 3: Scenario 3 - Layer 4 Load Balancing with Unbounded Model

Contoso completes their planning and pre-deployment testing and deploys Exchange 2013 Client Access and Mailbox servers. The certificate wizard is used to craft the certificate request, including the namespaces identified above. Once the certificate is received from the certificate authority, Contoso utilizes the Certificate wizard to import the certificate across all Client Access servers in both datacenters and enables the certificate for the IIS service.

Conclusion

Hopefully this article ties together the namespace and load balancing principles with respect to certificate planning. As you can see from the above examples, the choices you make with respect to your load balancing, namespace model, and DAG architecture greatly affect the number of host names required on the certificate.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

14 Comments
Not applicable
@Exchange Queries - OA, EWS, OAB, etc, will be mapped to legacy.contoso.com on the E2007 servers. It's only the 2013 virtual directories that will have the specific namespaces assigned.

This scenario is leveraging layer 4 load balancing, so there is no way to distinguish the URLs being accessed by the load balancer. This means that if we are checking the health of /rpc, then all protocols go down if that /rpc fails. By having specific namespaces for each of the relevant protocols that are used by Outlook (OA, EWS, OAB, Autodiscover) we can remove the specific failed protocol from the load balancing pool, as opposed to the whole server.

When the last internal facing Exchange 2007 server is removed, you can then remove the Exchange 2007 servers from the Internet facing site and retire the legacy.contoso.com namespace.

Ross
Not applicable
Fantastic article, as always. A couple of things that just don't seem necessary in an environment that already has an exchange infrastructure (which is more common). Setting the EXPR and EXCH value for the Outlook providers doesn't seem to have any drawbacks and is required if a client is Windows XP. A company is more likely to upgrade if we don't require them to upgrade all of their workstations for something that really doesn't seem that big of a deal.

Also, having separate namespaces for every service wouldn't be the default for most environments that already are using only two namespaces anyway. It would require the company to reconfigure their environment and educate their users.

The point I am making is that even though there is an ideal situation, the benefits likely wouldn't outweigh the cost to a company to fit this. The benefits would actually have to add certain value such as added reliability, performance, or stability for a company that already has an existing Exchange infrastructure to consider them.
Not applicable
@DavidR1 - the examples that add additional namespaces per protocol do not require user education as they are protocols that are handled by Autodiscover (OA, EWS, OAB, etc.). The only protocols that users have to know directly are IMAP/POP and OWA. Also, those namespaces would be added only to E2013, not E2010 servers (E2007 would have to be reconfigured to use the legacy namespace).

Ross
Not applicable
Hi Ross,

On Scenario 3, is there any specific reason or need to have EWS, OA, OAB to have them separate for each service why don't we have them mapped to legacy for 2007 and mail for 2013...And weather shall we remove them when we decommissioned 2007 box from both site
Not applicable
Thank you Mr. Ross Smith
Not applicable
Perfect and Clear Explanation ..Thanks Ross ...
Not applicable
Certificate Planning in Exchange 2013
Thanks
Not applicable
Wildcard certificates
hi lots of advice suggests not to use Wildcard certificates, for Exchange.
also lync 2013 i seem to remember advice was not to use a Wildcard certificate there.

can you confirm what the official guidance is now ?
are Wildcard certificates fully supported
Not applicable
Hi
and thanks for an informative post
from this and others I understand the best practice is not to use hardware load balancing(so you can use ex2013 new features, basically (no glue between sessions) is that correct?
Thanks
Not applicable
Question regarding the CAS server names on the certificate. Although several sources state that the server names do not need to be included on the certificate, this does not seem to be correct. I just had an embarrasing experience at the customer site. Exchange 2013 SP1 deployed into an existing Exchange 2007 organisation. With the certificate that does not include CAS FQDNs, Outlook 2013 client connects via Windows Load Balancing towards the load balancing cluster name mail.company.com and pops up: "I can't connect to "CASnodename". On the CAS both internal and external URLs are set to mail.company.com as per Exchange Server Deployment Assistant. Including the CAS FQDNs on the certificate solved the issue. Or there might be something forgotten in the Deployment Assistant ? Or any special setting in Windows Load Balancing that needs to be set?
Not applicable
Great Article for Exchange On-Premises customers, Thanks.
Not applicable
eas in scenario 3?
Not applicable
On a plane heading back from MEC. Is there any reason for the splitting up of the roles? I felt like there was quite a push to inform us that multi role boxes might be the way to go.

Had a blast at MEC!!!
Not applicable
Attn:


Can MS Exchange or Outlook API open 500 or more simultanious

connections per second and can be installed & configured on a

Google App Engine server or a MS Azure server to send several

million newsletters daily ? We do not know how to use JavaMail.

Google has gave us permission to send 5 million messages daily.

Sincerely, JamesBarbone@mediablitzers.net + JamesBarbone@verizon.net


Quota Increase Request + Approved + Billing Enabled


App Engine's quota system allows for efficient applications with billing enabled to scale to around 500 queries per second (qps) or more than 40 million queries per day. This is a substantial amount of traffic and should easily suffice for even the heaviest

of Slashdottings. But if you expect your application will need to handle even higher qps, please complete this form so we can assist you.





First name * James


Last name * Barbone


Admin Email: * Jamesbarbone@mediablitzers.net


Your application ID (http://myapp.appspot.com:( *

https://sites.google.com/a/mediablitzers.net/mediablitzers/



Application description * Newsletter


Traffic estimate (qps) * 5 Million Daily


Cause of traffic spike (e.g. new launch, Dugg, etc.) * New Launch

Version history
Last update:
‎Jul 01 2019 04:18 PM
Updated by: