Configuring High Availability for the Client Access Server role in Exchange Server 2013 Preview


All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

Following one of my previous articles in which I described how you could configure a Database Availability Group to achieve high availability for the Mailbox Server Role, we will now take a look at the process of how to configure high availability for the Client Access Server.

CAS Array

To achieve high availability, you create a load-balanced array of Client Access Servers just like in Exchange Server 2010. Other than before, layer-4 load balancing now becomes a viable options, though that would only be in the smallest deployments where there’s no budget for load balancers.

Layer-4 load balancing only takes into account the IP (and TCP port). Yes, you are no longer required to configure “affinity”. The latter is the process where a connection – once it was built – had to be persisted through the same Client Access Servers. This is because CAS in Exchange Server 2013 doesn’t do any data-rendering anymore: everything happens on the backend (Mailbox servers).

I hear you thinking: does this mean we could use DNS load balancing (a.k.a. round-robin). The answer is yes and no. Yes, because it will load-balance between multiple Client Access Servers; no because if a server would fail, you’d have to remove the server (manually) from DNS and wait for the record to time-out on all the clients. While this might be a cost-effective way to have load-balancing and a very, very basic form of high availability, it is not a real viable solution for most deployments…

Ever since the CAS Array was first introduced, it was subject to quite some misconceptions. A lot of them were addressed by Brian Day in a very interesting article he wrote.  What I find is that people tend to mix up the RPC Client Access Array and the load-balanced array used for http-based traffic. Yes, the use of the term CAS Array can be a little confusing. No, they’re not the same! Winking smile

Now, since Exchange Server 2013 dumped using RPC-over-TCP, I no longer see the purpose in creating the RPC Client Access Array object (New-ClientAccessArray). Instead, it suffices to configure multiple Client Access Servers with the same internal hostname for Outlook Anywhere.

To understand what happens, let’s take a look at the following examples:

In the case where you’re using two Client Access Servers in the same AD site, by default Exchange will “load balance” traffic between the two end points. This means that the 1st request will go to CAS1, the second to CAS2, the third to CAS1 etc… While this does provide some sort of load-balancing, it doesn’t really provide high-availability. Once Outlook is connected to a CAS, it will keep trying to connect to that same server, even after the server is down. Eventually, it will try connecting to the other CAS, but in the meantime your Outlook client will be disconnected.


If we add a load balancer, we need to configure the Internal Hostname for OA to a shared value between the Client Access Servers. For example: This fqdn would then point to the VIP of the load balancer which, in turn, would take care of the rest. Because we’re using a load balancer, it will automatically detect a server failure and redirect the incoming connection to the surviving node. Since there is no affinity required, this “fail over” happens transparently to the end user:


As explained before, this load balancer could be anything from simple DNS load balancing, to WNLB or a full-blown hardware load balancer that’s got all the kinky stuff! However, in contrast to before (Exchange 2010), most of the advanced options are not necessary anymore…

Configuring Outlook Anywhere

To configure the internal hostname for Outlook Anywhere, run the following command for each Client Access Server involved:

[sourcecode language=”powershell”]Get-OutlookAnywhere – Server <server> | Set-OutlookAnywhere –InternalHostname <fqdn>[/sourcecode]

Configuring the Load Balancer

As I explained earlier, Layer-4 is now a viable option. Although this could mean that you’d just be using DNS load balancing, you would want to use some load balancing device (physical or virtual).

The benefit of using a load balancer over e.g. WNLB is that these devices usually give you more options towards health-checking of the servers/service that you’re load balancing. This will allow you to better control over the load balancing process. For example: you could check for a particular HTTP-response code to determine whether a server is running or not. It definitely beats using simple ICMP Pings…!

The example below is based on the load balancer in my lab: a KEMP Virtual Load Master 1000. As you will see, it’s setup in the most basic way:

I’ve configured no persistency and – because it’s a lab – I’m only checking the availability of the OWA virtual directory on the Exchange servers. Alternatively, you could do more complex health checks. If you’re looking for more information on how to configure a KEMP load balancer, I’d suggest you take a look at Jaap Wesselius’ blogs here and here. Although these articles describe the configuration of a Load Master in combination with Exchange 2010, the process itself (except for the persistency-stuff etc) is largely the same for Exchange Server 2013. Definitely worth the read!




Exchange 2013 How-To's

Configuring Certificates in Exchange Server 2013 Preview


All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

One of the tasks you will have to complete after installing Exchange Server 2013 is configuring certificates. Most Exchange-related traffic (including client traffic) is handled via HTTPS and thus they require some additional configuration to work properly.

Out of the box, Exchange Server 2013 will be using self-signed certificates. While these certificates (and the associated error messages) might be acceptable in a test-lab, they won’t be in production.

Although there is already a lot of guidance on this topic for Exchange Server 2010, I still regularly come across issues because of wrongly configured certificates. Hence, I decided to create this article to somewhat clarify the subject.

What certificates can I use?

As in Exchange Server 2010, Exchange Server 2013 can use both SAN certificates (recommended) or wildcard certificates.

What namespaces should I use?

The change in the client access model in Exchange 2013 (RPC over TCP to RPC over HTTP) has a positive impact on the design of your namespaces: ultimately, you need less namespaces then before.

Amongst the namespaces that you (potentially) need are:

  • Client Access Array (Array of Load Balanced CAS servers)
  • Autodiscover
  • OWA Failback URL*
    * Whether or not you need the Failback URL, depends entirely on the setup of your environment. I will discuss the design and setup of an highly available Exchange Server 2013 environment in another article soon.

Configuring Certificates using EAC

If you aren’t re-using a certificate that you exported from another server earlier, you will have to create a new certificate request first. This request will provide you a DSR which you can use to generate the actual certificate.

  1. Open the EAC and navigate to Servers > Certificatesand click the “+”-sign (New Certificate Wizard):image
  2. Click create a request for a certificate from a certification authority and click Next:

  3. Type in a name for the certificate and click Next. Although you could enter just anything, it’s always interesting to make this name as descriptive as possible:image
  4. If you want to use a wildcard certificate, click the checkbox and enter your root domain. Then click Next.
    imageIf you are notusing a wildcard certificate, you will be presented with the following screens first. On the first page, you can define what namespaces you are going to use for the different Exchange-services:image

    After having clicked Next, you can manually add or remove namespaces to be included on the certificate. Once ready, click Next.

  5. Select on which server to store the certificate and click Next:image
  6. Enter your organization details and click Next.image
  7. Enter the location where you want to save the certificate. The location should be entered as a UNC path. Then click Finish:SNAGHTML283ffc

Before continuing, verify that the certificate request file has correctly been created. The file will contains a DSR which you can use to request your certificate from your CA. This CA can be a private of public one.

Your DSR will look something like this:



Once you have received the certificate from your CA, we can now continue to configure the certificate.

  1. From the certificate overview window, click Completein the actions-pane:image
  2. Enter the location where you stored the certificate. The location should be entered in UNC format. Then, click OK:image
  3. The certificate request should now be completed successfully. Verify that the certificate shows up in the certificate list and that it’s status is valid:image

Although the certificate has been installed on the server, it has not been activated yet. Before a certificate is used, you need to assign services to it.

  1. From the certificate overview, select the newly added certificate and click Edit:image
  2. On the properties page, select Services and select the appropriate service (e.g. IIS). Afterwards click Save:SNAGHTML34c265
  3. Verify that the certificate is installed and configured correctly by browsing to Outlook Web App. This should not throw a certificate warning. If there is a certificate warning, either something went wrong or your certificate does not contain all the namespaces you’re using.

If you have multiple servers, you can either repeat the process above for each server or if you will be using a single certificate for all servers (e.g. when using a wildcard certificate), you should import this newly added certificate on other servers.

  1. From the certificate overview, select the certificate and click the three dots (…). From there, select Export Exchange Certificate:image
  2. Enter a path where the certificate should be saved and type in a password to protect the certificate. The path should be entered in UNC format. Afterwards click OK:image
  3. Verify that the certificate was exported successfully:image

Next, you will have to import the certificate on each server that will be using the certificate.

  1. From the certificate overview, select the certificate and click the three dots (…). From there, select Import Exchange Certificate:image
  2. Enter the UNC where you previously exported the certificate to and provide the password you chose earlier. Click Next:

  3. Select the server(s) to which you want to import the certificate to. Then click Finish:imageimage


  4. Verify that the certificate has successfully been imported to the different servers by selecting the server from the drop-down list on the certificate overview page. The imported certificate should be in the list and it’s status should be valid:image

All that’s left to do now, is to assign services to these certificate on each server. The process is identical as described before.

Configuring certificates using PowerShell

The more servers you have, the longer it might take to perform the actions using EAC. Alternatively, you can also use PowerShell to request, import and export exchange certificates:

  1. Open the Exchange Management Shell and type in the following command. This will create the certificate request “DSR” which you can use to request a certificate from your CA:[sourcecode language=”powershell”]$newcert = New-ExchangeCertificate –GenerateRequest –SubjectName “c=BE,o=EXBLOG,” –DomainName “” –PrivateKeyExportable $true
    $newcert | out-file c:\certreq.txt[/sourcecode]


    c= is used to denote the country by it’s international code. e.g. “BE = Belgium”
    o= is used to denote the organization e.g. “Exblog”
    cn= represents the common name of the certificate.
    DomainName represents the (Subject Alternative) Names
    to be included on the certificate.

  2. Once you’ve received the certificate from your CA, it’s time to import/install it onto the server (= completing the request):[sourcecode language=”powershell”]Import-ExchangeCertificate –FileData ([byte []]$(Get-Content –Path “c:\CertificateFromCA.cer” –Encoding Byte –ReadCount 0))[/sourcecode]


  3. Next, we need to assign services to this certificate:[sourcecode language=”powershell”]Get-ExchangeCertificate –ThumbPrint <thumbprint> | Enable-ExchangeCertificate –Services IIS,SMTP[/sourcecode]


    Note   While enabling the certificate you will get a warning that this will actually overwrite the existing certificate. You can safely overwrite the default self-signed certificate.

  4. Now that the certificate has been installed on the first server, we need to export it and import it on our other servers:[sourcecode language=”powershell”]$certexport = Get-ExchangeCertificate –DomainName “” | Export-ExchangeCertificate –BinaryEncoded:$true –Password (Get-Credential).password
    Set-Content –Path c:\cert_export.pfx –Value $certexport.FileDate –Encoding Byte[/sourcecode]


    Note   when running the first command, you will be prompted for a username and password. You can type whatever you want for the username, as this value will be ignored. However, remember the password as you will be using it later to import the certificate into another server.

    To import the certificate into another server, use the following command:

    [sourcecode language=”powershell”]Import-ExchangeCertificate –FileData ([byte[]](Get-Content –Path <path_to_exported_certificate> –Encoding Byte –ReadCount 0)) –Password (Get-Credential).password –Server <servername>[/sourcecode]


    Note   you will be prompted for a username and password. You can type any value for the username, but the password should match the one you selected earlier while exporting the certificate.

    If you have multiple servers to which you want to import the certificate to, you could script the execution of the command above like this:

    [sourcecode language=”powershell”]$servers = Get-ClientAccessServer | Select Name
    foreach($server in $servers){
    Import-ExchangeCertificate –FileData ([byte[]](Get-Content –Path <path_to_exported_certificate> –Encoding Byte –ReadCount 0)) –Password (Get-Credential).password –Server $

  5. Enable the newly imported certificates by assigning services to it. Do this for each server to which you imported the certificate:[sourcecode language=”powershell”]Get-ExchangeCertificate –DomainName “” | Enable-ExchangeCertificate –Services IIS,SMTP[/sourcecode]

Clearly, PowerShell is thé choice once you have multiple servers in your organization: in just a few steps you created, exported and imported a certificate on multiple servers

Exchange 2013 How-To's