Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 18)

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


In part 17 of this article series revolving around what the Windows Azure service is all about as well as how you deploy an Exchange hybrid deployment in Windows Azure, we created the federation service name in internal Active Directory DNS. Then we verified the two AD FS servers in the established federation service farm had been configured properly and are accepting incoming connections. Finally we provisioned the two Web Application Proxy (WAP) servers in Microsoft Azure.

With that said, let’s get going…

Creating a Load Balanced Set for the WAP Servers

Since the job for the two Web Application Proxy (WAP) servers is to accept authentication requests from external clients and devices and then proxy them on to the AD FS servers on the internal network, it is important these servers are published to the Internet on port 443/TCP. In order to do that in a highly available fashion, we add the servers to a load balanced set.

In order to create a load balanced set and have this load balanced set listen on port 443/TCP, let’s first open the property page for the first WAP server in the Azure Management Portal and then click the “ENDPOINTS” tab. Under this tab. Click “Add” in the bottom of the page as shown in Figure 1.

Figure 1:
Endpoints tab on the property page of the first WAP server

Since we do not have a load balanced set to add this server to yet, select “ADD A STAND-ALONE ENDPOINT” and click the arrow in the lower right corner.

Figure 2:
Selecting a stand-alone endpoint

On the “Specify the details of the endpoint” page, select “HTTPS” in the “NAME” and “TCP” in the “PROTOCOL” drop-down box. Then of course also make sure port 443 is specified in both the private and public port text box. Finally, tick the “CREATE A LOAD-BALANCED SET” checkbox and click the arrow in the lower right corner.

Figure 3:
Specifying the details for the endpoint

On the “Configure the load-balanced set” page, enter a meaningful name for the load balanced set and unless you feel a need to change the default probing settings, leave the remaining options at their defaults.

If the “CREATE A LOAD-BALANCED SET” is greyed out, make sure the “Virtual machine tier” for the two servers are set to “Standard” and not “Basic” as the latter does not allow you to create load balanced sets.

Click the checkmark in the lower right corner.

Figure 4:
Configuring the load-balanced set

We have now created the load balanced set and associated it with the first WAP server.

Figure 5:
New load-balanced set created and configuration settings are updated as needed

Let’s switch to the property page of the second WAP server and select the “ENDPOINTS” tab. Click “Add” in the bottom of the page.

Figure 6:
Current endpoints for the second WAP server

On the “Add an endpoint to a virtual machine” page, select “ADD AN ENDPOINT TO AN EXISTING LOAD-BALANCED SET” and then make sure the load balanced set you just created is selected.

If you cannot select the new load balanced set, make sure the WAP servers are part of the same availability set. You can verify this under the “Configure” tab of each server.

Click the arrow in the lower right corner.

Figure 7:
Specifying the load balanced set to which the server should be added

We have now configured the load balanced set for the two WAP servers and the second server is updated as needed.

Figure 8:
Configuration settings for the second WAP server in order to have it added to the load balanced set

The two WAP servers now accept incoming sessions on port 443/TCP in a highly available fashion. Well, at least on the virtual machine layer. We still need to add the Web Application Proxy role to each server on the Windows Server layer.

Should the Web Application Proxy Servers be Domain Joined or Not?

So Web Application Proxy (WAP) server can either be added to the internal Active Directory domain or an Active Directory domain dedicated to a perimeter network. They can also be left in workgroup mode. All three options are fully supported. So for the purpose of the lab environment you’re building, what method should you choose? Well, it depends really. We can leave the “add the servers to a dedicated Active Directory domain in the perimeter network” out of the picture as this is usually only done in relative large infrastructures and is outside the scope of this specific lab environment we are building here. The benefit of this option is more optimal management of servers located in the perimeter network.

Then we have the “add the servers to the internal Active Directory domain” option. The primary reason for adding the WAP servers to the internal Active Directory domain is to be able to pre-authenticate end users at the WAP server level prior to allowing access to the internal service or applications that are being accessed. In my world pre-authentication in the perimeter network is a thing of the past. I don’t want to go into a detailed explanation here, but instead I can recommend you read this blog post by my good buddy Greg Taylor from the Exchange Customer Experience team, that sums it up quite well.

Although the WAP servers can do pre-authentication for applications such as Exchange and SharePoint, pre-authentication cannot be used for AD FS. More specifically, AD FS based authentication will always be proxied to the internal AD FS servers for authentication. Okay I’m starting to understand where you’re going here. But what if I want to publish Exchange 2013 and by that also Exchange hybrid through the WAP servers? Well, adding the WAP servers to the internal Active Directory domain won’t really gain you anything in this scenario either as Exchange hybrid requires you to not use pre-authentication but pass-thru authentication for the Autodiscover and Exchange Web Services protocols. Sure, you could still configure pre-authentication for the Exchange clients, but is it really needed? If you say yes go back and read that blog post I linked to earlier.

Okay, so obviously I will not add the WAP servers to the internal Active Directory domain, but leave them in workgroup mode.

There are other scenarios than what I talk about here where pre-authentication may make sense or even is required by the technology, but needless to say this is way outside scope of this article series.

This concludes part 18 of this multi-part article in which I provide you with an explanation of what Windows Azure is and how you configure an Exchange 2013 hybrid lab environment in Windows Azure.

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

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top