Virtually Jason

In this post, I'm going to discuss the details of the second 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 !  If you want to read about the first half of the workflow, check out Part 2 ! The bulk of the work for this workflow happens in the "Download then Install Windows Updates until there are no more to install" section.  By the time the workflow has hit this section, it has a powered on VM that has Windows Updates enabled and all of the necessary scripts in place.  This section begins by executing the Download script.  This workflow step completes almost immediately, even though the script will take several minutes to complete, so it goes into a sleep (as Windows Updates can a while to download everything).  The final step of that script is to create a flag file - it either generates a "Done" file if there are no more updates to do...

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...

Jeff and I have been doing a lot of work with Orchestrator lately.  It's been a bit of an uphill struggle, but we've managed to create a few cool things!  This one is very simple, but it addresses a common pain point and so we're sharing it.  We've generated an Orchestrator workflow that automatically applies Windows Updates to templates. Admittedly, that's not a very difficult process to go through by hand... but it's arduous and needs to be done regularly... and, truth be told, it seems like most people just don't bother.  So, we decided to automate it!  It turns out that automating it was actually a fairly interesting process, as we had to deal with a lot of decisions that are very easy for a human to make but are not so straight-forward for a machine.  I'm going to try my hand at a 3 part series of posts, detailing this workflow. So, what does this Workflow look like?  Here you go: As you can see, the workflow has 4 major parts. ...

We've been working with Orchestrator recently and came across a subtle incompatibility issue.  Our vCenter is currently version 5.5, update 2.  We came across an authentication issue and one of the more popular work arounds on the forums was to upgrade Orchestrator to version 6.  We did a quick compatibility check on the good old VMware Interoperability Matrix and found that Orchestrator 6 has no problems with the vCenter 5 family, so we went ahead with the plan. We applied the update and everything seemed to be working just fine for several months.  We decided that we're happy with how Orchestrator is working and so want to roll it out to several of the other vCenter servers in the environment... and that's when we ran into a problem. We had some difficulty adding the second vCenter to the system, so we went ahead and removed the first one and then re-added them both.  They added just fine, so I logged into the Web Client to kick off a test workflow......