WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

vSphere UI Client Plugin named N/A after vSphere 8 upgrade

11.21.2022 by William Lam // 16 Comments

This past weekend I finally got a chance to upgrade my personal homelab to vSphere 8, which went super smooth! As shared on Twitter and Mastadon, I started with my VCSA which was running vSphere 7.0 Update 3h and once that had completed and running for a couple of days, I then upgraded my single ESXi host which was running 7.0 Update 3g which runs on Supermicro E200-8D.

just successfully upgraded Supermicro E200-8D from 7.0u3g to ESXi 8.0, though I had to add HW flag as CPU may not be supported in future

ESXI_VERSION=ESXi-8.0.0-20513097-standard
esxcli software profile update -d https://t.co/cs4yUyvnxQ -p ${ESXI_VERSION} --no-hardware-warning pic.twitter.com/hnEspuEDpE

— William Lam (@lamw.bsky.social | @*protected email*) (@lamw) November 20, 2022

After was functional after the upgrade, including the VMware Event Broker Appliance (VEBA) UI Plugin 😀

This morning, I happened to navigate over to the vSphere UI Client Plugin screen under Administration->Solutions->Client Plugins and I noticed I had one plugin named "N/A" and was was showing incompatible.


I was not sure what the plugin was and raised this internally with the vSphere UI team on whether this was expected and if there was something I needed to do. It turns out this was the default vCloud Availability plugin for vCloud Director that ships with a vCenter Server deployment and it uses the deprecated local plugin architecture and this particular version of plugin is no longer applicable or compatible with vSphere 8.

[Read more...]

Categories // ESXi, vSphere 8.0 Tags // vSphere 8.0, vsphere client

An update on how to retrieve useful information from a vSphere login?

11.07.2016 by William Lam // 4 Comments

There was an internal Socialcast question today in which the answer could be found in my how to identify the origin of a vSphere login article. After responding to the question, I had realized that I wrote that article almost 6 years ago and what is even more crazy is that it is still very applicable today. The article explains how you can identify a vSphere login by enabling the "trivial" logging option in vCenter Server (extremely verbose, so please use with caution). Once enabled, you can go through the vpxd.log file and find things about a user login such as the the IP Address of the client as well as the type of vSphere interface they had used to login to whether that is using the vSphere C# Client or PowerCLI for example. Although this extracted information can be very useful, the process to retrieve this is not very ideal, especially having to increase your vCenter Server logging verbosity to the extreme which can force other more critical log events to roll over.

Given that this article written back when vSphere 4.1 was still the current release, I figure I should give the process another look to see if there was a better method in retrieving this information. While quickly browsing around the SessionManager object and specifically the UserSession property, I noticed there have been quite a few enhancements that were introduced in vSphere 5.1. It looks like you can now easily retrieve things like the User Agent, IP Address of the client as well as the number of API invocations for anyone who is currently logged into a given vSphere environment. Perhaps someone internally saw my blog post and thought it would be useful to add these properties directly into the vSphere API rather than poking around in the verbose logs 😀

To exercise these new vSphere APIs, I have create a quick PowerCLI function called Get-vSphereLogins The script will iterate through all currently logged in vSphere sessions and provide the following output: Username, IP Address, API Count & Login Time. It also excludes the current session initiating the query as well as any of the VC Extension logins. Here is a screenshot of my environment using several different vSphere API interfaces to login to my vSphere environment:

retreiving-useful-information-about-vsphere-login-0
With the information above, not only can you tell who is logging in but also where (IP Address) and most importantly how (User Agent) they are logging in. One thing to be aware of is that the User Agent is not always populated and even if it is, it may not provide you with enough information on the specific interface a given user is logging in from. For example, it looks like a script written using the vSphere SDK for Python does not actually set the User Agent, so it is empty.

Here is an updated table using some of the latest vSphere interfaces to log into a vSphere 6.0 Update 2 environment and their respective observed User Agents:

Interface User Agent
vSphere C# Client VMware vSphere Client/6.0.0
vSphere Web Client VMware vim-java 1.0
vSphere MOB Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML like Gecko) Chrome/54.0.2840.71 Safari/537.36
PowerCLI PowerCLI/6.5.0
vSphere SDK for Perl VI Perl
vSphere SDK for Ruby (rbvmomi) Ruby
vSphere SDK for Python (pyvmomi) None

Note: In vSphere 6.5, the User Agent that is returned for the vSphere Web Client session looks to be using web-client/6.5.0

Finally, saving the best for last. The VMware Engineer(s) not only added these new properties into the vSphere API, but they have also made them readily available using the vSphere Web Client. To view all the session information, navigate to your vCenter Server instance and under Manage->Sessions you can get the exact same view as using the vSphere API. By default, the IP Address, User Agent & API Invocations are hidden by default. You just need to right click on the table header and add those additional field as shown in the screenshot below.

retreiving-useful-information-about-vsphere-login-1
Longer term, it would be great to see that each of the "official" VMware CLI/SDKs as well as other interfaces can uniquely identify themselves with a well defined string. This not only helps with understanding the types of tools customers are using but also helps with any types of internal audits customers may require. If you think this would be useful to have, please feel free to leave a comment or any other things you feel would be useful to include.

Categories // Automation, vSphere Web Client Tags // PowerCLI, pyVmomi, rbvmomi, session, user agent, vSphere API, vsphere client, vSphere MOB, vSphere SDK, vsphere sdk for perl, vsphere web client

You no longer can install vSphere C# Client on Windows Domain Controller in vSphere 5.5

09.25.2013 by William Lam // 2 Comments

In the last couple of days I have noticed several folks comment on a new check that has been put in place in vSphere 5.5 which prevents a user from installing the vSphere C# Client onto a Windows Domain Controller system. If you try to install the vSphere C# Client on a Domain Controller system, you will get the following error message:

It is generally not recommended to install additional software on a Windows Domain Controller and I suspect this check was put in place to deter users from installing additional software, including VMware software onto a Domain Controller system. However, for a development environment or home lab, you may want to consolidate multiple applications onto a single system and help reduce the number of Windows systems that you may need to deploy. Luckily there is a way to by-pass this check and I am actually glad one exists as this is something I will need while building out some of internal labs.

Disclaimer: This is not officially supported by VMware, please use at your own risk.

To by-pass the check, you will need to launch the vSphere C# Client install from the command-line and pass in the following arguments:

VMware-viclient.exe /v "SKIP_OS_CHECKS=1"

Now the installer should allow you to proceed with the vSphere C# Client installation.

Categories // Uncategorized Tags // domain controller, vSphere 5.5, vsphere C# client, vsphere client

  • 1
  • 2
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...