Virtually Jason

I’ve had the chance to work with vRealize Orchestrator recently.  It’s got a bit of a learning curve, but we’re making good progress and are managing to automate some of those basic tasks that just seem to eat up time otherwise.  One of the challenges that we’ve come across is related to running PowerShell commands in the Guest OS itself (this is different than the PowerShell integration, which is a whole different ball of wax) via VMTools.  We ended up trying a bunch of different techniques, with various drawbacks and advantages. The first thing that we tried was the “Run program in guest” workflow under vCenter -> Guest Operations -> Processes.  When you launch that workflow, you’ll need to provide several pieces of data: which VM you want to execute the application in, the credentials for that VM, the path to the program and any arguments that the program will need (as well as a few others that we didn’t use in this situation).  The VM and credentials part is self explanator

One of my customers recently encountered an interesting problem.  They encountered an issue that caused their Unidesk desktop backups to fail to delete from the archive datastore.  As such, that datastore filled up and backups were unable to continue.  The customer was working directly with Unidesk and VMware to resolve the issue, but in the meantime needed an easy way to purge all of the stale backups from their system. A few months ago, I posted about setting up Persistent ESXi Scratch Space for hosts using SD cards for their installations.  In that post, we covered how to mount a VMFS volume into a PowerCLI session.  Once it's mounted, we created the per-host Scratch folders, but that same technique can be easily used here to help us find those stale backups.  First, we ran this command to mount the "VDI-Archive1" datastore as a drive named DS: New-PSDrive -Name "DS" -Root \ -PSProvider VimDatastore -Datastore (get-datastore VDI-Archive1) Next, we had

One of my customers is migrating a lot of ESXi hosts (with a strong naming convention) from one network onto a new network with a pre-defined IP Addressing scheme based around fully populated HP C7000 blade enclosures (containing 16 blades).  The host naming convention is <Site>-<Enclosure ID>-ESX<Blade Slot Number>.<FQDN>.  Based on this, I've been tasked with automating as much of this migration as possible, and part of that is automatically assigning the new IP Addresses to the blades. In order to do this, I'm using the new-vmhostnetworkadapter cmdlet.  That cmdlet will need several parameters in order to work: -virtualswitch -portgroup -IP -subnetmask Most of these are trivial, as they will be constant for every host in the environment.  The big exception to that statement is the IP address parameter.  As I said earlier though, due to the strong naming convention at this site we can derive the host's new IP address entirely from informat