Don Noonan is back this week with a fresh write up based on his work deploying customer applications into Windows Azure. By utilizing PowerShell he is able to provide these repeatable steps for deploying Active Directory into the virtual machines of Window Azure. Enjoy!
---Written by Don Noonan---
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.
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…
There are currently two major scenarios for providing Windows authentication in Windows Azure Virtual Machines:
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”.
As with any new deployment to Windows Azure Virtual Machines, you will perform the following high-level steps:
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:
Example command line:
Set-AzureVNetConfig –ConfigurationPath “C:\networkConfiguration.xml”
Contents of C:\networkConfiguration.xml:
<NetworkConfiguration> <VirtualNetworkConfiguration> <Dns> <DnsServers> <DnsServer name="skydc01" IPAddress="10.1.1.4" /> <DnsServer name="skydc02" IPAddress="10.1.1.5" /> </DnsServers> </Dns> <VirtualNetworkSites> <VirtualNetworkSite name="skyvn" AffinityGroup="skyag"> <AddressSpace> <AddressPrefix>10.1.0.0/16</AddressPrefix> </AddressSpace> <Subnets> <Subnet name="Management"> <AddressPrefix>10.1.1.0/24</AddressPrefix> </Subnet> <Subnet name="Database"> <AddressPrefix>10.1.2.0/24</AddressPrefix> </Subnet> <Subnet name="Middleware"> <AddressPrefix>10.1.3.0/24</AddressPrefix> </Subnet> <Subnet name="Application"> <AddressPrefix>10.1.4.0/24</AddressPrefix> </Subnet> </Subnets> <DnsServersRef> <DnsServerRef name="skydc01" /> <DnsServerRef name="skydc02" /> </DnsServersRef> </VirtualNetworkSite> </VirtualNetworkSites> </VirtualNetworkConfiguration> </NetworkConfiguration>
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:
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.
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
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
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.
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:
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.
Published with Permission from Don Noonan, Don's Blog at Skylera