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

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

Introduction

In part 15 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 established the federation service farm on the first AD FS server and then added the second federation server to this farm.

In this part 17, we will continue where we left off in part 16. More specifically, we will create the federation service name in internal Active Directory DNS. Then we will verify that the two AD FS servers in the established federation service farm have been configured properly and are accepting incoming connections. Finally we will create the two Web Application Proxy machines in Microsoft Azure.

Let’s get going…

Creating the Federation Service name in internal Active Directory DNS

So in the previous article, we provisioned the AD FS servers and established the federation service (fs.azurelab.dk). However, we did not create the federation service endpoint in the internal Active Directory DNS. So before we begin to verify the AD FS servers works as expected, we need to create the “fs.azurelab.dk” DNS record in our internal DNS. To do so log on to an AD DS server and launch the DNS Manager. Under the “azurelab.dk” zone, we will create two A records for “fs.azurelab.dk”. One pointing at the primary AD FS server and one that points to the secondary AD FS server as shown in Figure 1 and Figure 2.

Image
Figure 1:
Creating the DNS record for the federation service endpoint in internal DNS

Image
Figure 2: Both A records created in internal DNS

Verifying the Federation Service is working properly

With the federation service up and running and with the DNS records created in internal DNS, let’s check that the servers behaves as expected. First, let’s try to see if we can reach the login page on each AD FS server. To do so, open a browser and enter the following URL (replace server FQDN with your own):

https://fs.azurelab.dk/adfs/ls/IdpInitiatedSignon.aspx

If things work as expected, you should see the new AD FS 3.0 forms-based login page as shown in Figure 3.

Image
Figure 3:
AD FS 3.0 Sign-in page

Clicking the “Sign in” button should log you in without prompting you for credentials.

Note:
If a credential pop-up box appears, you should make sure the federation service endpoint has been added to the local intranet zone.

Image
Figure 4:
Signed in using the AD FS 3.0 sign-in page

Creating the two Virtual Web Application Proxy Machines in Windows Azure

Time has come to create the two virtual machines that are going to act as Web Application Proxy (WAP) servers in our federation service solution. More specifically, the purpose of these servers will be to listen for and proxy incoming federation requests from users that use a device not directly connected to the internal network, but to the Internet to our federation service on the internal network.

Image
Figure 5:
Deploying the Web Application Proxy (WAP) Servers

To create the first WAP server, open the Windows Azure Management portal, click “Virtual Machines” in the left pane. Under the “Virtual Machine Instances” tab, click “New” in the lower left corner.

Image
Figure 6:
Virtual Machine Instances

In the wizard, select “From Gallery”.

Image
Figure 7:
Creating Virtual Machine from Gallery

In the gallery, select the “Windows Server 2012 R2 Datacenter” image and click the arrow in the lower right corner.

Image
Figure 8: Choosing the proper image from the gallery

Now we need to provide a name (which will also become the NetBIOS name of the server) for the virtual machine and specify the building block we want to use. Since I want to keep compute power as low as possible, I will configure the virtual WAP servers with the “Extra Small (shared core, 768 MB memory)” building block.

Note:
You can switch between the building blocks at any time after the virtual machine has been provisioned, if you require more compute power for the respective virtual machines during specific periods.

Also, enter the admin account name and provide a complex password for it and then click the arrow in the lower right corner.

Image
Figure 9:
Specifying name, building block and admin credentials for the virtual machine

We are brought to the page where we can configure the cloud service, network, storage account and availability set.

In the “Cloud Service” drop-down menu, you will be able to see a list of the cloud services created so far. Since this is the first WAP server we are deploying and because we don’t want it  in an existing cloud service, select “Create a new cloud service”.

In the cloud service name, we should enter the DNS name through which the WAP virtual machine(s) should be accessible from the Internet. Unlike the internal AD FS servers, we want to make the WAP servers available directly from the Internet via HTTPS.

The two WAP servers should also be placed in the same Availability Set and in the same Cloud Service just like we did with the other server roles deployed so far. We will call the Cloud Service “AzureLabWAP”, so that it is not bound to a single AD FS server name-wise.

Note:
All servers placed in a cloud service will by default be available from the Internet via “<insert_name>.cloudapp.net”. However, we can use CNAME or A-records if we want to use custom domain names, which we will in this article series.

In the “Region/Affinity Group/Virtual Network” drop-down menu, we will select the virtual network we created earlier on in the article, which is “VirtualNetwork1”.

Under “Storage Account” we will use the one we previously created as shown in Figure 6.

Finally, under “Availability Set”, select “Create an availability set” and set a name for it. I will call it “AzureLabWAP” as I wish to use this for both WAP Servers that are being deployed in my lab environment.

On this page, we can also add, modify or delete endpoints for the respective virtual machine. Endpoints are the TCP or UDP protocol based ports through which it should be possible to access the virtual machine/cloud service from the Internet. Notice that the public port for remote desktop is set to “auto”, which means that a random port number will be configured during the provisioning of the virtual machine.

For the WAP role, we will leave the defaults as is and add the HTTPS protocol after both servers has been created.

Click the arrow in the lower right corner.

Image
Figure 10:
Virtual Machine configuration

On the “Virtual machine configuration” page, leave the defaults as is and click the check mark in the lower right corner to create and provision the virtual machine.

Image
Figure 11:
Virtual Machines Agent that will be installed

Now repeat the above steps in order to create the second WAP server. Only difference should be the name of the server as shown in Figure 12 and Figure 13.

Image
Figure 12:
Virtual Machine configuration

Image
Figure 13: Virtual Machine configuration – continued

We have now created and provisioned the WAP servers which will be used to proxy incoming HTTPS sessions to the AD FS servers on the internal network in our our “on-premises” Active Directory forest.

This concludes part 17 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