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?  

Update (12/26/14): For easy access to these code snippets, you can find them here.

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. (For more info Michael Washam's script, check out his post, Introduction to Remote PowerShell with Windows Azure.)

$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!)

The Imperfect Lab: Connecting a VNET to another VNET

As I mentioned yesterday, I'm struggling with setting up the "perfect" lab environment for myself. So instead of trying to make it perfect, I'm just going to start by simply getting started and letting in evolve.  Because starting is most of the battle, right?  Most environments grow and change and become a bit messy, so I am just going to embrace a little chaos!

My starting goal is to create two networks in Azure (in two different regions) and connect them.  To start I'll need two VNETs in Azure. I also created two corresponding storage accounts in each region, so that when I'm building my servers, everything is as neat an organized as I can make it.

In each of the networks, I carved out a few subnets, because I don't know exactly what I'm doing with them yet. Keep in mind you will need to make at a small Gateway subnet in each. Also, as soon as you put a VM in a subnet, you can no longer edit it.

• ImperfectNet - 192.168.1.0/22 (West region)
• AnotherNet - 192.168.4.0/23 (East region)

Because I want to connect them together with site-to-site networking, I have to create corresponding "local" networks in Azure to sort of trick each network into thinking its connecting to a physical network.  So under the "Local Networks" tab, I created "ImperfectLocal" and "AnotherLocal" with the same IP address ranges as the virtual networks. Be sure to put in a fake VPN Gateway Address as a placeholder here, you'll update it later after Azure gives you a real gateway address.

In each network, I threw the ticky-box under Site-to-Site Connectivity, selected the correct "local" network and then created the Gateway subnet.  After everything was finished configuring, when you return to the dashboard page of each network, you will see the remote network showing.  Azure will tell you that "the gateway was not created".

Click "create gateway" at the bottom. For VNET to VNET connectivity, you have to go with Dynamic Routing.  Do this for each network and wait for it to complete.  (Creating gateways actually takes a while, this might be a good time to get lunch.)

Once your gateways are created, write down the IP addresses carefully and then edit those "local networks" with the fake VPN gateways to the correct ones Azure just assigned you.

Finally, you have connect the networks together with shared key.  There isn't any way to do this in the portal, so pop over to PowerShell and use the following code to hook them together.  You have to run the command twice with the corresponding network names and the SAME shared key. Please make your key longer then the sample I put in here.

Set-AzureVNetGatewayKey -VNetName YourVNETName -LocalNetworkSiteName TheOppositeLocalNet -SharedKey abc123xyz

Set-AzureVNetGatewayKey -TheOtherVNetName YourVNETName -LocalNetworkSiteName TheOtherLocalNet -SharedKey abc123xyz

So now I've got two connected networks in Azure, albeit empty of servers.  Next up... starting to build out my "imperfect" domain.

One more thing... if you want the offical "Azure" instructions for this, complete with images, go to http://msdn.microsoft.com/en-us/library/azure/dn690122.aspx.  

The Quest for the Perfect Lab

There are a few old sysadmin jokes out there... one that often comes to mind for me these days is the one-liner about how the perfect network is one that no one is on.  But now that I have the luxury of being able to build just about any lab network I want (either in Azure or using Hyper-V) I find myself nearly paralyzed by wanting to build the "perfect" network/lab for my needs.

I start, I stop, I get sidetracked by a different project, I come back to my plan, only to realize I've forgotten where I left off (or forgotten where I wrote down that fancy admin password for that VM) and end up tearing it out and starting over again.  The end result is I'm getting no where fast.

I've got several MCSE exams in my future that I need to build some things for hands on for.  I have a little internal metric of how I need to improve my PowerShell a bit more.  I have work training items that sort of fit into all this and I keep striving for the perfect lab, the perfect naming system, the perfect password that I won't forget... well, I guess my "perfectionist" is showing.

It's a slow week here in the office with the Thanksgiving holiday approaching, so now is the perfect time to sit down with a pen and a paper and really figure out what I'm going to build and what I want to use it for.

Because there is something worse than a network that no one uses.  It's that network I keep deleting.

You Bought It... AND You Can Bring It!

Consumers want what they want. And when those consumers arrive at their place of work, they still want to use what they like. It seems like it wasn't that long ago where the best technology you had access to was at the office, but these days that's not always the case.

If you are looking to address "Bringing Your Own Device" in your organization, need to update corporate policies to support more current device lifecycles and get your hands around managing your applications and data on whatever device tries to connect to your data center, Kevin Remde has got you covered.

Check out his multipart series on just that topic.  It started out last December with Part 1 -What It Means for My Company, continued with Part 2 - How to Make it Happen and recently summed up things with Part 3.

In PART 3 - BYOD Design Considerations, Kevin Remde welcomes back Yuri Diogenes to the show as they continue their discussion around the benefits, challenges and considerations businesses must make around Bring Your Device (BYOD) and how IT organizations can support it.  

• [2:46] Why don't you give us a summary on the concept of BYOD?
• [6:20] I understand that recently you and your team have published some really useful resources to the Microsoft TechNet online documentation.  What have you created for us?
• [9:26]  How should one use the BYOD Design Consideration Guide?
• [13:51]  Can you give us an example of how an IT organization can use this guide in a real-world BYOD scenario?

Check out the FREE “BYOD Design Considerations Guide” and start giving people what they need, where they want it.  Working hard doesn't always happen in the office.

** 11/21/14 Update ** Want to learn more about BYOD tools and Mobile Device Management?  Don't miss this upcoming MVA - Taming Android and iOS with Enterprise Mobility Suite with Kevin Remde and Simon May on 12/8/14.