Exchange Server 2016 and Microsoft Cloud - Deployment Guide (Part 3)

by [Published on 26 May 2016 / Last Updated on 26 May 2016]

Configuring Public Certificates and exploring the high availability options in Exchange Server 2016.

If you would like to read the other parts in this article series please go to:

Introduction

So far in this series, we built the Active Directory on the main site and installed Exchange Server 2016 on both servers. The next logical step is to configure the Public Certificates on Exchange Server which is a key step before working on the load balancer for these new servers.

Exchange Certificates…

As part of any Exchange Server deployment, the administrator must spend some time on the certificates. By default, any new installation will come with a self-signed certificate, and it should be changed to a Public Certificate Authority (recommended) or a certificate from a Public PKI (it is okay if you don’t have mobile devices and most of your machines are domain joined). The preference is always to use a certificate from a Public Certificate Authority to avoid certificate pop-ups from non-domain joined machines, mobile devices and different platforms (Apple, Android, Linux and etc).

In this article series, we will be using a Public Certificate, and our second discussion point is around the names that we will be using on the Public Certificate. The minimum requirement for Exchange Server is to use two names: autodiscover and another one for Outlook Anywhere and webmail. In our article series we will use these following names:

  • autodiscover.infralab.org
  • webmail.infralab.org
  • adfs.infralab.org (to be used by ADFS later on this series)
  • smtp.infralab.org

Before creating the certificate request, we must have a folder where Exchange Server is able to create and read files. The folder must be shared (we can use Everyone Full Control at the Sharing level) and on the Security (NTFS) level we must add the group Exchange Trusted Subsystem with Full Control permissions, as shown in Figure 01.

Image
Figure 01

Now that we have a folder to store our certificate request, we can use these following steps to generate a certificate in Exchange Server 2016.

  1. Logged as administrator on Exchange Admin Center (https://TOREX01/ECP please replace torex01 for your server name)
  2. Click on Servers and then Certificates
  3. Click on +
  4. On the initial page, select Create a request for a certificate from a certification authority and click Next
  5. Define a name for the certificate, in our series we will label it as Infralab.org – Public Certificate and click Next
  6. In the following page (Request a wildcard certificate), just click Next
  7. Select which server will store the certificate request, we will select the first server. Click Next
  8. In the following page which has two columns: access and domain, just click Next
  9. This page of the wizard is the most important, it is on this page that we define the names that will be part of the certificate, based on our scenario we fill out the information accordingly (Figure 02), click Next.

Image
Figure 02

  1. Fill out all the organization information, and click Next
  2. In the following page, fill out the UNC path (\\servername\SharedFolder\request.req format) of the new request and click on Finish.

The next step is to go to the Public Certification Authority and create the certificate using the certificate request file generated in the previous step. The Public Certification Authority will perform some checks to make sure that your company is the real owner of the domain and after those tests a certificate will be available to install on the Exchange Server(s).

  1. Logged on EAC as administrator
  2. Click on Servers and click on Certificates
  3. Select the Public Certificate request created in the previous step, and click on Complete located on the right side (Figure 03)

Image
Figure 03

  1. Type in the location of the certificate that was download from the Public Certification Authority, and click OK, as shown in Figure 04.

Image
Figure 04

Now that the Public Certificate is installed, the administrator can assign it to the services. In order to do that double click on the new certificate, and click on services item on the left side. For now, we will select SMTP and IIS and then click on Save (Figure 05). A warning dialog box may show up about overwriting the default SMTP Certificate, just click on Yes.

Image
Figure 05

Public Certificates and additional servers…

That is the easy part, from a server that already has the certificate, click on the certificate and click on Export Exchange Certificate (Figure 06), a new page asking for the location of this export and a password. We will fill out using the same UNC path that we used to create the initial request (\\torex01\exutil\infralab.pfx).

Image
Figure 06

Time to import the certificate, click on and then Import Exchange Certificate… (Figure 07), fill out the UNC path including the filename and the password that we defined in the previous step.

Image
Figure 07

Add one or more servers that will receive the Public Certificate and click on Finish (Figure 08).

Image
Figure 08

The last step is to assign the certificates, the same way that we have done when created the Public Certificate.

Deploying High Availability for the Client Access Services...

Now that we have Exchange Server 2016 servers deployed and they are up and running, and all of them have the same certificate, we can configure the high availability of the client access services using two methods: DNS or Load Balancer appliances.

Fellow MVP Steve Goodman goes in detail of the configuration involved on each method in his series at MSExchange.org article.

If we want to keep simple, we just need to create two entries for webmail.infralab.org (Figure 09) pointing out to the Exchange Server(s), and by doing that we guarantee that our internal clients will be properly balanced between Exchange Servers, but it does prevent a single server outage to bring the entire service down.

The external clients (when OWA and other services are published) usually is to an IP address, so you may need to check with your Firewall device if there is the capability to balance the publishing of Exchange Server(s), or in a worst case scenario use two Public IPs and create a DNS load balancing on the external DNS zone. There is also an operational cost here, every time that one server will be patched or unavailable for a period of time the Operations Team have to remove the entries from DNS/Firewall to make sure that end-users are not impacted.

Image
Figure 09

When a more elegant and robust solution is required, then we need to start talking about Load Balancers. Using load balancer, we have a couple of methods to perform the balancing, but at the end of the day we need to decide between 2 key components: single or multiple namespaces.

The recommended deployment in most of the scenarios is to use Single Name Space and no session affinity (Layer 7), where we save operational cost with a single name (webmail.infralab.org for example) and each virtual directory (owa, ecp, ews and so forth) are checked individually. When one of those virtual directories go down, the load balancer redirects the traffic to the working virtual directory, however all others virtual directories on the same server can be used, if they are healthy of course.

A Load Balancer solution may require changes in your network, in some scenarios you want the Load Balancer being the default gateway for all servers that are using it, and it is also easier to publish a VIP (Virtual IP) hosted in a Load Balancer from the firewall perspective. All big players will support Exchange Server 2016 deployment, including: F5, NetScaler (Citrix) and Kemp, some of those have articles here at MSExchange.org with step by step guide to configure.

If the decision is towards the Load Balancer option, the recommendation then is to use 2 (two) to provide High Availability and the vendors provide HA on the application level to reduce downtime. Load Balancers may be physical or VMs, in case of a VM it is important to configure at virtualization level rules to avoid both load balancer sharing the same physical host.

Conclusion

In this article we went over the process to configure certificates which are key for DNS Load Balancing and Load Balancers in general where session affinity is not required, and we configure the DNS Load Balancing in our environment, but we could use any Load Balancer to balance the traffic as well.

If you would like to read the other parts in this article series please go to:

See Also


The Author — Anderson Patricio

Anderson Patricio avatar

Anderson Patricio is a Canadian MVP in Cloud and Datacenter Management, and Office Server and Services, besides of the Microsoft Award he also holds a Solutions Master (MCSM) in Exchange and several other certifications. Anderson contributes to the Microsoft Community with articles, tutorials, blog posts, twitter, forums and book reviews. He is a regular contributor here at ITPROCentral.com, MSExchange.org, Techgenix.com and Anderson Patricio.org (Portuguese).

Advertisement

Featured Links