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

By /

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

Introduction

In part 5 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, I showed you how Office 365 services are enabled for a Windows Azure Active Directory created via a Windows Azure subscription.

In this part 6, I will provide you with an overview of the Windows Azure based virtual lab environment that will be used in this article series. In addition, we will begin the preparation of Windows Azure in order to get ready for deployment of the virtual machines.

Let’s get going…

Overview of the Lab Environment

The virtual lab environment we are going to deploy in Windows Azure will consist of the following servers:

  • 2 x AD DS Domain Controllers
  • 2 x Exchange 2013 Multi-role servers
  • 2 x AD FS Servers
  • 2 x WAP (AD FS Proxy) servers
  • 1 x Directory Synchronization server (DirSync)

The Active Directory forest will be named ”azurelab.dk” and split-brain DNS will be used, which means that the same namespace (azurelab.dk) will be used internally as well as for external publishing.

All servers will be deployed using the Windows Server 2012 R2 RTM image available in the Windows Azure image gallery. Because Windows Server 2012 R2 is used as the base OS, identity federation will be based on AD FS 3.0 and the new Web Application Proxy role in Windows Server 2012 R2 will be used to publish Exchange 2013 and act as proxy for our AD FS based federation.

Note:
As you can see from the above list, we will deploy 9 servers in total. Depending on your Windows Azure subscription and how many cores you have at your disposal, you may want to deploy one of each server role instead of two. However, if possible I recommend you go with two servers per role, except for the DirSync server, which cannot be made and is not required to be highly available.

The two Exchange 2013 multi-role servers (CAS & Mailbox) will be installed using Exchange 2013 Service Pack 1 (SP1) bits (CU2 or later is required in order to set up a hybrid configuration with Exchange Online in the new Office 365 service).

We will use a wildcard certificate (*.azurelab.dk) for Exchange 2013 as well as AD FS purposes.

Back in part 2 of this article series, I talked about the concept of cloud services in Windows Azure. I mentioned that with cloud services, Windows Azure would maintain the infrastructure by performing routine maintenance, patch the operating systems and attempt to recover from service as well as hardware failures. When we have two or more instances for a role in a cloud service, service upgrades can be performed without interrupting the respective service.

In our scenario, we will place the two WAP servers (AD FS Proxy servers) in a single cloud service and the AD FS servers together in another. We will also place the two Exchange 2013 hybrid servers in a single cloud service. However, the Domain Controllers will be placed in separate cloud services as we do not need these to be load balanced or be reached from the Internet.

Although in this article series we will use cloud services for load balancing, you do not necessarily need to take this approach. If you wish to simulate an on-premises environment more closely in respect to the load balancing piece, you could place each individual virtual machine in its own cloud service and instead load balance the servers using traditional means such as a virtual load balancing appliance. I have tested the one available from Kemp and it works quite well although you cannot deploy an HA pair as Windows Azure doesn’t allow us to use static IP addresses, which is required for a Kemp HA pair.

For this same reason, we cannot use Windows Network Load Balancing (WNLB) to load balance our WAP, AD FS and Exchange hybrid servers, as WNLB also requires you to configure a static virtual IP address (VIP).

All identical server roles will be placed in the same availability set in order to eliminate any failure domains. Said in another way, identical server roles in the respective availability set will be spread across multiple racks in the Windows Azure Datacenter(s).

Below is a conceptual diagram of the planned Windows Azure based lab environment.

Image
Figure 1: Conceptual overview of the lab environment

Registering a DNS Server

By default, Windows Azure provides a name resolution service, which can be used to resolve hostnames between role instances or virtual machines located in the same cloud service. Prior to deploying role instances or virtual machines on a virtual network, you should decide whether the default name resolution service provided by Windows Azure is sufficient or if you need to use an external DNS service that is not maintained by Windows Azure.

The name resolution service in Windows Azure is simple and efficient, however in most scenarios it’s a bit too limited. For instance, in our specific scenario, we will not deploy all virtual machines into the same cloud service and we will create an Active Directory forest that as you know usually uses its own AD DNS.

For this reason, we wish to register our own AD DNS server (domain controller) in the Windows Azure portal. Since this can be, and actually should be done prior to deploying the virtual domain controller, let us open the Windows Azure Management Portal and click “Networks” in the left pane. Under “Networks”, click on the “DNS Servers” tab as shown in Figure 3.

Image
Figure 2: Selecting the DNS Server tab in the Windows Azure Management portal

You will see that the list of DNS servers is blank. Click the “New” button in the lower left corner and then “Network Services” > “Virtual Network” > “Register DNS Server”.

Image
Figure 3: Clicking Register DNS Server

Now enter a name for the DNS server. The name is not critical in regards to the virtual AD DNS server (domain controller) we will create later on. In theory, you could call it whatever you want to. In my environment, I will call it “AzurelabDNS”. The important thing is the IP address you specify. Some of you might think how you should be able to know what IP address to use since virtual machines will get an IP address dynamically assigned. Well, in my case I will use the private network “10.0.0 /11” (you can choose what private network you wish to use when you create the virtual network).

Also, I know that the first three IP addresses in an assigned range will be used for internal Windows Azure purposes, so the first virtual machine we deploy will get the internal IP address “10.0.0.4”. Since the first virtual machine we deploy will be a virtual domain controller with AD DNS installed, I can specify “10.0.0.4” as the DNS server that should be used for name resolution between the machines.

Image
Figure 4: Entering the friendly name and IP address of the AD DNS server

When you have entered the friendly name and IP address of the DNS server, click “Register DNS Server”.

Image
Figure 5: DNS Server registered successfully

Since this is a lab environment, it is not critical to have multiple DNS servers registered. However, since we will deploy two domain controllers, we could also register the second DNS server if we wanted to.

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

Read Next

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