Updating VM Templates with vRealize Orchestrator, Part 2
In this post, I'm going to discuss the details of the first half of the Windows Template Update workflow that we created in vRealize Orchestrator. If you want to read an overview of the script, please check out Part 1!
There are two major sections before Windows Updates can actually be applied. The first section ensures that the workflow has a powered on VM that is ready to be manipulated and the second section creates and transfers necessary resources to that VM. How do they work?
The Get Powered On VM section begins by checking if the supplied VM is a template or not. If it is a template, it converts it to a VM and then waits 30 seconds before powering it on. I included that sleep command because there is a note on the "Mark as VM" workflow that it can potentially complete before vCenter updates the VM's status, which can cause problems. The "Start VM" workflow waits for VMTools to start; I went ahead and put a 30 second sleep in after that as well, just to ensure that the OS would be fully booted before the workflow moves on. If the supplied VM is not a template, it checks the VM's power state. If it is off, it turns it on and waits 30 seconds. If the VM is already on, it moves forward to the next section.
The next section is the "Prepare for Updates" section of the workflow. This section begins by generating and uploading four Powershell scripts onto the VM (in its C:\Windows\Temp directory): Enable.ps1, Download.ps1, Apply.ps1, and Disable.ps1. These four scripts are all stored as parameters in the workflow, until the workflow generates and uploads the script files. Enable.ps1 simply turns on automatic Windows Updates on the VM, through the registry. Download.ps1 is the first half of Greg Shields' Windows Update script. Apply.ps1 is the second half of that same script. Disable.ps1 simply disables automatic windows updates (once again, by the registry).
After the necessary script files are uploaded, the workflow does a small cleanup pass. During the execution of the workflow, it creates several temporary flag files that Orchestrator uses to determine if it should move forward or not at key points. I wanted this workflow to function if it was interrupted at some point during a previous run and so it simply deletes any of those flag files that might exist from a prior failed execution. You'll notice that the lines proceeding from those three "Delete X" steps are all red and blue; that means that Orchestrator will proceed to the next step regardless of success or failure of each "Delete X" step (they will usually fail, as the files won't exist to be deleted). The final preparatory step is to execute the Enable.ps1 script so that the VM is ready to run its Windows Updates.
In the next post, I'll cover the process that the workflow uses to actually download and apply the Windows Updates.
Download the Update Templates Orchestrator Package
*This package is provided for educational purposes only and is not guaranteed to work in any environment. Make sure that you carefully understand any code that you find on the internet and test it thoroughly before executing it in your environment.
Part 1: Update Templates Workflow Overview
Part 3: Update Templates Workflow Execution/Cleanup Phases
There are two major sections before Windows Updates can actually be applied. The first section ensures that the workflow has a powered on VM that is ready to be manipulated and the second section creates and transfers necessary resources to that VM. How do they work?
The Get Powered On VM section begins by checking if the supplied VM is a template or not. If it is a template, it converts it to a VM and then waits 30 seconds before powering it on. I included that sleep command because there is a note on the "Mark as VM" workflow that it can potentially complete before vCenter updates the VM's status, which can cause problems. The "Start VM" workflow waits for VMTools to start; I went ahead and put a 30 second sleep in after that as well, just to ensure that the OS would be fully booted before the workflow moves on. If the supplied VM is not a template, it checks the VM's power state. If it is off, it turns it on and waits 30 seconds. If the VM is already on, it moves forward to the next section.
The next section is the "Prepare for Updates" section of the workflow. This section begins by generating and uploading four Powershell scripts onto the VM (in its C:\Windows\Temp directory): Enable.ps1, Download.ps1, Apply.ps1, and Disable.ps1. These four scripts are all stored as parameters in the workflow, until the workflow generates and uploads the script files. Enable.ps1 simply turns on automatic Windows Updates on the VM, through the registry. Download.ps1 is the first half of Greg Shields' Windows Update script. Apply.ps1 is the second half of that same script. Disable.ps1 simply disables automatic windows updates (once again, by the registry).
After the necessary script files are uploaded, the workflow does a small cleanup pass. During the execution of the workflow, it creates several temporary flag files that Orchestrator uses to determine if it should move forward or not at key points. I wanted this workflow to function if it was interrupted at some point during a previous run and so it simply deletes any of those flag files that might exist from a prior failed execution. You'll notice that the lines proceeding from those three "Delete X" steps are all red and blue; that means that Orchestrator will proceed to the next step regardless of success or failure of each "Delete X" step (they will usually fail, as the files won't exist to be deleted). The final preparatory step is to execute the Enable.ps1 script so that the VM is ready to run its Windows Updates.
In the next post, I'll cover the process that the workflow uses to actually download and apply the Windows Updates.
Download the Update Templates Orchestrator Package
*This package is provided for educational purposes only and is not guaranteed to work in any environment. Make sure that you carefully understand any code that you find on the internet and test it thoroughly before executing it in your environment.
Part 1: Update Templates Workflow Overview
Part 3: Update Templates Workflow Execution/Cleanup Phases
Hi Jason, the script downloads and installs all WU right? Critical and not...
ReplyDeleteYes, that's managed by the PowerShell script that Orchestrator launches in the VM.
DeleteHow did you check if the supplied VM is a template or not?
ReplyDeleteI was wondering the same thing.
DeleteHey guys - sorry, but I don't have access to an orchestrator environment to fire this up and look at it (and it was sufficiently long ago that I don't remember exactly how we solved that), but if you download the package you should be able open up that step and see how we handled it. I vaguely recall it as being a built in function, but that could certainly be wrong.
DeleteI found it after submitting that post. It's VcVirtualMachine.config.template (boolean).
Delete