Body:

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 offload 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 offloading 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 offloading 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.

Source: http://blogs.technet.com/b/exchange/archive/2014/03/19/certificate-planning-in-exchange-2013.aspx

Category: How to do; Servers
Published: 3/21/2014 3:20
]]>