vRealize Automation (vRA) offers built-in integration with a long list of imaging technologies, such as SCCM, BladeLogic, HP Server Automation, and Citrix Provisioning Server, to name just a few.  But what if you want to integrate vRA with a different imaging technology, that’s not on this list?  Well fortunately, vRA comes with all the extensibility you need to integrate with just about anything.  In this article, I’ll demonstrate the steps needed to integrate vRA with an example imaging technology, Microsoft Deployment Toolkit (MDT).  You can then re-use these steps to build your own integration with other imaging technologies, as needed.

Our Approach To Extending vRealize Automation (vRA)

One of the most powerful aspects of vRA is how it maps its processes for provisioning and managing machines across a sequence of Machine Lifecycle States. This sequence starts at the initial machine request, and ends when the machine is ultimately de-provisioned and destroyed.  And here’s the best part: each state within the sequence can be augmented to call out to additional AUTOMATION, often via workflows and vendor-provided plug-ins within vRealize Orchestrator (vRO).  Below is a graphic that depicts a subset the vRA’s Machine Lifecycle States, specific to the initial VM provisioning process.

The Building Machine and Machine Provisioned states are highlighted in yellow because vRO’s vRealize Automation plug-in includes the ability to easily assign a vRO workflow to augment them.  Here’s how we’ll use them to incorporate third-party imaging into vRA’s Provisioning Process:

Building Machine

1. Create VM.  vRA asks vCenter to create the VM, per the CPU/memory specs in the user’s Request.  For this example, this will just be a shell VM (empty VMDK, with no OS), as opposed to the usual template clone.
2. Attach boot ISO to CD-ROM.  vRA will ask vCenter to mount a boot ISO to the target VM. More on this in a moment…
3. If needed, we can call a vRO workflow to flip the target VM’s Network to an imaging network/VLAN (I’ll cover this in a future blog article).

Machine Provisioned

1. vRO workflow powers on VM.  Now that the VM is created, we’ll call a vRO workflow to facilitate its imaging process.  It will turn the VM on, and then let the mounted ISO boot the VM and connect it to MDT for imaging.
2. If an imaging network/VLAN was used during imaging, then after imaging is complete a vRO workflow can flip the target VM’s network back to its production network/VLAN (future blog article).
3. vRO workflow applies a Customization Specification from vCenter.  This customization will also be the delivery mechanism for any static IP information from a vRA Network Profile or external IPAM integration

Oftentimes with imaging technologies, PXE is used during the initial power-on to provide the target VM with a boot image, which it then loads in order to connect to an imaging server and bring down its OS image.  vRA, however, allows us to attach a boot ISO (mentioned above) from a vSphere datastore, and sidestep any need for PXE in this scenario.  Pretty slick, eh?  The boot ISO only needs DHCP on the network, to get its temporary IP number for connecting to the imaging server.

Other important Requirements:

• Any imaging technology we integrate into vRA must be configured to be 100% automated (i.e. no human interaction needed).
• Any image we deploy must have VMware Tools installed.  When VMware Tools comes online with a status of “Ready” this will signal to vRO that imaging of the target VM has completed successfully, and any subsequent automation can proceed.

MDT Configuration

In my lab, I downloaded MDT 2013 from the MDT landing page to a spare Windows Server 2012 R2 VM.    As a prerequisite, I also downloaded and installed the Windows Assessment and Deployment Kit (ADK) for Windows 8.1 on the same VM.

After installing the ADK and MDT, I followed this TechNet Article to 1) create a Deployment Share and then 2) add my Windows 2012 R2 install ISO.

After my Windows 2012 R2 install image was added, I downloaded the latest VMware Tools for Windows x64.  In MDT’s Deployment Workbench, I right-clicked Applications and then selected “New Application” to import it.  For the install command line, I made sure no human interaction was required, and I suppressed the reboot:

VMware-tools-9.4.12-2627939-x86_64.exe /S /v"/qn REBOOT=R"

Since we don’t want VMware Tools to load before the MDT process is done, I didn’t check the box to reboot after installing.

Next I created a new “Standard Server Task Sequence” and left all the settings default.  I gave it an ID of TS0001.  This Task Sequence comes pre-loaded with the steps that will image the target VM with the vanilla Windows install image, and then install the Applications (VMware Tools).

It’s essential that any imaging technology we integrate with vRA is 100% automated.  In order to configure MDT in my lab to be 100% automated, I configured the Rules tab of the Deployment Share, as well as its Bootstrap.ini.  Side note: the Rules tab is also referred to as CustomSettings.ini.  To configure it, I right-clicked the Deployment Share, and selected Properties.  Then on the Rules tab, I entered the settings below.

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerBackup=YES
SkipBitLocker=YES

TaskSequenceID=TS0001
MandatoryApplications001={60a9a2fd-05cc-45fa-a993-c030e247282d}
SkipComputerName=YES
SkipDomainMembership=YES
SkipLocaleSelection=YES
SkipTaskSequence=YES
SkipTimeZone=YES
SkipApplications=YES
SkipSummary=YES
SkipFinalSummary=YES
FinishAction=REBOOT

The TaskSequenceID refers to the Task Sequence that I created for our Windows 2012 R2 install image.  The “MandatoryAppliaction001” references the Application GUID of the VMware Tools application that I created.  You can find this by going into the properties tab of the the VMware Tools application:

Back on the Rules tab of the Deployment Share, there is an “Edit Bootstap.ini” button at the bottom.  When I clicked it, I was able to edit a text file with information that the Boot ISO will use to connect the target VM to the MDT Deployment Share.  I added the share’s UNC path, connection credentials, and SkipBDDWelcome line, like this:

Lastly, I generated the boot ISO from MDT.  In order to integrate an imaging technology with vRA, it should provide a boot ISO, that the target VM can load in order to connect to the imaging server and automatically apply an OS image.

To generate the boot ISO, I did the following:

1. Right click the deployment share and select Update Deployment Share.  This will, among other things, update the boot ISO to include the modified Bootstrap.ini.
   
2. Find the boot ISO within the Deployment Share.  Mine was here:
   D:\DeploymentShare\Boot\LiteTouchPE_x64.iso
3. In the vSphere Web Client, upload the ISO to a datastore, like this:
   

Now, STOP.  If you’ve been following along in your own lab, then at this point you should have everything in place to test MDT.  Before you proceed with the rest of this article, make sure your MDT imaging process is 100% automated.  From the vSphere Web Client, create a VM.  Attach the boot ISO to its CD-ROM, and power on the VM.  Watch the VM’s console, and you should see it boot to Windows PE, connect to MDT, and start imaging Windows.  When it finishes, you should see it reboot, and then in vCenter you should see that its VMware Tools is running.

Take note of how many minutes this imaging process takes.  We’ll want this information later, when we configure our vRO workflow.

vRealize Automation Blueprint

From this point on, the steps in this article are non-MDT-specific, and apply universally to any imaging technology that can be configured to use a boot ISO to apply an image to a target VM in an automated fashion.

As a prerequisite to creating the vRA Blueprint, we’ll need a Customization Specification in vCenter, for the same version of Windows that we want to image.  If you don’t already have a Customization Specification created, then you can follow this online manual, to create one.  For the Computer Name, be sure to choose “Use the virtual machine name.”

In section “8 Network” of the Customization Specification wizard, you can leave it on the default option “Use standard network settings for the guest operating system, including enabling DHCP on all interfaces.”  We’ll be overriding this via automation later, to set any applicable static IP settings.

Next, let’s create a Blueprint in vRA for our MDT-based Windows 2012 R2 deployment.  On the Build Information tab, select “BasicVmWorkflow” for the Provisioning workflow

On the Properties tab, add the following properties:

Here’s an explanation of each Property:

• Image.ISO.Name is a built-in property that specifies the folder and filename of the boot ISO.  A little later, we’ll also create a corresponding property that specifies the datastore on which it lives.
• ImagingHelpers.CustSpecName is a property I made up to specify the name of the vCenter Customization Specification from vCenter to apply.  We’ll read this property from a vRO workflow a little later.
• VMware.SCSI.Type is a built-in property that specifies the type of SCSI controller for the VM.  For the Windows 2012 R2 OS that MDT provides, I had to use lsilogicsas.
• VMware.VirtualCenter.OperatingSystem is a built-in property that informs vCenter what OS will run within the VM.  For Windows 2012 and Windows 2012 R2 use windows8Server64Guest.  For a complete list of OS types, look in this SDK page.

Go ahead and click OK to save/close the Blueprint.

Now that the Blueprint is finished, let’s use the built-in Image.ISO.Location property to specify the datastore in which the boot ISO lives.  Since it’s likely that each cluster could have a different datastore for ISOs, I like to apply this property to each Compute Resource or Reservation.  In my lab, I applied it at the Compute Resource.

Together, the Image.ISO.Name property in the Blueprint, and this Image.ISO.Location property in the Compute Resource will tell vRA to mount the boot ISO during the “Building Machine” Lifecycle State noted earlier.

Last but not least, there’s a good chance that applying an image will exceed the 30-minute default timeout for external automation in the Machine Provisioned Lifecycle State.  In my (very slow) lab, the MDT imaging process took about 45 minutes, end-to-end.  To be safe, I increased this timeout to 60 minutes.  To do so, edit the ExternalWFStubs.xml file located on your IaaS server, here:
C:\Program Files (x86)\VMware\vCAC\Server\ExternalWorkflows\xmldb

There are multiple sections.  Find the WFStubMachineProvisioned section, and increase its timeout.
PLEASE resist the temptation to enter 00:60:00.  I didn’t, and now I have a little more grey hair to show for it!  Any value greater than 59 will confound vRA and cause Requests to fail with errors like “Request failed: dev-0067 not found, and possibly deleted before provisioning finished.”  Instead, be sure to enter one hour as 01:00:00 (90 minutes would be 01:30:00, etc.).

vRO Workflow

Before we get to the vRO workflows, you’ll need to make sure you’ve already configured the vCenter and vCloud Automation Center plug-ins within vRO.  If you haven’t done this yet, or aren’t sure, here are a couple of blog series from my colleagues that can walk you through it:

• http://www.vmtocloud.com/how-to-extend-vcac-with-vco-part-1-installation/
• http://extendingclouds.com/2013/12/18/vcac-vco-a-marriage-made-in-the-clouds/

Make sure you’ve tested that you can assign a state change workflow to a Blueprint, and that it successfully runs at the proper Lifecycle State.  Once that’s complete, you’re ready to move on.

When we discussed the Building Machine and Machine Provisioned Lifecycle States, above, we noted that Machine Provisioned was going to use vRO workflows to help facilitate the imaging process.  Let’s dive into a little more detail on what our vRO workflow for Machine Provisioned will need to do:

1. Turn the VM on.  Since we applied the custom properties for the boot ISO to the Blueprint and Compute Resource, the ISO will already be attached to the CD-ROM by the time we turn it on.
2. Wait for the imaging process.  The VM will boot, connect to the imaging server (the MDT Deployment Share, in this case), and image itself.  Remember, we configured our MDT Deployment Share and boot ISO so that this process would be 100% automated.  In my lab, I had the workflow go to sleep at this point for 40 minutes.
3. Watch for VMware Tools to report to vCenter that it is running with a status of “Ready.”  This indicates to the workflow that imaging is complete.
4. Turn off the VM.  This is required before vCenter will let us apply a Customization Specification.
5. Disconnect the Boot ISO from the CD-ROM.  Now that the VM has been imaged, we don’t need this attached any more.
6. Get Static IP info from vRA.  If a Network Profile or IPAM integration is being used by vRA to provide a static IP number and IP settings to the VM, these will be stored in vRA’s custom properties for the VM:
   

   VirtualMachine.Network0.Address
   VirtualMachine.Network0.SubnetMask
   VirtualMachine.Network0.Gateway
   VirtualMachine.Network0.PrimaryDns
   VirtualMachine.Network0.SecondaryDns
   VirtualMachine.Network0.PrimaryWins
   VirtualMachine.Network0.SecondaryWins
   VirtualMachine.Network0.DnsSuffix
   VirtualMachine.Network0.DnsSearchSuffix

7. Apply a Customization Specification from vCenter.  Remember, we specified the name of the Customization Specification as one of the custom properties in the Blueprint.  Also, if custom properties for static IP info were found above, these will be inserted into the customization process.
8. Turn the VM on and wait for the Customization Specification to update the guest OS.

I recently posted a collection of vRO workflows to help with various imaging scenarios.  One of the workflows is a wrapper for third party imaging, which performs all 8 of the steps noted above.  Let’s go ahead and download it, and then I’ll show you how to set it up.  Note: I developed and tested this workflow package in vRO 6.0.

1. Download the workflow package from my FlowGrab project.
2. Import the workflow package into your vRO.
   
3. In vRO, click the drop-down to enter Design mode, and then click on the Configurations tab.
   
4. The only Configuration element that we need to setup is Imaging Wrapper. Highlight Imaging Wrapper, click the Attributes tab, and click the Edit button (pencil).  Then choose imagingSleepSecsDefault.  This setting determines how long the workflow goes to sleep while the VM is being imaged.  The default is 20 minutes (1200 seconds). There’s also a 20-minute buffer (while watching for VMware Tools to start up) before the workflow will timeout, but I still like to get this number pretty close. Remember earlier, when we tried out the MDT imaging process, and then took note of how many minutes it took?  Well now we need that number!  Multiply it by 60 to convert it to seconds, and enter it here.  Alternatively, if you want to use this workflow to wrap multiple images or imaging tools with significantly different imaging times, you can also configure this sleep time in a Custom Property within the Blueprint, so that it’s Blueprint-specific.  I’ll show you this in a moment.

You should now have this workflow structure in your vRO.

The workflow we’re interested in for this article is “vRA 3rd Party Imaging Wrapper (Machine Provisioned).”  Let’s go ahead and assign it to the Machine Provisioned Lifecycle State of our Blueprint!  Run the “Assign a state change workflow to a blueprint and its virtual machines” workflow from Library/vCloud Automation Center/Infrastructure Administration/Extensibility.

Back in vRA, edit the Blueprint and take a look at its Properties – we should now see the reference to the workflow we just assigned to Machine Provisioned.

And there it is on the top line: ExternalWFStubs.MachineProvisioned.  I also went ahead and manually added another new property since the first time we looked here: ImagingHelpers.ImagingSleep.  This is the optional property I mentioned that you can use to set the imaging sleep time on a per-Blueprint basis; if present, it overrides the imagingSleepSecsDefault attribute we saw in the Configuration Element earlier.

Now Request It Already!!

That’s it. All our hard work is about to pay off.  Go ahead, you’ve earned it: click that Request button, sit back, and watch the fireworks!

Yup, fireworks.  Ker-Pow!