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

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

Introduction

In part 1 of this article series revolving around how you deploy an Exchange hybrid deployment in Windows Azure, we talked about what Windows Azure is and how you sign up for a trial subscription.

In this part 2, we will continue where we left off back in part 1. That is we will take a look at the Windows Azure portal and talk about the services within the Windows Azure platform that are relevant when it comes to preparing for deployment of the Windows Azure based virtual machines that will be used for our Exchange hybrid deployment. We will also dive into how you can connect to the Windows Azure platform using Remote PowerShell.

Let’s get going…

Overview of the Windows Azure Portal

As you saw back in part two of this article series, we finished that article by being presented with the Windows Azure Portal.

To log back into the portal, open your favorite browser and open “http://manage.windowsazure.com”. You will be redirected to the Windows Azure login page, where you need to enter your credentials.

Figure 1: Windows Azure Management Portal Login Page

Do so and you are once again faced with the Windows Azure Management Portal page.

Figure 2: Windows Azure Management Portal Page

As you can see there are quite a few sections listed on the left side. This is because you use this portal for most of the stuff you can do in Windows Azure no matter the task. For instance, this is the place where you create, deploy, configure or manage Active Directory (not to be confused with a traditional on-premises Active Directory), Cloud Services, Virtual Machines, Web Sites, Mobile Services, Visual Studio Online, Media Services, Storage, BizTalk Services, you name it.

In our specific scenario, the only relevant pieces are:

Virtual Machines
Cloud Services
Networks
Storage

Before we begin the configuration and deployment part, let us quickly go through each of the above listed pieces, so you can get an understanding of how they work and a glued together.

Virtual Machines

The “Virtual Machines” section of the portal is the place where we can create our virtual machines to be used in our Exchange hybrid lab environment.

Virtual machines can be created based on either images or disks.

Windows Azure contains a rather extensive gallery of server images both for Windows based and *NIX applications. In addition, you can upload your own VHDs to Windows Azure.

As you can see in Figure 3, the “virtual machines” section is rather empty by default.

Figure 3: Virtual Machine section within the Windows Azure Management Portal

We will dive much more into how we create and configure virtual machines later on in this article series when we create the virtual machines.

Cloud Services

So what is a “cloud service” and why do you need it? Well, this concept can be a little difficult to grasp.

Basically, if you decide to create an application and run it out of Windows Azure, the code as well as the configuration for that application together are called a cloud service. Cloud services can contain web or worker roles and makes it possible to distribute processing and allow flexible scaling.

With cloud services, Windows Azure will 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 could place the ADFS Proxy servers in a single cloud service and the ADFS Servers in another. In theory, we could also place the Exchange hybrid servers in a cloud service. In this article, we will not make use of cloud services for service availability, but instead place each individual server in its own cloud service. The reason for this is we want to simulate the real world production environments as closely as possible.

As you can see in Figure 4, the “cloud services” section is rather empty by default.

Figure 4: Cloud Services section within the Windows Azure Management Portal

We will dive a bit more into how we create and configure cloud services later on in this article series, when we create them together with our virtual machines.

Networks

Under the “Networks” section, we can create virtual networks in order to logically isolate sections within Windows Azure using private IP address ranges. This is also the place where we can configure a virtual private network (VPN) between Windows Azure and one or more on-premises environments.

With Windows Azure, we have the concept of private IP and VIP addresses. A virtual machine created in Windows Azure will get a private IP address dynamically from the private IP address range to which the virtual machine is associated.

In addition to a private IP address, all virtual machines will also have a VIP address assigned. A VIP address is a public IP address to which the public FQDN of the virtual machine will resolve (a virtual machine or cloud service will be published to the Internet using <server_name.cloudapp.net>).

All virtual machines must use dynamically assigned IP addresses. Static IP addresses are not supported in Windows Azure no matter the role of the server running on top of a virtual machine (including domain controllers, Exchange servers etc.). However, it’s possible to make sure a virtual machine always gets the same private IP address even when shut down in a “Stopped (deallocated)” state.

As you can see in Figure 5, the “network” section is rather empty by default.

Figure 5: Networks section within the Windows Azure Management Portal

We will dive much more into how we create and configure virtual networks later on in this article series when we create the virtual machines.

Storage

All Windows Azure subscriptions in which you create and deploy cloud services and virtual machines require storage. In Windows Azure it is referred to as a storage account. A storage account gives our applications access to Windows Azure Blob, Table, and Queue services located in a geographic region. A storage account can contain up to 200 TB of data, which should be just about enough for our Exchange hybrid lab environment.

In our scenario we need a storage account where we can store the disks (VHDs) used for our virtual machines.

Figure 6: Storage section within the Windows Azure Management Portal

We will dive a bit more into how we create and configure our storage account later on in this article series when we create the VHDs and storage blob together with our virtual machines.

Managing Windows Azure with Remote PowerShell

In addition to create, test, deploy, and manage solutions and services delivered through the Windows Azure platform using the Windows Azure Management Portal GUI, it is of course also possible to do these tasks (and more) through Remote PowerShell. However, you cannot just launch a Remote PowerShell and connect to the Windows Azure platform as you need to use a special Windows Azure PowerShell module that provides cmdlets to manage Windows Azure through Windows PowerShell.

Note:
For those of you using Mac or *NIX, there are also Command Line Interfaces (CLIs) available for these operating systems.

First, you must go to “http://windowsazure.com” and then click “Downloads” as shown in Figure 7.

Figure 7: Clicking Downloads on the Windows Azure frontpage

On the “Downloads” page, drill down to the bottom and click on “Windows Azure PowerShell”.

Note:
When we install the module, the installer checks our system for the required software and installs all dependencies, such as the correct version of Windows PowerShell and .NET Framework.

Figure 8: Clicking “Windows Azure PowerShell” on the “Downloads” page

Figure 9: Launching WindowsAzurePowerShell.exe file

This will launch the Microsoft Web Platform Installer.

Figure 10: Web Platform Installer 4.6

And after a few seconds, you are taken to the page shown in Figure 11. Click “Install”.

Figure 11: Windows Azure PowerShell module in the Web Platform Installer

On the “Prerequisites” page, click “I Accept”.

Figure 12: Accepting the listed prerequisites are installed

The Web Platform Installer will now begin to download the required component and then install them.

Figure 13: Downloading and installing prerequisites

When the installation process has finished, the machine needs to reboot before it can continue with the installation process of Windows Azure PowerShell.

Figure 14: Prompted for reboot after installation of the prerequisites

When the machine has rebooted, it will begin where it left off by installing the remaining components.

Figure 15: Installing the Windows Azure PowerShell Module after the reboot

When the components have been installed, click “Finish”.

Figure 16: Installation of the necessary components completed with success

Now click “Exit” in the Web Platform Installer.

Figure 17: Windows Azure PowerShell installed

Now let’s click “Start” > “All Programs” and launch “Windows Azure PowerShell” as shown in Figure 18.

Figure 18: Launching Windows Azure PowerShell

Figure 19: Windows Azure PowerShell window

We are now ready to connect to our Windows Azure subscription. In order to connect to and manage our service, the unique subscription information associated with our service is required. We have two options for connecting to the service:

We can download and use a management certificate that contains the necessary information
We can login using our Microsoft account or organizational ID.

Both methods are fine for logging in and manually managing our service. The primary difference is that if we use our credentials to login, the session will expire after 12 hours. However, if we use the certificate-based approach, we can be connected for the lifetime of the subscription as long as the certificate is valid. If you need to use automation for long running tasks, it’s recommended to use the certificate-based approach.

To connect using your Windows Azure credentials, you simply type Add-AzureAccount and enter your the credentials in the dialog box.

Figure 20: Choosing to authenticate using Microsoft Account or Organizational ID credentials

Enter your Microsoft Account or Organizational ID and click “Continue”

Figure 21: Entering Microsoft Account or Organizational ID

Enter the associated password and click “Sign In”.

Figure 22: Entering password associated with the Microsoft Account or Organizational ID

We are now connected to our Windows Azure subscription using Powershell.

Figure 23: Connected to Windows Azure service using credentials

Let us verify that we can run a cmdlet against Windows Azure. In this example, we will use “Get-AzureSubscription”, which will provide us with details about the subscription.

Figure 24: Retrieving subscription details using the “Get-AzureSubscription” cmdlet

To use the certificate-based approach, we must first download and import the certificate. To do so, type “Get-AzurePublishSettingsFile”. This will take us to a website from where we can download the certificate.

First on your Microsoft Account or Organizational ID.

Figure 25: Authenticating in order to download certificate

Enter the password associated with your Microsoft Account or Organizational ID.

Figure 26: Authenticating in order to download certificate

Download the “credentials-publishsettings” file.

Figure 27: Downloading certificate

Now navigate to the folder to which you downloaded the file.

Figure 28: Navigating to the folder containing the download file

Enter the following to import the publishsettings file:

Import-AzurePublishSettingsFile “.\name of the publishsettings file”

We are now connected to our Windows Azure subscription. To verify we can run a cmdlet against the service, use a cmdlet such as “Get-AzureSubscription”.

Figure 29: Importing the subscription file in order to authenticate to Windows Azure

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

Introduction

Overview of the Windows Azure Portal

Virtual Machines

Cloud Services

Networks

Storage

Managing Windows Azure with Remote PowerShell

About The Author

Henrik Walther

Leave a Comment Cancel Reply

Introduction

Overview of the Windows Azure Portal

Virtual Machines

Cloud Services

Networks

Storage

Managing Windows Azure with Remote PowerShell

About The Author

Henrik Walther

Read Next

Leave a Comment Cancel Reply