Setting the Machine Name of a vCAC-provisioned VM to comply with a Corporate Standard – Part 4 of 4

• Machine Prefix/Property Definition – Part 1
• Powershell – Part 2
• Workflow Configuration – Part 3
• Blueprint Update – Part 4

Review

In part 1, we configured the Machine Prefix, Property Dictionary and layout to accommodate our change. In part 2, we created and saved a powershell script to create the desired machine name from the inputs we provided. In part 3, we modified the Building Machine workflow stub to create and assign a new machine name. In this last part, we’ll finish by updating the blueprint and testing.

Recall that in Part 1, we created a Property Definition named “custom.machineRole” and a Property Layout named “machineRole.Selection”

Steps

1. Navigate to Infrastructure/Blueprints/Build Profiles
2. Create a new or edit an existing Build profile
3. From the “Add from Property Set”, select the appropriate “VMware*” property set for your O/S.
4. Save the updated Build Profile
5. Edit your vSphere Clone or Linked-Clone Blueprint
6. Confirm that the selected machine prefix is set to “Use Group Default” or is appropriate
7. Check the correct Build Profile for the Blueprint’s O/S. The objective here is to ensure the “VMware.VirtualCenter.OperatingSystem” property is set.
8. On the Properties page of the Blueprint settings, add the following Properties:
   

   Name	Value	Prompt User	Reason
   ExternalWFStubs.BuildingMachine		No	Execute the Workflow we’ve modified
   custom.machineRole		Yes	The name of our Property Definition
   VirtualMachine.Request.Layout	machineRole.Selection	No	The Property Name indicates that a custom layout should be employed and the value is the name of our Property Layout

   

9. Click OK to save the blueprint

Testing

• Logon as a member of a Business Group that has an entitlement to the Blueprint we’ve worked on.
• When requesting a VM from the blueprint, the request form should include the “Role” dropdown list with your values
• The resulting request will include the “custom.machineRole” property set to the selected value
• If you left the “write” lines in the PS script, you can check the C:\Scripts\nametest.txt file on the IaaS Server to ensure the values are passed and set correctly
• Lastly, of course, check to see if the provisioned machine has the appropriate name

Once again…
You should visit Adam Bohle’s blog and his fantastic posts about this. He knows way more about it than I do. I stepped through his and Tom O’Rourke‘s procedures and wanted to document what it took. Those guys are the authority on vCAC.

References
Powershell Scripting out of vCAC
Easily change the name of a provisioned machine in vCloud Automation Center to conform with company naming conventions
Common LINQ Queries for vCAC
Add a new location to a Compute Resource

Advertisement

Setting the Machine Name of a vCAC-provisioned VM to comply with a Corporate Standard – Part 2 of 4

• Machine Prefix/Property Definition – Part 1
• Powershell – Part 2
• Workflow Configuration – Part 3
• Blueprint Update – Part 4

Review

In part 1, we configured the Machine Prefix, Property Dictionary and layout to accommodate our change. In part 2, we’ll create our Powershell script that will create the new machine name from our inputs.

Recall that for this example, the name should use the initials of the Business Group, “V” for Virtual, a single letter for the OS (“W” for Windows, “L” for Linux), a three character “role” and a two digit sequence number for uniqueness.

Example Naming convention:
BG1VWAPP14
BG1 = Business Group initials
V = Virtual
W = Windows
APP = APPlication server
14 = Sequence number

We’ll pass the following variables to the script during execution:

Name	contains
$originalName	The name originally created by vCAC based on the Machine Prefix (“BG1-14” in the example above)
$vmwareOS	The value in the “VMware.VirtualCenter.OperatingSystem” property of the request (This is set when selecting the appropriate VMware O/S Property Set on the blueprint)
$machineRole	The value that the user selected in the “Machine Role” dropdown that we configured in Part 1 (“APP” in the example above)

Script

On the IaaS (or DEM Agent) server, save the following to “C:\scripts\CreateNewMachineName.ps1”:


$machineName=$originalName
write "Original name of the VM – $originalName" | out-file c:\scripts\nametest.txt
write "VMwareOS – $vmwareOS" | out-file c:\scripts\nametest.txt -append
if ($machineName -match "-"){
write "Name contains a dash" | out-file c:\scripts\nametest.txt -append
if ($vmwareOS -match "rhel") {$machineRole = "VL" + $machineRole}
if ($vmwareOS -match "sles") {$machineRole = "VL" + $machineRole}
if ($vmwareOS -match "sola") {$machineRole = "VS" + $machineRole}
if ($vmwareOS -match "wind") {$machineRole = "VW" + $machineRole}
$machineName=$machineName -replace "-", $machineRole}
write "machineRole – $machineRole" | out-file c:\scripts\nametest.txt -append
write "New Name – $machineName" | out-file c:\scripts\nametest.txt -append
$Global:PowerShellOutVar = $machineName


Line-by-line Explanation

Line Num	Code (should not wrap)	meaning
1	$machineName=$originalName	Set the $machineName variable to the value of the incoming variable $originalName
2	write “Original name of the VM – $originalName” | out-file c:\scripts\nametest.txt	Create the “C:\scripts\nametext.txt” file and write the value of the $originalName variable in it (just for validation/testing)
3	write "VMwareOS – $vmwareOS" | out-file c:\scripts\nametest.txt -append	Append the value in the $vmwareOS variable to the text file (again, just for validation/testing)
4	if ($machineName -match "-"){	Begin a conditional loop if the $machineName variable contains a dash
5	write "Name contains a dash" | out-file c:\scripts\nametest.txt -append	Append to the text file (again, just for validation/testing)
6	if ($vmwareOS -match "rhel") {$machineRole = "VL" + $machineRole}	Nested Loop that prepends “VL” to the $machineRole value if the $vmwareOS variable contains “rhel”
7	if ($vmwareOS -match "sles") {$machineRole = "VL" + $machineRole}	Nested Loop that prepends “VL” to the $machineRole value if the $vmwareOS variable contains “sles”
8	if ($vmwareOS -match "sola") {$machineRole = "VL" + $machineRole}	Nested Loop that prepends “VS” to the $machineRole value if the $vmwareOS variable contains “sola”
9	if ($vmwareOS -match "wind") {$machineRole = "VL" + $machineRole}	Nested Loop that prepends “VW” to the $machineRole value if the $vmwareOS variable contains “wind”
10	$machineName=$machineName -replace "-", $machineRole}	Update the $machineName variable by replacing the dash with the string built above
11	write "machineRole – $machineRole" | out-file c:\scripts\nametest.txt -append	Append the new $machineRole value to the text file (again, just for validation/testing)
12	write "New Name – $machineName" | out-file c:\scripts\nametest.txt -append	Append the new $machineName value to the text file (again, just for validation/testing)
13	$Global:PowerShellOutVar = $machineName	Create the PowerShellOutVar Global variable and assign it the value in $machineName

More info
This is a pretty simple script. The line-by-line is mostly for my own benefit, so I remember what it’s supposed to do later. 🙂 If your scenario requires that the same workflow is used for provisioning other than Virtual, you’d want to verify that the $vmwareOS exists and perhaps follow some other execution path if it does not. You’ll probably want to comment-out the lines that write to the text file once you’re satisfied that it works as desired.

Continue to Part 3 – Workflow configuration

Extending vCAC IaaS to fix an annoyance

Background: When provisioning a Windows VM using the Clone Workflow and a vSphere customization specification that joins the computer to an active directory domain, the computer object is placed in the “Computers” container. I want to change that. 🙂

Solution Overview:
Modify the built-in Stub workflow to execute a Powershell script that moves the computer object based on the Business Group.

Preparation:

1. Created a new Build Profile with the ActiveDirectoryCleanupPlugin, MiscellaneousVrmProperties, RemoteDesktopProtocolProperties and VMwareWindows2008R2_64Properties Property Sets.

   

   vCAC Build Profile Properties

2. Created a new Windows 2008 R2 VM from a vSphere template, did not power-on. Took a snapshot
3. Created a new shared vSphere Linked Clone Blueprint, included a customization specification that joins the machine to the domain

   

   vCAC Windows Blueprint Information

   

   vCAC Windows Blueprint Build information

4. Created a Business Group, Created a reservation for them, entitled the Business Group to the service and catalog item for the Windows Server
5. Tested requesting a new machine, it was provisioned, sysprepped and joined the domain correctly. I was annoyed that the computer object was in the “Computers” container.
6. Installed the VMware vCloud Automation Center Designer (found at https://your-vcac-server:5480/i) on the IaaS Server.
7. Installed Active Directory module for Windows PowerShell part of RSAT on the IaaS Server

Steps

1. We’ll need to indicate where we want the Computer Object moved to, so we’ll add that property. Since I wanted all of my Business Group’s computer objects in the same place, I added a property named targetOU to the Business Group and assigned the distinguishedName of the OU.

   

   targetOU property added to Business Group

2. Save the PS script to C:\scripts\movecomputer.ps1
   

   Import-Module ActiveDirectory
write "VM Name - $vmName" | out-file c:\scripts\invoketest.txt
write "Target OU - $targetOU" | out-file c:\scripts\invoketest.txt -Append
Get-ADComputer $vmName | Move-ADObject -TargetPath $targetOU

   This script will write out our variables to a text file, so we can verify that they’re getting passed correctly. Then it performs the move. Please note that this will be executed by the DEM, so make sure the execution account has permissions to perform this action in AD.

3. Launch the vCAC Designer, Load the WFStubMachineProvisioned workflow from the list
   

   

   vCAC Designer Workflows

4. In the “Machine Provisioned” try loop, locate and double-click on the “Custom-Code” item.

   

   Custom Code section in workflow

5. From the toolbox, under DynamicOps.Cdk.Activities, drag the GetMachineName element into the Custom Code box
6. From the toolbox, under DynamicOps.Cdk.Activities, also drag the GetMachineProperty and InvokePowerShell elements into the Custom Code box, near GetMachineName
7. Drag a connection from one of the “tabs” on the Start element to the GetMachineName element, from GetMachineName to GetMachineProperty and from GetMachineProperty to InvokePowerShell

   

   vCAC Designer – Workflow Custom Code Wiring

8. While still in the Custom Code element, click “Variables” (near the bottom), click Create Variable and enter vmName for the name, leave the variable type as String. Repeat with a variable named targetOU. These are going to hold the values we want to work with through the workflow.

   

   Custom Code Variables

9. Select the GetMachineName element. On the Properties pane to the right, enter VirtualMachineId in the MachineId field. In the MachineName field, enter vmName. Ok, so where do these come from?!
   If you click on “Arguments” while in the GetMachineName element, you’ll see two, VirtualMachineId and ExternalWorkflowId. These are standard internal values that are used in these external workflows. So, we’re providing the VirtualMachine Id GUID to the system to look up the Virtual Machine Name. The “vmName” value is the name of the variable we assigned a moment ago and the GetMachineName element enters the retrieved Name into the vmName variable.

   

   GetMachineName Properties

10. Now select the GetMachineProperty element and work with its properties. Just like before, set the MachineId to VirtualMachineId. Here, we want to retrieve the value in the “targetOU” property and set it in the targetOU variable. So set the PropertyValue to targetOU without quotes and the PropertyName to "targetOU" WITH QUOTES.

    

    GetMachineProperty Properties

11. Select the InvokePowerShell element. Notice there are several more properties in with this one – don’t worry, we’re only going to use a few. In my case, I chose to use a PS script instead of a one-liner. This way, I could modify the script without modifying the workflow. So, check the box labelled “IsScript” and set the CommandText to the full path of the PS script in quotes. In this case, use "C:\scripts\movecomputer.ps1".

    

    InvokePowerShell Properties

12. Our script expects two variables to be provided; $vmName and $targetOU, so click the ellipsis beside PowerShellVariables. Click Create Argument to add a new variable. Set the name to vmName, leave the direction as In and the type as String, set the value also to vmName” no quotes. Repeat for targetOU. Here, we’re telling it to create PowerShell Variables and set their values to the values of the workflow. Click Ok

    

    PowerShell Variables

13. Click “Send” to upload the modified workflow to the Model Manager. Now that we’ve created the workflow, we need to make sure it fires when we want it to.
14. Back in vCAC Infrastructure, modify the Windows blueprint by adding a property named ExternalWFStubs.MachineProvisioned. No value needed. This way, when this shared blueprint is used by any Business Group, the computer object will be moved to
    the OU given in the Business Group’s targetOU property.

    

    Property Added to blueprint to call customized workflow

Results
When an entitled member of Business Group 1 requests a VM from the Windows 2008 R2 catalog item, the VM is correctly created as a linked clone, assigned an IP address from the network profile and its Computer Object moved as expected.

I probably should have broken this into multiple parts…

References:
I would still be twiddling my thumbs if it weren’t for the following enormously helpful bloggers:

• 
  Adam Bohle – Working with the InvokePowerShell script activity in vCAC
• 
  Tom O’Rourke – PowerShell Scripting out of vCAC
• Preetam zare – vCAC 6 policies
• Zack Kielich – Extend vCAC workflow to call vCO workflow