virtuallyGhetto

vsphere web client

“Shockwave Flash has crashed” workaround for vSphere Web (Flash) Client

by 80 Comments

On Saturday, I started to notice that logins to the vSphere Web (Flex) Client stopped working with Google Chrome. Upon a successful logon, it would immediately crash with “Shockwave Flash has crashed” message. I had seen this message plenty of times in the past and usually restarting Chrome would resolve the problem but this time it looked to be persistent even after a system reboot.

I took to Twitter to see if I was the only one hitting this issue since I was not able to find anything on the web and literally in minutes, I had several dozen replies with folks experiencing the same issue which apparently started several days ago but like most, including myself, thought it was an isolated event.

After a bit of back/fourth and a few other folks chiming in, it looks like Google actually went and published a newer version of Flash (27.0.0.170) with latest Chrome (61.0.3163.100) update. This newer Flash version is not even available for download and the current version as listed on Adobe’s website should be 27.0.0.159. This issue not only affects VMware products that uses Flash but any website that has Flash content and I had also noticed few others sharing frustrations on Twitter for other flash-based websites.

Luckily, one workaround that I had found which others have also confirmed is to switch to Firefox which currently does not have this issue Its also been reported that latest updates from Firefox is also distributing the latest Flash which causes the exact same issue. Like most, Chrome is my default browser and it was annoying that I had to switch to another browser but that was the only way I could access the content I needed. Earlier this evening, I was looking at the VMware Reddit Channel and noticed a thread had popped up regarding this exact issue and it looks like more and more folks are now noticing.

[Read more…] about “Shockwave Flash has crashed” workaround for vSphere Web (Flash) Client

VMworld Hackathon vSphere Client Login UI Theme

by 7 Comments

For those of you who attended this years VMworld Hackathon (US/Europe), you may have noticed something different when logging into the vSphere Web/H5 Client? In case you missed it or could not attend, here is a GIF demonstrating what you would have saw:

via GIPHY

No, the VMworld Hackathon environment was not hacked 😉 but instead I had built a very special VMworld Hackathon vSphere Client Login UI Theme for the event. I was also getting tired of looking at our boring blue login screen. Customizing the vSphere Client Login UI has been possible (though not officially supported by VMware) since vSphere 6.0 which I have written about here, here and most recently here (due to vSphere 6.5 Update 1 changes). Having received a large number of requests from folks who attended the Hackathon as well as folks who had heard or saw the customization who wish to replicate this in their own environment, I have posted the instructions below.

This slick customization would not have been possible without the help from Timo Sugliani (thanks dude!) who was the one that made me aware of the two of the creatives that then gave me the idea to combine them into a vSphere Client Login UI Theme. The first is V for Vendetta image which can be found here and the second is super slick interactive Bootstrap animation which can be found here. Lastly, I added my own touch by using a Mr. Robot font from this site here which goes really well with the overall theme.

[Read more…] about VMworld Hackathon vSphere Client Login UI Theme

vSphere Client Login UI customizations do not persist in VCSA 6.5 Update 1

by 3 Comments

The much anticipated release of vSphere 6.5 Update 1 just GA’ed late last week and like many in the community, I also went ahead and upgraded my home lab to this latest release. vSphere 6.5 Update 1 contains a ton of fixes as well as several new capabilities which you can read all about in the release notes here and here.

One neat little trick I take advantage of in my lab environments when deploying the vCenter Server Appliance (VCSA) is actually pre-filling out the credentials for the vSphere Client UI (not recommended for production environments of course) which I had blogged about here a few years back. Sine I have many different environments for different scenarios, I find myself being lazy and having to type in the credentials to each one of these environments. Instead, I can pre-fill either the username and/or password (which I will stress again, not recommended for production) within the vSphere Client Login UI page which is simply just using HTML.


After making the necessary changes to my VCSA 6.5u1 system, I needed to reboot my ESXi host and when everything came back up, I was surprised to find my changes to the vSphere Client Login UI had disappeared. It took me awhile to figure out why the changes were not persisting across reboots. There seems to be a change in behavior compared to prior releases of the VCSA (6.0 & 6.5) on when this capability was actually possible.

[Read more…] about vSphere Client Login UI customizations do not persist in VCSA 6.5 Update 1

PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup

by 10 Comments

I can still remember when I was a VI Admin and how annoying it was to try to correlate the build numbers for my ESX(i) hosts and vCenter Servers that I have deployed with the versions listed on VMware’s website. This especially gets challenging when there are multiple patch releases (a, b, c or 01, 02, 03) in between major releases (5.5, 6.0, 6.0u1, 6.0u2, 6.5, etc.). Historically, most customers including myself would retrieve the respective build numbers and then manually comparing them to either the release notes and/or download website which was very tedious.

Although VMware has exposed the version number within our vSphere products since day 1 which can also be retrieved programmatically using the vSphere API (here), it unfortunately does not provide more details than simply the major/minor version (e.g. 5,5, 6.0, 6.5, etc) of the software. Recently, VMware had released a series of VMware KBs which provides a mapping between the build numbers for vCenter Server, ESXi and vSAN to their respective versions which can be found in the links below:

These are definitely a great set of resources that I know many customers including myself have been using since its release. Having said that, the process today is still pretty manual since you need to manually retrieve the build numbers for either a VC, ESXi or vSAN Host (can be automated using vSphere APIs) and then comparing that to the KBs to get the correct versions. How cool would it be if you could *easily* just point to YOUR environment and retrieve the version information for either a vCenter Server (Windows or VCSA), ESXi host(s) or vSAN host(s) without needing to manually perform this lookup each time? Well, I have just done that! I have taken all three KBs and converted that information into a simple PowerCLI script called VCESXivSANBuildVersion.ps1 leveraging our vSphere API and it provides three functions:

  • Get-VCVersion – Retrieves the vCenter Server version given a VC connection
  • Get-ESXiVersion – Retrieves the ESXi version for all hosts given a vSphere Cluster
  • Get-VSANVersion – Retrieves the vSAN version for all hosts given a vSAN Cluster

Here is an example output using the first two functions:


For the vCenter Server version output, you will notice that I am also including the OS platform of your vCenter Server, so you can distinguish between a Windows vCenter Server and a vCenter Server Appliance (VCSA) which can be useful to see if you have been #migrate2vcsa ;). For the ESXi version output, you will notice the “OriginalInstallDate” value, this is actually new API property that was introduced in vSphere 6.5 and it provides you with the original installation date of your ESXi host (more details can be found here) which is pretty neat.

Here is an example output using last function:


If you wanted to take this a step further, you could even take this output and dynamically update the vSphere UI using either Custom Attributes or vSphere Tags so you know what version the software is at any given moment. Its easy enough to set this up as a scheduled task that could run periodically so you always have the latest information provided in the vSphere UIs.

Although this is a significant improvement over the existing manual methods, I think most of you will agree that it would be ideal if this information was natively available within the product which means BOTH UI and APIs. I think we all appreciate versioning of software is not always easy and it can change from release to release for a variety of reasons, most of which may not be technical. If the vSphere platform could dynamically pull this information in either real time and/or through an offline mechanism and provide this association by default, it would greatly improve the experience when needing to troubleshoot or perform maintenance of the vSphere platform. If this is something you would like to see, please leave a comment below providing your feedback. I know I have already pinged our PMs about this and I am sure they would love to hear form you as well!

Additional Information:

Note1: Update levels can be found using the vSphere API, take a look at this article here for more details.

Note2: As of ESXi 6.5 Update 1, the Update levels are also included by default in the Embedded Host Client as shown in the screenshot below:

Note3: As of vSAN 6.2, the vSAN Management API already includes vSAN version information that can be queried. Take a look at this script here which exercises this new API. For example above, I decided to not use this new API since customers may be running older releases of vSAN which is not covered by the vSAN Mgmt API.

Note4: VMware has also published simliar build to version mapping for other VMware products which can find the complete list here.

Configure vRealize Automation to use Platform Services Controller as External Identity Provider

by 2 Comments

I was doing some research on an inquiry that I had received from a customer who was interested in configuring their vRealize Automation (vRA) instance to use vCenter’s Platform Services Controller (PSC) as an External Identity Provider (IDP) rather than the default VMware Identity Manager (vIDM) which vRA supports natively out of the box. vIDM already supports a large number of websso applications as seen here and it itself can also be used as an External IDP to integrate with things like Active Directory Federation Services (ADFS) for example.

For some customers who are more familiar with the PSC, this is a convenient way to unify their authentication between the different vRealize products which support vIDM and integrating that directly with PSC. Since both solutions spoke SAML, it was merely figuring out process on setting up the External IDP using the PSC. In reading some of our internal Wikis and working with one of the vIDM Engineers, since I was stuck on a particular step, I was able to finally get this to work which I have outlined the steps below. I also learned that we had officially supported this since vRA 7.0 which was great to hear as well.

I know there are number of customers who would also like to see the reverse of this configuration, where PSC can use vIDM as an External IDP. I know this is something the PSC team is currently looking into for External IDP support. If this is something that you are interested in or would like to see specific External IDP setup/configuration, feel free to leave a comment.

Pre-Requisite: 

  • Join Platform Services Controller (PSC) to Active Directory (instructions here & here)
  • Join vRealize Automation (vRA) Appliance to Active Directory (instructions here)

In my lab environment, I have deployed an Embedded VCSA 6.5 (this also works with an External PSC) and vRealize Automation 7.2 (this was prior to 7.3 getting released but should work as well).

[Read more…] about Configure vRealize Automation to use Platform Services Controller as External Identity Provider

vSphere 6.5b prevents vSphere Web Client logins for users w/o VC permissions

by 8 Comments

A patch update was just released for vCenter Server 6.5, dubbed vSphere 6.5b. While glancing through the release notes, I caught one interesting “resolved issue” which I thought was worth sharing.

Users with no vCenter Server permissions can log in to the vSphere Web Client

Users without permissions can log in to the vSphere Web Client. Users can click the menu options, but no inventory is displayed.

Users with no permissions can no longer log in to the vSphere Web Client.

To enable the login, set the allow.user.without.permissions.login = true property in the webclient.properties file.

This particular behavior has been something that has confused a few customers and has been asked about since the introduction of vCenter Single Sign-On (SSO) service. The issue or rather the confusion is that prior to the SSO service, vCenter Server handled both authentication as well as authorization.

With SSO, authentication was no longer being handled by vCenter Server and this meant that even if you had no permissions in vCenter Server but you could authenticate to SSO (especially common when Active Directory is configured), you would still be allowed to login to the vSphere Web/H5 Client.


Although vCenter Server would does the right thing and does not display any inventory if you do not have any permissions, it was still not a desired behavior in addition to the confusion it caused. I was pleasantly surprised to see that we have changed this default behavior by disallowing logins to the vSphere Web/H5 Client if a user has no VC permissions. Below is the message you will receive if you try to login without VC permissions.


If you wish to revert to the original behavior, you can do so by simply adding the allow.user.without.permissions.login = true setting into the vSphere Web/H5 Client configuration file (webclient.properties) and restart the vSphere Web/H5 Client service. I think many of our customers will appreciate this fix as well as the new default behavior!