Virtually Jason

One of my customers has to an application with strict concurrency limits in its licensing.  Historically, they've worked around those concurrency limits by having a limited number of workstations from which to launch that application.  When a user needed it, they would just go to one of those workstations and do their work.  This created a serious pain point though, as users would frequently lock the workstation rather than log out of it, leaving their coworkers with one fewer workstation at that location (there are far more users then computers at these locations). VDI allows us to very easily work around that later problem, as each user can now get their own desktop.  The location is still limited by the number of terminals that it has, however a user can now simply restart the terminal in order to connect to their own desktop without causing their coworker to lose any work.  This flexibility has introduced the pain from this particular applications concurrency limits, though.

One of my customers recently had a major issue; due to a fault in their cooling system, their server room overheated and many devices turned themselves off in order to avoid damage... including one of their SANs.  After resolving the cooling issue, the environment largely came back up without serious incident, however there was one lingering problem. Several VMs in the environment could not connect to their distributed virtual switch.  Each VM was associated with its port group correctly, however the "connected" checkbox was cleared.  When we tried enabling that option, the task failed with an error that read: Invalid Configuration for Device '0' Some quick googling revealed a VMware KB Article about this particular issue, with several different workarounds suggested.  They ranged from easy (move the VM to a different Port Group and back) to arduous and time consuming (remove the NIC from the VM, then add a new NIC and reassign its network identity to the new NIC

One of my customers offers a hosting solution.  One of their larger customers came to them with a request recently - they wanted a 5 second boot delay on all of their VMs.  This customer had previously run all of their VMs in their own vCenter and needed a way to get access to the VMs' BIOS settings now that they had the vCloud Director subset of actions.  A boot delay was deemed the best solution.  This presented another excellent scripting opportunity - a very simple task that needed to be repeated hundreds of times. My customer was understandably hesitant to let a script just run rampant through their vCenter, and so I put together the following.  It only targets VMs in the named Resource Pool and can be further filtered by passing it a VM's name (or part of a name) with the -VM parameter.  After that, it loops through the list of all returned VMs and checks their boot delay setting.  If the VM doesn't have the correct Boot Delay, the script prompts the user and change