This content is the documented script that we will be demonstrating at Microsoft TechEd in Houston on May 13, 2014 in session DCIM-B330 "Best Practices Integrating On-Premise Datacenters with Azure IaaS" at 10:15am-11:30am, Ballroom C. It is auto-provisioning of virtual machines up in Azure using Microsoft System Center Orchestrator 2012 R2.
This set of runbooks provisions a new Azure virtual machine in an existing stretched data center. It joins the machine to the domain and installs a SCOM agent for monitoring immediately after deployment.
0.0 New VM
This is the master runbook that calls all the other runbooks. It uses Orchestrator variables to store the needed information to connect to the Azure subscription, for the Azure virtual network and for the Azure affinity group.
The runbook has a single activity and then calls a series of child runbooks. The runbooks are called with parameters from Orchestrator variables.
The “Get Server Number” activity reads in the current machine count from a text file.
The contents of the MachineCount.txt are shown below. It’s just a single line that tracks the count of the machines and is used to name the new instances.
The server name is created using a variable prefix (“CCOLAB200SV”) to which the machine count is appended to form the final server name, in this case CCOLAB200SV8. The machine count will be incremented in each run of the runbook.
1.0 Provision VM in Virtual Network
This is the runbook that provisions the new VM in Azure. It assumes that there is an Azure subscription, an existing stretched data center Azure virtual network with an affinity group, a common Azure storage account.
It takes a number of parameters, as shown below.
The “Provision New Azure VM” activity uses a PowerShell script to create the Azure VM. The activity is shown below, but is only partially visible.
The full script is shown below for readability.
2.0 Get VM IP
Once the VM has been created in Azure, we need to get the IP address of the machine to reach it remotely and add it to the on-premise Active Directory domain (in step 3.0).
We initialize the run book with the Azure connection information and the servername of the new Azure VM. This will allow us to retrieve the IP address from the Azure VM definition.
Below is the script from the “Get Azure VM IP Address”. Because the VM was newly created and might not be running or have an IP address assigned yet, the script will loop until the IP address of the machine becomes available.
The “Get Azure VM IP Address” activity uses a PowerShell script to get the Azure VM IP. The activity is shown below, but is only partially visible.
3.0 Add VM to DomainThe parameters for the runbook are listed below. Notice how we no longer need the Azure connection information, as we are working directly with the virtual machine due to the stretched data center.
Now that we have the Azure VM IP address and we have a stretched data center, we have full network access to the virtual machine. We can work with it as we would with any other server in our on-premise network. This runbook adds the new Azure VM to the on-premise Active Directory domain.
The “Add Computer to Domain” activity uses a PowerShell script to get the Azure VM IP. The activity is shown below, but is only partially visible.
4.0 Install SCOM Agent
Below is the full script for the “Add Computer to Domain” activity. Notice that there is now Azure specific code in the script and that it could be used to join any machine to the domain, not just an Azure VM. This is where we see the full integration of the stretched data center, where cloud and on-premise servers are treated exactly the same.
Once the new Azure virtual machine is domain joined, we want to make sure that the virtual machine is monitored by System Center Operations Manager immediately. The “Install SCOM Agent” runbook installs the SCOM agent on the new Azure virtual machine.
As parameters, all we need is the computer name of the new Azure virtual machine. Because it is domain joined and the data center has been stretched, standard commands will work exactly the same as for on-premise servers.
The standard Orchestrator Run Program activity is used to launch the SCOM 2012 R2 agent installation with the appropriate parameters.
The agent source files were preloaded on the custom Azure image that was used to build the new Azure VM.
5.0 Increment Server Count
Now that the new Azure virtual machine is built and being monitored by SCOM, the machine count file needs to be updated for the next build. The “Increment Server Count” runbook does that.
The runbook takes as input the current server number.
The first activity sets an Orchestrator counter to the current server number. This will allow us to hold the value.
Before saving the new machine build number, we clear the existing line from the MachineCount.txt file.
The next activity increments the Orchestrator counter by one to use for the next Azure virtual machine build.
We then write the updated machine build number from the Orchestrator counter to the MachineCount.txt file to make it ready for use on the next Azure virtual machine build.
Additional information could be stored and updated in the text file if needed. The machine count information could just as easily been stored in a database table rather than a text file as well, for better scalability or fault tolerance.
Chris and I will cover all of this step by step at TechEd in Houston, track down our session noted at the start of this blog post!
Rand