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

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

Introduction

In part 18 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 a load balanced set for the Web Application (WAP) virtual machines. I also talked about whether you should add the Web Application Proxy (WAP) servers to the internal Active Directory domain or not.

In this part 19, we will continue where we left off in part 18.

Let’s get going…

Installing the Web Application Proxy Feature on the Servers

With the Microsoft Azure IaaS specific configuration and settings in place for both virtual machines going to act as WAP (AD FS Proxy) servers, it’s time to install the Web Application Proxy feature on each virtual machine. To do so, let’s start by remoting the first virtual server.

Note:
Back in our previous article, I talked about whether the WAP servers should be added to our Active Directory forest domain and in this specific environment, I have chosen to leave the servers in a workgroup. The primary reason being I do not have any requirements for pre-authentication in the perimeter network for any services or applications.

In the “Server Manager”, click “Manage” and then select “Add Roles and Features” in the menu as shown in Figure 1.

Image
Figure 1:
Selecting Add Roles and Features in the Server Manager

On the “Before You Begin” page, click “Next”.

Image
Figure 2:
Before you begin page

On the “Installation Type” page, leave the defaults as is and click “Next”.

Image
Figure 3:
Installation Type page

On the “Server Selection” page, leave the defaults as is and click “Next”.

Image
Figure 4:
Server Selection page

We have now reached the “Server Roles” page and here you should tick the “Remote Access” role since the Web Application Proxy feature is a sub-component of this role.

Click “Next”.

Image
Figure 5:
Selecting the Remote Access role

On the “Features” page, all required features will have been pre-selected, so we can just click “Next”.

Image
Figure 6:
Features page

The “Remote Access” page provides a short description of the features held under the “Remote Access” page.

Click “Next”.

Image
Figure 7:
Remote Access page

Now we need to select the role services we wish to install on the server. Select “Web Application Proxy” and click “Next”.

Image
Figure 8:
Role Services page

On the “Confirmation” page, click “Install”.

Image
Figure 9:
Confirmation page

When the feature installation has completed, click “Close” to exit the “Add Roles and Features Wizard”.

Image
Figure 10:
Results page

Repeat the above steps on the second server.

Importing Trusted Third Party Certificate

One thing that is not possible when we are publishing the AD FS servers using the WAP Publishing wizard is to import the trusted third party certificate that is required. We can only select a certificate that has already been imported to the personal store of the computer account.

So now we are going to import the certificate using the good old certificates MMC snap-in. So let’s launch an empty MMC by selecting Run and typing “MMC”.

Image
Figure 11: Opening an empty MMC

In the MMC, click “File” and then select “Add/Remove Snap-in”.

Image
Figure 12: Selecting to add a new snap-in

In the “Add or Remove Snap-ins” windows, select “Certificates” and click “Add”.

Image
Figure 13: Selecting the Certificates snap-in

Make sure to select “Computer account” and then click “Next”.

Image
Figure 14: Selecting Computer account

Under “Select Computer”, leave the default as is and click “Finish”.

Image
Figure 15: Selecting Local Computer

Expand “Certificates” and then “Personal”. Right-click the Certificate store and select “All Tasks” and then “Import…” in the context menu.

Image
Figure 16: Selecting Import in the context menu

The “Certificate Import Wizard” launches. Click “Next”.

Image
Figure 17: Certificate Import Wizard

On the “File to Import” page, click “Browse” and select the certificate to be used. Then click “Next”.

Image
Figure 18: Specifying the certificate to import

Specify the password that protects the certificate and click “Next”.

Image
Figure 19: Specifying the password for the certificate

Make sure the Personal certificate store is selected and click “Next”.

Image
Figure 20: Personal Certificate Store selected

On the “Completing the Certificate Import Wizard” page, click “Finish”.

Image
Figure 21: Completing the Certificate Import Wizard page

Repeat the above steps on the second WAP server.

Configuring Internal and External DNS

Time has come to configuring the internal and external DNS. Well, when it comes to the internal DNS we have already created the AD FS federation service endpoint DNS record in the Active Directory DNS. What we need to do is to add the AD FS endpoint to the “hosts” file on the WAP servers. This is required in order to make sure incoming authentication requests are proxied properly on to the AD FS servers and do not end up in a loop.

So let’s open the “hosts” file on the first WAP server. To do so, open “Notepad” in administrator mode, and open the “hosts” file located under “C:\Windows\System32\drivers\etc” as shown in Figure 22.

Image
Figure 22: Opening the hosts file

In my specific environment, the federation service endpoint are named “fs.azurelab.dk”, so I’ll add this endpoint to the host file and make sure it resolves to the AD FS server IP addresses. Since I do not use any form of load balancing for the AD FS servers on the internal network, I need to add the IP address of both AD FS servers.

Note:
As there will not be any clients or devices directly connected to the internal network (Azure subnet) I use in my setup, a load balancer solution is not critical. The good old DNS round robin method is sufficient.

Image
Figure 23:
Adding federation endpoint to the hosts file

Repeat the above steps on the second WAP server.

Now we need to create the external DNS record (also “fs.azurelab.dk” as I use split-DNS) at the DNS provider I use. First, I need to take note of the public virtual IP (VIP) address that is associated with the load balancer set I have created for the WAP servers. This can be found by going to the Azure Dashboard for one of the WAP servers as shown in Figure 24”.

Image
Figure 24:
Public virtual IP (VIP) address

Now that we have the public virtual IP (VIP) address, we can log on to the web interface of our DNS provider and create an A-record which points to this address. Make sure to use a low TTL in case you need to change it some day.

Image
Figure 25:
Creating the external DNS record for our federation endpoint

This concludes part 19 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:

Leave a Comment

Your email address will not be published.

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

Scroll to Top