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

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

Introduction

In part 6 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 began the preparation of Windows Azure in order to get ready for deployment of the virtual machines.

In this part 7, we will continue right where we left off in part 6. That is, we will create the required virtual network and then begin deploying the virtual machines.

Let’s get going…

Creating a Virtual Network

Back in part 6, we registered our DNS server. Now it is time to create the virtual network (vNet) to which our virtual machines and cloud services should be connected.

To create the virtual network, open the Windows Azure Management portal and click “Networks” in the left pane. As expected no virtual networks exists.

Under the “Virtual Networks” tab, click “Create a Virtual Network”.

Figure 1: Networks section in the Windows Azure Management portal

Enter a name for the virtual network. This is just a friendly name for you to identity the network. I simply use the name “VirtualNetwork1” simply because I am an ace at being creative with names.

The “Region” drop-down menu is a bit more important to pay attention to, as this is where you select which region (datacenter), your virtual network should be created. Here you usually should select the region closest to your physical location.

After having selected the region, an additional drop-down menu pops up called “Affinity Group”. Affinity groups are used to physically group Windows Azure services together in the same datacenter in order to increase overall performance. You can only assign one virtual network to a given affinity group.

Since no affinity groups exists yet, you can only select to create a new one. Do so and give it a name such as “AffinityGroup1”.

Click the arrow in the lower right corner.

Figure 2: Virtual Network Details page

We are now taken to the “DNS Servers and VPN Connectivity” page. Under DNS Servers, select the DNS server we registered previously and click on the arrow in the lower right corner.

Note:
The “Point-to-Site connectivity VPN” and “Configure Site-to-Site VPN” options are not relevant in our scenario as we do not wish to connect our Windows Azure hybrid lab environment to an on-premises infrastructure.

Figure 3: DNS Servers and VPN Connectivity page

This brings us to the “Virtual Network Address Spaces” page where we define the address space we wish to use. I typically go with the defaults of 10.0.0.0/8, but if you rather wish to use a 192.168.x.x or 172.16.x.x address space, you can do so (Figure 5).

As shown in Figure 6, you can also specify the CIDR (address count) if required.

When done, click the checkmark in the lower right corner.

Figure 4: Virtual Network Address Spaces page

Figure 5: Defining the address space to be used

Figure 6: Defining the CIDR (address count)

The virtual network is now being created as shown in Figure 7. This should not take more than a few seconds.

Figure 7: Virtual network is being created

That is it. Our Virtual Network has now been configured successfully.

Creating the Virtual Machines

We have reached the exciting moment where we will begin the actual deployment of the virtual machines. Naturally, we will begin with the two Domain Controllers.

In the Windows Azure Management portal, click “Virtual Machines” in the left pane. Under the “Virtual Machine Instances” tab, click “Create a Virtual Machine”.

Figure 8: Virtual Machine Instances

In the wizard, select “From Gallery”.

Figure 9: 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 10: Choosing the proper image from the gallery

Now we need to provide a name (also the NetBIOS) for the virtual machine and specify the building block to use. Since I want to keep compute power as low as possible, I configure all my virtual Domain Controllers with the “Extra Small (shared core, 768 MB memory)” building block except for the memory hungry Exchange 2013 servers.

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. Yes, we can block RDP access to the Domain Controllers, but this does not hinder hackers and the like to access your Active Directory using this admin account from one of your Internet-accessible virtual machines.

Click the arrow in the lower right corner.

Figure 11: 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 only be able to select “Create a new cloud service” as we have not created any yet. In the cloud service name, we should enter the DNS name through which the virtual machine(s) should be accessible from the Internet. We do not plan to have the AD DS Domain Controllers accessible from the Internet (other than through remote desktop and PowerShell), but in order to place the servers in the same Availability Set, we also need to place them in the same Cloud Service. We will call the Cloud Service “AzureLabADDS”, so that it is not bound to a single AD DS 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.

Under “Storage Account” we will select “Use an automatically generated storage account” since we do not have one yet.

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

Click the arrow in the lower right corner.

Figure 12: Virtual Machine configuration continued

On the last page (4), we 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 Domain Controller role, we will leave the defaults as is and click the checkmark.

Figure 13: Virtual Machine Endpoints

The virtual machine is now being created.

Figure 14: Virtual Machine being created

After a few seconds, we will see a status of “Starting (Provisioning)”. Then it will change to a status of “Starting” followed by a status of “Running (Provisioning)”.

Figure 15: New Virtual Machines Running (Provisioning)

And finally, it will change to “Running”, which means it now can be accessed via remote desktop and or Windows PowerShell (Figure 16).

Figure 16: New Virtual Machines Running

With the virtual machine running, let us open the property page for it. We can do so by clicking on the name.

Figure 17: Clicking on the name of the virtual machine

Click on the “Dashboard” tab.

On the “Dashboard” page, we can see current performance stats and other details. Also, note that in the lower right corner we can see the private IP and VIP address that has been assigned to the machine.

Figure 18: Virtual Machine Dashboard

In addition to the “Dashboard” tab, we also have the following tabs:

Monitor Here we can see additional performance related statistics
Endpoint This is where we add, modify or delete endpoints (basically published ports)
Configure The place where we can change the building block and/or availability set

Let us switch over to the “Cloud Services” section in the Windows Azure Management Portal. Here you can see that the cloud services we specified during the creating is listed (Figure 19).

Figure 19: New virtual machine cloud service listed under cloud services

Now, switch over to the “Storage” section. Here we can see the auto generated storage account and the location (datacenter) we specified back when the virtual network was created (Figure 20).

Figure 20: Storage account

Within the storage account under the “Containers” tab is a folder called “vhds” and within this subfolder, we can see the VHD file for the virtual machine we just created (Figure 21).

Figure 21: VHD folder with the virtual machine VHD file

Let us continue by creating the second Domain Controller. Again, click the “New” button and select “From Gallery” where you should select the same image as we did for the first Domain Controller.

Figure 22: Choosing from gallery

Name the Domain Controller (I call the second one AzureLabADDS2). Use the same building block and same credentials and click the arrow.

Figure 23: Virtual Machine Configuration

On the next page, we need to pay a little attention. Here, you need to specify the existing cloud service as well as the existing availability set (Figure 24).

Click the arrow.

Figure 24: Virtual Machine Configuration Continued

Leave the endpoints as is and click the checkmark to finish the configuration.

Figure 25: Default Endpoints

Like was the case with the first virtual machine, this one will also go through the various start and running processes.

Figure 26

When the virtual machine goes into a status of “Running”, click on the name of the second virtual machine and go to the “Dashboard”.

Figure 27: Both Virtual Machines in a status of “Running”

Here you can see the public virtual IP (VIP) is the same as the one associated with the first virtual machine we deployed. This is because the machines have been placed into the same cloud service.

Figure 28: Configuration Details

Now go to the “Cloud Services” section and click “Instances”. Here you can see both machines listed.

Figure 29: Virtual Machines listed in the Cloud Services section

Under the VHDs subfolder in the respective storage account, we can now see two VHD files. One for each server.

Figure 30: VHD files under the storage account

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

Introduction

Creating a Virtual Network

Creating the Virtual Machines

About The Author

Henrik Walther

Leave a Comment Cancel Reply

Introduction

Creating a Virtual Network

Creating the Virtual Machines

About The Author

Henrik Walther

Read Next

Leave a Comment Cancel Reply