Tuesday, December 16, 2014

The Imperfect Lab: A Few VM Manageability Tweaks

Today in the Imperfect Lab I'm going to work on some clean up to improve the manageability of my new domain controllers. Since I have two of them, I want to take advantage of the Azure's service level agreement.  The only way to ensure that Azure keeps at least one DC running at all times is to create an availability set, which will distribute the VMs within a set across different update and fault domains.

Some notes about Availability Sets - VMs must be in the same cloud service and you can have a maximum of 50 in each set. You will find that your machines are spread across 2 fault domains and upwards of 5 update domains.  Also, avoid creating a set with just one machine it, because once you create a set you won't get notifications about maintenance regarding those update/fault areas. 

Since my machines have already been created I use the following PowerShell to update them with a set named "ADDC".

Get-AzureVM -ServiceName "imperfectcore" -Name "dc-cloud1" |
    Set-AzureAvailabilitySet -AvailabilitySetName "ADDC" |
    Update-AzureVM

Get-AzureVM -ServiceName "imperfectcore" -Name "dc-cloud3" |
    Set-AzureAvailabilitySet -AvailabilitySetName "ADDC" |
    Update-AzureVM

If you want a quick gander at all the availability sets that exist in your subscription, run this:

(Get-AzureService).servicename | foreach {Get-AzureVM -ServiceName $_ } | select name,AvailabilitySetName

Since the GUI does hold a fond place in my heart, I do want the dashboard of Server Manager on one of the VMs to show the status of all the servers in the domain.  You'll notice that if you log into the desktop of one of these newly created servers the "Remote Management" will be disabled.  This needs to be enabled to allow management from other services, so run "winrm quickconfig -q" against each server to turn that on.  You will have to start a PS-Session for each server for that.

Finally, since I expect to reduce the amount of times I'm logging into a machine directly, I'm going to take switch one of the DCs to Server Core and the other to the MinShell format.  These commands do take a while to complete and require a restart to complete the configuration, so don't panic if you can't connect to what looks like "running" VMs in Azure for a few minutes after reboot.

For Server Core (from a Machine running the Full GUI):
Remove-WindowsFeature -name User-Interfaces-Infra
Restart-Computer -Force

For MinShell (from a Machine running the Full GUI):
Remove-WindowsFeature -name Server-GUI-Shell
Restart-Computer -Force

With the MinShell installation I will still have access to the nice Server Manager dashboard when I want it and will be able to remotely manage the 2nd domain controller from it.  The list below will show the differences between each of the versions. (Click to make it bigger!)




Thursday, December 11, 2014

The Imperfect Lab: More DCs and Static IPs

When I was last working in my Imperfect Lab, I added another server to the existing cloud service and decided to make it a domain controller.  When you set up domain controllers (cloud or on-premises) a few things become really important - IP Addresses and DNS.

By default, Azure will provide DNS services from the fabric if you don't specify your own DNS.  You would think there is some PowerShell to do that directly, but surprisingly there isn't.  You can set the DNS for each network using the Management Portal or by exporting the network configuration file and updating it.  I just used the portal and made sure that my ImperfectNet listed the IP address for both servers that would act as domain controllers.

If you don't set a domain controller as the DNS server, all the VMs that come up inside your virtual network will look to an Azure fabric DNS server and won't be able to authenticate to your domain.  Since this is a crucial to AD function, I also wanted to make sure that the VMs that were acting as domain controllers had static internal IP addresses. 

Now, these addresses aren't really "static" on the OS. They are more like DHCP reservations handed out from the fabric manager.  But the end result is the same - VMs that have the correct IP address, regardless of the order they are started.

To do this with PowerShell, you first need to have the VMs in the Stopped (Deallocated) state. This way the addresses are free to assign.  If the VM is already running, the address is allocated already, thus can't be assigned.  You can double check that an address is free with:

Test-AzureStaticVNetIP –VNetName ImperfectNet –IPAddress 192.168.1.5

To set the static address, I used:

Get-AzureVM -ServiceName ImperfectCore -Name DC-Cloud1 | Set-AzureStaticVNetIP -IPAddress "192.168.1.4" | Update-AzureVM

Take note of the use of quotes around the IP address in that last line. It matters. I don't know why.  Just trust that I wasted a lot of time on your behalf for that knowledge.

Then to finally kick off the addition of my second domain controller in this domain, I used:

Install-ADDSDomainController -Credential (Get-Credential) -DatabasePath 'C:\Windows\NTDS' -DomainName 'imperfectlab.com' -InstallDns:$true -LogPath 'C:\Windows\NTDS' -NoGlobalCatalog:$false -SiteName 'ImperfectNet' -SysvolPath 'C:\Windows\SYSVOL' -NoRebootOnCompletion:$true -Force:$true -Verbose

One note about the paths used for the logs and SYSVOL… I've left them on C:\ for convenience, but for production, you will want to set up your DCs in Azure with an additional disk where you direct those files to go.  Read more about the reason behind that best practice here.

Also, if this Domain Controller happens to connect back to an on-premises domain. Be sure to make the proper changes to you AD Sites and Services to ensure proper site topology.

Tuesday, December 9, 2014

The Imperfect Lab: There's No Such Thing as a Free Gateway

Sometimes I forget that the internet isn't really free.  I have the convenience of having a MDSN subscription from work, so I enjoy the access to a set amount of Azure credits each month to spend.  However, some things are more "spendy" than others and gateways fall into that category for me, particularly for a testing scenario that doesn't have a "real" business need behind it.

MSDN users of Azure do get some discounted rates. All instances for Windows and Windows Server Virtual Machines, Cloud Services, Websites, and HDInsight are discounted up to 40% off our Pay-as-you-go rates. The MSDN rate on these services is equal to the rate for a Linux virtual machine of the same size and type. (For more details about MSDN benefits visit http://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-details/)

But all the other things are billed at regular rate, for gateways that rate is about $.05 per hour, a tad over one dollar a day.  When connecting a VNET to a VNET you are paying for two gateways, so my costs just to keep that running for my Imperfect Lab will eat up about a third of my monthly credits.  Take note, even gateways you aren't actively using are charged. So if you have a point-to-site gateway setup for clients to connect with but no clients are connecting, that's being charged too, just to keep it available. 

So with the holidays coming and my growing list of things I'd like to do in the lab, I'm going to rip down the VNET-to-VNET connectivity for the time being.  I'm going to build out my little infrastructure in one VNET to start and then extend it to the second VNET once I really have a set plan in place.

Onward to my domain controller creation and tying that into Azure Active Directory. Stay tuned.

Monday, December 1, 2014

The Imperfect Lab: Deploying More VMs

As I mentioned, I had created my first VM in my Imperfect Lab with the Azure Portal.  But I wanted to be able to do this using PowerShell from my workstation To recap my "physical" set up so far:
  • VNETs
    • ImperfectNet
    • AnotherNet
  • Storage Accounts in Different Regions
    • imperfectstore (West US)
    • anotherstore (East US)
  • Cloud Services
    • imperfectcore
    • anothercore
(I don't think I've mentioned it before, but if you are just starting out and need to get your ISE connected to you Azure account, just run Add-AzureAccount. You'll get prompted for your credentials.)

To start, I'm just going to create an additional server in the same network as my current domain controller.  Then I'll have a server I can promote to DC later, or use for another service. 

If you have multiple subscriptions and/or multiple storage accounts set up, like I do, you need to make sure Azure knows where you want to put things. My subscription happens to be the Visual Studio one.

Set-AzureSubscription -SubscriptionName "Visual Studio Ultimate with MSDN" -CurrentStorageAccount "imperfectstore"

Then you'll want to configure the basic variables for your VM. In this case, this is the adminstrator name and password, as well as the name of the Windows Server 2012 R2 image available at the time of this exercise. You'll want to make sure to get the current name of whatever OS you want to install.

$un = "adminname"
$pwd = "secretpassword"
$image = "a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201411.01-en.us-127GB.vhd"

Pick up that VM image the full list with: Get-AzureVMImage | Select ImageName

Then,  configure a few more variables using the New-AzureVMConfig.  In this case, I'm settting the server name and instance size, pulling in the username and password variable I set with the lines above and specifying the pre-existing subnet I want to use.

$newVM = New-AzureVMConfig -Name "Server2" -InstanceSize "Small" -Image $image |
     Add-AzureProvisioningConfig -Windows -AdminUserName $un -Password $pwd |
     Set-AzureSubnet -SubnetNames "FirstSubnet"

Finally, kick off the VM creation with one of the following options: 
  • Into an Existing Cloud Service: New-AzureVM -VMs $newVM -ServiceName "imperfectcore" 
  • Into an New Cloud Service:  New-AzureVM -VMs $newVM -ServiceName "newcloudservice" -Location "West US" -VNetName "imperfectnet" 
Give this all a few minutes to cook and your new VM will be deployed. I haven't joined it to the domain yet... baby steps here, baby steps!  I like to make sure one thing works at time, so it's easier to troubleshoot when I have issues.  That's what a lab is for, right?  



Wednesday, November 26, 2014

The Imperfect Lab: Standing Up Active Directory in Azure with PowerShell Remoting

Today in my Imperfect Lab, I needed to start adding some servers so I could build out a domain. So I popped over to the management portal and quickly spun up "DC-Cloud1" in the "FirstSubnet" of my ImperfectNet.

  • ImperfectNet
    • FirstSubnet (192.168.1.0/24) <- right in here!
    • HalfSubnet (192.168.2.0/25)
    • Gateway (192.168.3.200/29)

I logged in and was just about to click "Add Roles/Features" when I paused. What fun is that? I've installed AD a million times that way and it would be way more interesting to do it from PowerShell ISE from my laptop. So I closed out my RDP session and got to work.

First you have to install the remote access certificate on your local machine. To do that you want to download this script - Configures Secure Remote PowerShell Access to Windows Azure Virtual Machines.  Put is somewhere easy to access, open it in PowerShell ISE and then feed the script your personal variables to install the certificate on your machine.  Once that's done, you'll be able to use the lines below to open a PowerShell session directly to your VM.

$uri = Get-AzureWinRMUri -ServiceName $cloudServiceName -Name $Name 
$cred = Get-Credential  
Enter-PSSession -ConnectionUri $uri -Credential $cred  

Now that I had a secure, remote session it was time to install Active Directory.

Add-WindowsFeature -name ad-domain-services -IncludeManagementTools
Install-ADDSForest -DomainName "yourdomain.com" -ForestMode 5 -DomainMode 5

Those "mode" numbers are adjustable for controlling the forest and domain functional levels. 5 is for 2012. For Server 2003 functional level use 2, for Server 2008 use 3.

Finally, just in case I wanted easy access to RDP to the machine, I installed the newest Remote Desktop Connection Manager 2.7. This way I don't have to download and keep track of RDP files from the Azure Portal every time. (Shout out to Tommy Patterson for letting me know about that version update last week!)