Uncategorized | Skylera Blog

Using Windows Azure Virtual Machines to Learn: Networking Basics

Until recently I’ve used a personal hypervisor to experiment and learn new Windows technologies. Over the past few years my personal productivity machines have become more like mini datacenters – tons of cores, memory and storage. You know how it is, you go shopping for a new sub 2 pound / $1K notebook and by the time you click “add to cart” it gained about 4 pounds and $3K.

Enter Windows Azure. With only a browser and an RDP client I can spin up and manage just about anything. In other words, I could get away with an old PC or even a thin client and get out of the personal datacenter business. That $3K notebook just turned into a couple years of compute and storage in a real datacenter.

Don’t already have a Windows Azure account? Go here for a free trial.

Anyway, speaking of experimenting in the cloud, let’s talk about networking in Windows Azure Virtual Machines…

Did I just see a server with a DHCP-assigned IP address?

Windows Azure introduces a new concept when it comes to networking – DHCP for everything regardless of workload. That’s right, even servers are assigned IP addresses via DHCP. This comes as a surprise to hard core server admins. We have become religious about our IP spreadsheets, almost charging people when asked for one of our precious intranet addresses. Like labeling our network cables, this is another thing we’re going to have to let go when migrating workloads to the cloud.

The platform is now our label maker. As long as a virtual machine exists, it will be assigned the same IP address. Wait a minute, I thought DHCP only leased IP addresses out for a finite amount of time. What happens when the lease expires? Well, let’s find out when our lease is up on my domain controller using ipconfig /all:

Wow. Our virtual machine has a lease on 10.1.1.4 for over 100 years. I think we’re good. Even still, the platform automatically renews the lease for a given virtual machine.

What’s the point of subnetting in Windows Azure?

Most of the time we subnet to segregate tiers of a service, floors of a building, roles in an organization, or simply to make good use of a given address range. In Windows Azure, I typically use subnets when defining service layers:

In this case we have a simple 3-tier application that uses classic Windows authentication. There is a management subnet containing the domain controllers, a database subnet with SQL servers, and an application subnet with the web front ends.

Here is another type of deployment where we simply wanted to isolate virtual classrooms from each other:

The deployment shared a common Active Directory, however each classroom had its own instructor and students.

What can I do with subnets once they’re created?

Once you have defined your subnets and their services, you can secure those services by applying Windows Firewall rules and settings in a consistent manner. For example, you can define rules where servers on the application subnet (10.1.3.0) should only be able to reach the database subnet (10.1.2.0), and only over ports relevant to the SQL Server database engine service instance (i.e. TCP 1433).

In other words, subnetting in Windows Azure allows you to organize objects in the cloud for many of the same reasons you do on-premise. In this case we’re using it to contain similar services and create logical boundaries to simplify firewall configuration settings. When you create a consistent deployment topology for cloud services in Windows Azure Virtual Machines, you can then take advantage of other Windows technologies such as WMI Filters and Group Policy to automate and apply consistent security settings.

We’ll talk about applying role-specific firewall settings via Group Policy in a future blog.

Don’t already have a Windows Azure account? Go here for a free trial.

Integrating Active Directory into Windows Azure Virtual Machines

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
Create a virtual network
Create a storage account
Create virtual machines

We’re only going to cover the different off ramps we take to accomplish this scenario. If you need help with any of the fundamentals, here is a great resource.

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:

Creating highly available Domain Controllers using PowerShell

Relevant excerpts from createService.ps1:

$instanceSize = ‘Small’
$imageName = ‘MSFT__Win2K8R2SP1-Datacenter-201210.01-en.us-30GB.vhd’
$subnetName = ‘Management’
$availabilitySetName = ‘skydc’

$password = ‘@skyDc01′
$vmName = ‘skydc01′
$skydc01 = New-AzureVMConfig -Name $vmName -AvailabilitySetName $availabilitySetName -ImageName $imageName -InstanceSize $instanceSize |
Add-AzureProvisioningConfig -Windows -Password $password |
Set-AzureSubnet $subnetName

$password = ‘@skyDc02′
$vmName = ‘skydc02′
$skydc02 = New-AzureVMConfig -Name $vmName -AvailabilitySetName $availabilitySetName -ImageName $imageName -InstanceSize $instanceSize |
Add-AzureProvisioningConfig -Windows -Password $password |
Set-AzureSubnet $subnetName

Once you’ve created the servers, you will need to make them domain controllers, also known as promotion.

Promoting a server to a Domain Controller using DCPROMO or PowerShell

Depending on what operating system you have chosen, you can automate forest creation via command line. In the following examples, be sure to replace DOMAIN_HERE with the desired domain name, and replace passwords with those corresponding to temporary password you assigned to the local administrator account on the first (primary) server.

Windows Server 2008 R2 – Create a new forest using DCPROMO

dcpromo.exe /unattend:C:\primaryDomainController.txt

Contents of C:\primaryDomainController.txt:

[DCInstall]
; New forest promotion
ReplicaOrNewDomain=Domain
NewDomain=Forest
NewDomainDNSName=[DOMAIN_HERE].com
ForestLevel=4
DomainNetbiosName=DOMAIN_HERE
DomainLevel=4
InstallDNS=Yes
ConfirmGc=Yes
CreateDNSDelegation=No
DatabasePath=”C:\Windows\NTDS”
LogPath=”C:\Windows\NTDS”
SYSVOLPath=”C:\Windows\SYSVOL”
SafeModeAdminPassword=@skyDc01
RebootOnCompletion=Yes

Windows Server 2012 – Create a new forest using PowerShell

C:\primaryDomainController.ps1

Contents of C:\primaryDomainController.ps1:

Import-Module ADDSDeployment
Install-ADDSForest `
-CreateDnsDelegation:$false `
-DatabasePath “C:\Windows\NTDS” `
-DomainMode “Win2012″ `
-DomainName “[DOMAIN_HERE].com” `
-DomainNetbiosName “DOMAIN_HERE” `
-ForestMode “Win2012″ `
-InstallDns:$true `
-LogPath “C:\Windows\NTDS” `
-NoRebootOnCompletion:$false `
-SysvolPath “C:\Windows\SYSVOL” `
-Force:$true

Part of your homework will be to create the second domain controller in the new forest. There will need to be slight changes made to the answer files above.

What’s next?

Creating the rest of servers required by your application seems like the logical next step. However, there are a handful of important tasks I like to do prior to creating ANY additional virtual machines:

Create domain user accounts that will be used for future system administration.

Create containers for major objects such as server computer accounts.

Create core group policies for significant items such as:

Remote Desktop Services – Enable Keep-alives (posted previously)
User Account Control
Windows Firewall
Windows Update

Important considerations

When creating a private forest, consider the amount of administrative overhead involved vs. level of isolation. For example, you may want to have a single forest for all pre-production environments so that you only need to perform user account tasks in one place. This is easy to do in Windows Azure.