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:

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.

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.

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.

Blocking vSphere C# Client Logins

12/10/2012 by William Lam 5 Comments

I recently picked up on this neat little tidbit from Mr. Not Supported aka Randy Keener, where you can block a user from logging into the vCenter Server using the vSphere C# Client. Other than playing a prank on your co-workers, you might be wondering is there a use case for this? Surprisingly, this is a request I have heard from a few customers in the past where they would like to block their users from using the vSphere C# Client in favor of leveraging only the vSphere APIs for routine tasks.

Since the vSphere C# Client also uses the vSphere API itself, a user with proper credentials to the vSphere environment can easily download the client from an alternative source and still login. Of course, there are ways of preventing this such as restricting application installation on end users desktop but there is some amount of management overhead of identifying those existing and new users, especially if access is delegated out to other teams.

There is a very simple solution if you choose to block ALL users from using the vSphere C# Client which requires a tiny modification on the vCenter Server itself and it takes effect immediately with no service restarts.

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

Windows: C:\ProgramData\VMware\VMware VirtualCenter\docRoot\client
VCSA: /etc/vmware-vpx/docRoot/client

There is parameter called exactVersion which will be set to current supported version of the vSphere C# Client which should also match the version of your vCenter Server. You just need to change this to some other value that you know will not exist in your environment such as 9.0.0. Once you have made this change, now when a user tries to connect and there is a miss-match in the version, the vCenter Server will provide you with a download to the vSphere C# Client located on the server as it normally would if you did not have the latest client.

What the user will find out shortly, is that this will continue in an infinite loop even after installing the proper vSphere C# Client. The reason for this is that the number in version.txt will never match the vSphere C# Client and vCenter Server will just continue serving the installer in an infinite loop. I also looked into this trick for a standalone ESXi host and you can do the same by editing a file called clients.xml which is located in /usr/lib/vmware/hostd/docroot/client and users will not be able to login to the ESXi host using the vSphere C# Client.

Now, even though this prevents users from logging into the vSphere C# Client, users will still be able to connect using the vSphere API which includes the use of vCLI/ESXCLI, PowerCLI, vCO, SDKs, etc. and the use of the vSphere Web Client for either vSphere 5.0 or 5.1 will continue to work. Ideally, it would be nice to be able to control this access on a per user/group basis and perhaps even specify how a user can connect whether that is through the use of the APIs or UI only. Is this even useful to have at all? Would love to hear your comments.

For now, if you want users to get familiar with the new vSphere Web Client 5.1 ... this is one way of "encouraging" them 😉

How to unregister vCenter plugin/extension using the MOB

07/09/2010 by William Lam 19 Comments

I saw a post on the VMTN forums the other day about unregistering a vCenter plugin. The user had a bad installation of an early preview of NetApp's VSC utility. After uninstalling the plugin, the user was still unable to unlink the plugin from vCenter. There is actually a pretty simple solution to this problem which can be accomplished by using the vSphere MOB.

Here are the instructions to remove a specific plugin/extension from your vCenter server:

1. Point your web browser to your vCenter server: https://your_vc_server/mob and login.

2. Click on content:

3. Locate and click on ExtensionManager:

4. Click on the plugin you are interested in removing:

5. Record the plugin key id which will be used to remove the plugin:

6. Now, go back to previous page and at the bottom click on the function "UnregisterExtension". A new window will open and ask for the plugin key id which was recorded from above. Enter the key and click on the "Invoke Method" to remove the plugin

You can now refresh the page and you will see that the plugin is no longer available. You can restart your vSphere Client to see that the plugin has now been removed.

The following operation can also be performed using a script, here is a vSphere SDK for Perl script that does just that: pluginExtensionManager.pl