Virtualization has made server deployments easier, and putting a new server into production can be as easy as right-clicking on a template and selecting Deploy VM and applying a customization spec.
Deploying a VM from a template is just one step in the process. Manual intervention, or worse – multiple templates, may be required if the new VM needs more than the default number of processors or additional RAM. And deployment tasks don’t stop with VM hardware. There may be other steps in the process such as putting the server’s Active Directory account into the correct OU, placing the VM in the correct folder, or granting administrative rights to the server or application owner.
All of these steps can be done manually. But it requires a user to work in multiple GUIs and even log into the remote server to assign local admin rights.
There is an easier way to handle all of this. PowerShell, with the PowerCLI and Active Directory plugins, can handle the provisioning process, and .Net calls can be used to add a user or group to the new server’s Administrator group while pulling the configuration data from a SQL database.
The Script
I have a script available on Github that you can download and try out in your environment. The script, Provision-VM.ps1, requires a SQL database for profile information, which is explained below, PowerCLI, and the Active Directory PowerShell cmdlets. You will also need two service accounts – an Active Directory user with Administrator permissions in vCenter and an Active Directory user with Domain Administrator permissions.
This script was designed to be used with the vCenter Orchestrator PowerShell module and WinRM. vCO will provide a graphical front end for entering the script parameters and executing the script.
This script might look somewhat familiar. I used a version of it in my Week 1 Virtual Design Master submission.
What Provision-VM.ps1 Does
So what exactly does Provision-VM.ps1 do? Well, it does almost exactly what it says on the tin. It provisions a brand new VM from a template. But it does a little more than just deploy a VM from a template.
The exact steps that are taken are:
- Query the SQL database for the customization settings that are needed for the profile.
- Prestage the computer account in the Active Directory OU
- Create a non-persistent Customization Spec
- Set the IP network settings for the customization spec
- Deploy a new VM to the correct resource pool/cluster/host and datastore/datastore cluster using the specified template based on the details retrieved in step 1.
Note: The Resource Pool parameter is used in the script instead of the host parameter because the Resource Pool parameter encompasses hosts, clusters, and resource pools. This provides more flexibility than the host parameter. - Add additional CPUs and RAM is specified using the –CPUCount and –RAMCount parameters
- Power on VM and customize
- Add server owner user account or group to the local administrators group if one is specified using the –Owner parameter.
By using this deployment process along with some other scripts for configuring a server for a specific role after it has been deployed, I’ve been able to reduce the number of templates that need to be managed to 1 per Windows version.
WinRM and Working Around Kerberos Issues
vCenter Orchestrator is a great tool for automation and orchestration, and VMware has developed a PowerShell plugin to extend vCO management to Windows hosts and VMs. This plugin even uses WinRM, which is Microsoft’ s preferred remote management technology for PowerShell.
WinRM setup for the vCO appliance, which I use in my environments, requires Kerberos to be used when making the remote connection. I use a single Windows jumpbox to execute all of my PowerShell scripts from one location, so I run into Kerberos forwarding issues when using vCO and PowerShell to administer other systems.
There is a way to work around this, but I won’t spend a lot of time on it since it deserves it’s own post. However, you can learn more about how the password information is stored and converted into a PowerShell credential from this article on PowerShell.org.
I also put together a little script that creates a password hash file using some of the code in the article above.
SQL-Based Profiles
One of the drawbacks of trying to script server deployments is that it needs to be simple to use without making it too hard to maintain. I can make all required inputs – cluster or resource pool, datastore, template, etc, – into parameters that the person who runs the script has to enter. But if you plan on using a script as part of a self-service provisioning model, keeping the number of parameters to a minimum is essential. This helps limit the options that are available to users when deploying VMs and prevents them from having to worry about backend details like cluster and datastore names.
The tradeoff, in my experience, is that you need to put more into the script to compensate for having fewer parameters. To do this, you’ll need to create “profiles” of all the customization settings you want to apply to the deployed server and code it directly into the script.
Let’s say you have one vSphere. The cluster has three VLANs that servers can connect to, two datastore clusters where the server can be stored, and three templates that can be deployed. To keep the script easy to run, and prevent admins or app owners from having to memorize all the details, you’d need to create 18 different profile combinations to cover the various settings.
This can make the script larger as you’ll need to include all combinations of settings that will be deployed. It also makes it more likely that any additions or changes could introduce a script breaking bug like a missing curly bracket or quotation mark.
There is another way to reduce the size and complexity of the script while keeping parameters to a minimum – use a SQL database to store the customization settings. These customization settings would be queried at run-time based on the profile that the end user selects.
The database for this script is a simple single table database. There is a SQL script on Github to set up a table similar to the one I use in my lab. If you choose to add or remove fields, you will need to edit the Provision-VM.ps1 file starting around line 106.
There are two ways that the information can be retrieved from the database. The first method is to install SQL Server Management Studio for SQL Server 2012 or newer on the server where the script will be executed. The other is to use .Net to connect to SQL and execute the query. I prefer the later option because it requires one less component to install.
The code for querying SQL from PowerShell, courtesy of Iris Classon’s blog that is linked above, is:
$dataSource = $SQLServer $user = "SQL Server User Account" $pwd = "Password" $database = "OSCustomizationDB" $databasetable = "OSCustomizationSettings" $connectionString = "Server=$dataSource;uid=$user;pwd=$pwd;Database=$database;Integrated Security=False;" $query = "Select * FROM $databasetable WHERE Profile_ID = '$Profile'" $connection = New-Object System.Data.SqlClient.SqlConnection $connection.ConnectionString = $connectionString $connection.Open() $command = $connection.CreateCommand() $command.CommandText = $query $result = $command.ExecuteReader() $ProfileDetails = new-object “System.Data.DataTable” $ProfileDetails.Load($result)
Once the settings have been retrieved from the database, they can be used to determine which template will be deployed, the resource pool and datastore or datastore cluster that it will be deployed to, temporarily modify an existing customization spec NIC mapping settings at runtime, and even determine which OU the server’s AD account will be deployed in.
The benefit of this setup is that I can easily add new profiles or change existing profiles without having to directly edit my deployment script. This gets changes into production faster.
More to Come…
This is just scratching the surface of deployment tasks that can be automated with PowerShell. PowerShell 4.0 and Windows Server 2012R2 add a lot of new cmdlets that can automate things like disk setup.
The Virtual Horizon 