Exchange Virtual Directory HTML Report

Update 12/09/2016: script updated to version 1.8:

  • Included support for Exchange 2016 CU2+
  • Made some minor changes to the code + output now shows a message if successful/unable to write the html file.

Previous updates in version 1.7:

  • Added more recent Exchange build numbers
  • Updated download location to TechNet Script Gallery

You can download v1.8 here


as a consultant, I regularly come across situations in which I have to troubleshoot an existing Exchange server environment or perhaps have to make an assessment, health report, etc.

Almost every time, I found myself looking up the information from the different (commonly used) virtual directories like: Autodiscover, ActiveSync, OWA, ECP, Web Services, OAB… That’s why I thought it became about time I automated this process so that I didn’t have to type the commands in manually anymore.

The result is a simple script which will query the Exchange Client Access Servers in your environment and will query them for their virtual directory information. Depending on the use of the virtual directory, different object are shown:


Blog Exchange PowerShell

Load Balancing Exchange 2013 – part 1


In one of my earlier posts, I already briefly explained what load balancing in Exchange 2013 looked like and how you could setup basic load balancing using a KEMP LoadMaster based on a blog post that Jaap Wesselius wrote. Today I will elaborate a bit more on the different load balancing options you have, along with how to configure a KEMP LoadMaster accordingly. In a future blog post (which I’m working on right now), I will be explaining how you can configure an F5 BIG-IP LTM to achieve the same results.

Load Balancing Primer

One of the ‘biggest’ changes towards load balancing in Exchange 2013 is that you can now use simple, plain Layer 4 load balancing. More ‘complex’ and more expensive layer 7 load balancing that you had to use in Exchange 2010 is no longer a hard requirement. However, this doesn’t mean that you cannot use Layer 7 load balancing. But more about that later (part 2).

In a nutshell, Layer 7 load balancing means that you can do application-aware load balancing. You achieve this by decrypting SSL traffic, which allows the load balancing device to ‘read’ the traffic that’s passing though. The Load Balancer will analyze the headers and based on the what it ‘finds’ (and how it’s configured), it will take an appropriate action (e.g. use another virtual service or use another load balancing option).

Traffic decryption uses additional resources from your load balancer. The impact of the amount of users connecting through your load balancing device usually is (much) higher in such case. Also, not all load balancers offer this functionality by default. Some require you to purchase additional license (or hardware) before being able to decrypt SSL traffic. Companies might choose to re-encrypt traffic that is sent to Exchange (SSL Bridging) because of security reasons (e.g. avoid sniffing). In Exchange 2010 you could also choose not to re-encrypt traffic when sending it to Exchange. This latter process is called SSL Offloading and required some additional configuration in Exchange. Not re-encrypting traffic (SSL Offloading) saves some resources on your load balancing device, but know that – for now – it is not supported for Exchange 2013; you are required to re-encrypt traffic when using Layer 7 load balancing! So make sure that you size your hardware load balancers accordingly. How to size your load balancer depends of the model and make. Contact the manufacturer for more information and guidance.

Load Balancing Options in Exchange 2013

When looking purely at Exchange 2013, you have different options with regards to load balancing. Each of the following options has its advantages and disadvantages. Let’s take a closer look at each of them and explain why:

  • Layer 4 (single namespace)
  • Layer 7
  • Layer 4 (separate namespaces)

Layer 4 (single namespace)

This is the most basic (and restricted) but also the easiest way of setting up load balancing for Exchange 2013. A single namespace will be used to load balance all traffic for the different Exchange workloads (OWA, EAC, ActiveSync, EWS, …).


Because you are using a single namespace with Layer 4, you cannot do workload-specific load balancing and/or health checking. As a result, a failure of a single workload can possibly impact the end user experience. To illustrate, let’s take the following example:

User A connects to and opens up OWA. At the same time, his mobile device syncs (using ActiveSync) over the same URL while his Outlook is connected (Outlook Anywhere), you’ve guessed it right, over the same external URL. In this example, the virtual service is configured to check the OWA Virtual Directory (HTTP 200 OK) to determine whether a server is available or not.

Let’s see what happens if OWA fails on a server. The health check that the load balancer executes will fail, therefore it will assume that the server isn’t functioning properly anymore and take that entire server out of service. It does this by preventing traffic from being forwarded to that server. Even though other workloads like Outlook Anywhere and ActiveSync, … might still work perfectly, the server will still considered ‘down’. From an efficiency point-of-view that is not the best thing that could happen:


Now, imagine that OWA works fine, but the RPC/HTTP components is experiencing some difficulties…At this point, OWA would still return a positive health check status and the load balancer would assume the server is still healthy. As a result traffic is still being sent to the server, including traffic for the failed RPC/HTTP components.  This will definitely impact a user’s experience.


As you can see, it’s perhaps not the best possible experience for the end user (in all cases), but it definitely is the easiest and most cost-effective way to setup load balancing for Exchange 2013. Because you don’t need advanced functionality from the load balancer, you will probably be able to fit more traffic through the load balancer before hitting it’s limits. Alternatively, if you don’t have a load balancer yet, it could allow you to buy a smaller scaled model to achieve the “same” results as with L7 load balancing.

Let’s take a look at how to setup a KEMP LoadMaster for this scenario:

Note   to keep things brief and to the point, I’m not going to discuss how to setup a KEMP LoadMaster in your environment and what options you have there (e.g. single-arm setup, …). We’ll only discuss how to setup the virtual services and other related configuration settings.

First, navigate to Virtual Services and click Add New:


Enter the Virtual IP Address (VIP), port, and optionally a descriptive name for the service. Then click Add this Virtual Service to create it:


Configure the Basic Properties as follows:


Because we’re not going to use Layer 7, make sure to disable Force L7 in the Standard Options. Because Exchange doesn’t need affinity (persistence), you do not have to configure anything specific for that either. You’re free to choose the load balancing mechanism (a.k.a. scheduling), but Round Robin should be OK:


I can imagine that you’re now like “Wait a minute, does that mean that every new connection possibly end up with another server in the array?” The answer is: yes. But that actually doesn’t matter. Every connection that is made is automatically re-authenticated. As a result, the fact that every new connection is forwarded to another server (even mid-session) doesn’t impact the end user’s experience. If you’d like to know a bit more about this, I suggest you listen to episode 12 of “The UC Architects”. In this episode, Greg Taylor (Microsoft) explains how that actually works.

Anyway, we got sidetracked. Back to the Load Master! Again, because we’re doing the simplest of the simplest (L4) here, we also don’t need to do any form of SSL decrypting, meaning that you can leave these options at their default:


If you will, you can specify a “Sorry Server” in the advanced properties. This is a server where traffic is redirected to if all servers within the array become unavailable:


Note   if you click Add HTTP Redirector the KEMP LoadMaster will automatically create a Virtual Service for the same VIP on TCP port 80 that will redirect traffic to the Virtual Service on TCP port 443. This way you can enforce SSL and you don’t necessarily have to do that elsewhere.

All that’s left now is to configure the servers to direct traffic to. Click Add New under Real Servers to add an Exchange 2013 server. Once you’ve filled in the details, click Add this Real Server. Repeat this step for all Exchange 2013 Client Access Servers you want to add.


We still have to configure how the LoadMaster will check the health of the servers in the array. There are different ways to do this. In the example below, the LoadMaster will query the OWA Virtual Directory and if it gets a response, the server will be deemed healthy. Alternatively, you could also opt not to specify an URL. Do not forget to click Set Check Port after entering the port number.


Believe it or not, but that’s it. Your LoadMaster is now setup to handle incoming traffic and distribute the load evenly over the configured servers.



Simple Layer 4 load balancing clearly has its benefits towards simplicity and cost (you usually need less performing hardware load balancers to achieve the same result as with L7). On the other hand, the limited options towards health checking could potentially take offline a server based on problems with a single workload while other workloads might still work fine on that server.

In the second part of this article, we’ll dive deeper into the option of using Layer 4 load balancing with multiple namespaces and how that compares to using Layer 7 load balancing, so stay tuned!



Blog Exchange 2013

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