31 Days of Servers in the Cloud: Utilizing PowerShell for Integrating Active Directory into Windows Azure Virtual Machines (Part 23 of 31) by Dan Noonan; posted by Tommy Patterson - Harold Wong's Blog with Geekie Thoughts and Insights - Site Home

On Wednesday, January 23, 2013, Tommy Patterson posted Part 23 of 31 in the 31 Days of Servers in the Cloud Blog Series (written by Guest, Dan Noonan). Below is a small excerpt from his blog.

Most of the work I’ve been doing lately involves migrating traditional client/server applications to Windows Azure Virtual Machines. The majority of these workloads use Active Directory Domain Services as their authentication provider, or in other words, classic Windows authentication. In this blog we’ll walk through the basic building blocks of creating a private forest within Windows Azure.

if Active directory is not available, you better be

As we all know, if AD is down so is your app. Imagine setting up a single domain controller responsible for both name resolution (DNS) and authentication. You just created another synonym for single-point-of-failure. At a minimum you should deploy two (2) domain controllers, and they should be created as part of an Availability Set. This will ensure that at least one (1) domain controller is always available for authentication and name resolution requests. If you’re considering saving a few bucks by deploying a single domain controller in non-production environments, let me save you a few more. The first call you get from development or QA will cost you at least 6 months of compute. Telling a dozen upset people on a conference call that you wanted to save the company $50/month will sound pretty bad…

a private forest for me? oh you shouldn’t have

There are currently two major scenarios for providing Windows authentication in Windows Azure Virtual Machines:

Deploy a new private forest
Extend an existing on-premise forest

In this blog we’ll cover deploying a new private forest. Here is a quick Visio of a classic 3-tier application (using Windows Azure features) to get us started:

As you can see, we have a management subnet that contains our domain controllers, as well as separate database and application “tiers”.

Stop Talking and Start Deploying

As with any new deployment to Windows Azure Virtual Machines, you will perform the following high-level steps:

Create an affinity group (See Bob Hunt’s Article in the Series)
Create a virtual network (See Bob Hunt’s Article in the Series)
Create a storage account (See Kevin Remde’s Article in the Series)
Create virtual machines (See Tommy Patterson’s Article in the Series)

While creating the virtual network, you will need to specify that the domain controllers will also be providing name resolution for all of the servers in your deployment. You can do this in the Windows Azure management portal as well as through the management web service. Here is how you do this via PowerShell:

Specifying custom DNS servers using PowerShell

Example command line:

Set-AzureVNetConfig –ConfigurationPath “C:\networkConfiguration.xml”

Contents of C:\networkConfiguration.xml:

In the example above, the IP addresses used assume the domain controllers are the first virtual machines created on the Management subnet. Let’s make sure that’s true by creating them now:

To get the full article, please read it here: http://virtuallycloud9.com/index.php/2013/01/integrating-active-directory-into-windows-azure-virtual-machines/

Harold Wong