Virtually Jason

One of my customers recently asked us to pilot App Volumes for them.  We decided to go with the latest and greatest, and so used App Volumes 3.0 ... and that's turned out to have been a bit of a mistake.  Unfortunately, it appears that the 3.0 release may have been a bit premature, as it has some issues.  Specifically, you can't delete an AppStack once created (without a phone call with VMware technical support)... which is particularly difficult, as there's no way to upgrade an AppStack, instead the work flow is to copy the existing one and modify the copy.  Also, and this may have been an issue that was site specific, but we found that whenever we restarted our Capture machine, our AppStack creation process failed. After a few weeks of wrestling with these issues, we decided to roll back to version 2.10 (ie. reinstall and go back to the older version).  2.10 worked much better for our purposes (we were able to capture applications that required reboots and c...

Well, we all knew that this was coming, but VMware has announced that, as of the next release of vSphere, the C# client will no longer be supported.  So, what can you do if you hate Flash?  Well, there's a bit of good news on that front: VMware is moving to an HTML5 web client, instead of the Flash web client that we currently use.  And, more good news, if you'd like to try it out today, VMware has released an HTML5 Client Fling !  It can't do everything yet, but it can do many of the most common administrative actions and will hopefully see the rapid addition of functionality. Just like all Flings, this is not supported by VMware.  That doesn't mean that using it will cancel your support or something, but it does mean that if you run into issues support is going to ask you to go back to the Flash client.  Since the HTML5 client Fling is available in addition to the Flash client, that should be rather painless. Of course, other management tools (like Po...

One of my customers recently found that their ESXi hosts were not uniformly configured for syslog shipping, so asked me to help them audit their environment.  They have hundreds of ESXi hosts, so going through the advanced settings in the GUI for each of their hundreds of hosts didn't seem like the best approach... PowerCLI to the rescue! In this case, I put together a quick one-liner.  It gets all of the VMHosts, then generates a string in the format of "<ESXi Hostname>,<Configured SysLog Host>".  That string is then parsed by the convertfrom-csv cmdlet, which adds the "VMHost" and "SysLogServer" headers to the line.  That line is then output and the system moves on to the next host in the list.  When the command is completed, the system has generated a nice table with a "VMHost" column that is populated by ESXi hostnames and a "SysLogServer" column that is populated with their configured Syslog servers. Importantly...

One of my customers is planning on upgrading to vSphere 6.  They have many sites and require that each site be able to operate independently, but want them to be centrally managed under normal conditions.  So, they have a great use case for Enhanced Linked Mode! We're exploring different architectures and how to handle various situations.  One of the situations that we wanted to explore very thoroughly was the loss of a vCenter or PSC at one of the sites and how the recovery process might work.  To that end, we've set up three VCSA + PSC pairs in a single SSO domain and have been ripping them apart and generally abusing them. We've come up with a generally good procedure that covers, start to finish, how to decommission a PSC all the way to how to restore a replacement PSC/vCenter to full functionality.  We've come up with this process by combining the steps from a few VMware KB articles, and so I've decided to go ahead and cover it here in a single workflo...

One of my customers recently asked me for some help developing a script to search his Active Directory for user accounts that hadn't been used for more than 90 days.  He had already found that the get-aduser "LastLogon" parameter was domain controller specific, meaning that whichever DC is responding to the request will tell you when it last authenticated that user account.  Of course, since you have multiple DCs (you do, right!?), that isn't guaranteed to give you their actual last logon time. So, we put together a script that will get a list of all active AD accounts from a particular OU, then query each DC (filterable to a given site by DC name, if necessary) for each account's last logged in time.  Whichever DC returns the most recent last logged in date is the winner, and that date is stored.  At the end, the script returns a list of all users who haven't logged in to the network in X days (we used 90 days).  The script returns some basic info about the...

We came across an unexpected situation recently at a customer site that I wanted to briefly discuss.  Typically, when applying ESXi host updates, you're safe to install whatever patches are available for your current version of ESXi.  The December 2015 patch, ESXi550-201512001, as described in this VMware blog entry , does not fall into that category.  You may have heard about the POODLE exploit; this patch updates the openSSL implementation and disables SSL version 3 in order to block that vulnerability. Blocking vulnerabilities is well and good, but this patch requires many vsphere administrators to modify their normal patching workflow.  If you just apply the available ESXi updates, your ESXi hosts will lose their connection to vCenter and enter an unmanaged state.  The proper way to apply this update is to update vCenter first, then apply updates to the ESXi hosts.  That workflow is well understood, when updating ESXi versions (say, from 5.1 to 5.5 o...

One of my customers recently had a host throw a PSOD.  It's a large environment with appropriate spare capacity, so that wasn't a major issue.  I mean, we never want a host to go down, but we designed the environment to accommodate that situation and it largely responded well... except for 2 VMs.  They errored out, with a message saying that "vSphere HA unsuccessfully failed over this virtual machine... ...Reason: An error occured during host configuration".  We found a related event that said, "Operation failed, diagnostics report: Failed to open file /vmfs/volumes/<Datastore UUID>/.dvsData/<DVS UUID>/<Port Number> Status (bad0003)= Not found".  True to the error message, that file was not there. VMware has a KB Article about this issue, but it's related to vSphere 5.0, when Storage vMotion fails to move a file that HA requires for tracking the VM on the Distributed vSwitch.  This customer is on vSphere 5.5 (and has been for a signi...