If you would like to read the other parts in this article series please go to:
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 1)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 2)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 3)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 4)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 5)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 6)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 7)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 9)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 10)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 11)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 12)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 13)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 14)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 15)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 16)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 18)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 19)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 20)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 21)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 22)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 23)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 24)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 25)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 26)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 27)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 28)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 29)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 30)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 31)
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.
Figure 1: Creating the DNS record for the federation service endpoint in internal DNS
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.
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.
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.
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.
Figure 6: Virtual Machine Instances
In the wizard, select “From Gallery”.
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.
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.
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.
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.
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.
Figure 12: Virtual Machine configuration
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:
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 1)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 2)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 3)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 4)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 5)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 6)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 7)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 9)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 10)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 11)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 12)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 13)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 14)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 15)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 16)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 18)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 19)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 20)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 21)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 22)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 23)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 24)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 25)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 26)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 27)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 28)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 29)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 30)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 31)