Goodbye vCenter Server for Windows and Flash-based vSphere web client!

Hmm…. it’s not even VMworld yet and VMware decide to make 2 big-ish announcements.

Although tbh, since vSphere 6.5 was released these 2 announcements have long been coming!

Finally, after loads of speculation, VMware had announced that vCenter Server for Windows and the Flash-based vSphere web client is to be deprecated with the launch of the next version of vSphere. Updates to 6.5 will continue supporting the 2 features, but come vSphere 7.0 it will be no more….


“vCSA-exclusive capabilities such as file-based backup and restore, unified update and patching, native vCenter High Availability, and a significant performance advantage mean that the VCSA has become the platform of choice for vCenter Server.  Additionally, due to the integrated nature of appliance packaging, VMware is able to both better optimize and innovate vCenter Server at an accelerated pace.  Finally, with the VCSA, VMware can provide support for the entire vCenter Server stack including the vCenter Server application, the underlying operating system (Photon OS), and the database (vPostgres). By doing so, VMware can ensure that customers can focus on what matters most while having a single source for updates, security patches, and support.  The VCSA model is simply a better model for vCenter Server deployment and lifecycle management.”

That pretty much sums up why VMware are 100% behind the vCSA, although they miss out the whole “screw you Microsoft licensing!!” part! Plus given that 6.5 ships with a migration tool that helps you move/upgrade from a Windows vCenter to an Appliance vCenter, it’s no surprised that more and more people are moving over when it comes round to upgrade time!

In fact ever since 6.5 was released, I’ve not even deployed a single Windows vCenter Server – all my customers have been moved over to the vCSA.

With regards to the vSphere Web Client, loads of people found the flash-based version was frustratingly difficult to use – it was slow, it was notoriously prone to crashing and frankly it was based on in-secure Flash technology (not to mention that Adobe themselves are dropping flash). HTML5 is the way to go baby!

So with those announcements in mind….. I may think about changing some of my VMworld sessions to jump on the vCSA and Web Client update sessions!!




Cannot connect to vCenter Server via vSphere Client – timeout

I’ve been upgrading my company’s solution centre to vSphere/vCenter 6.0 update 2 the past week and noticed that I was having issues logging into the vCenter Server Appliances I had deployed.

It was a strange issue because I could log into the Windows vCenter Server I had deployed in my primary cluster, but couldn’t log into the vCenter Server Appliance I had deployed in my secondary cluster….. hmmm…. Web Client worked fine for both, but it was the vSphere C# client that was timing out for the vCSA!


After much head scratching and trawlling through logs (Found at C:\Users\username\AppData\Local\VMware\vpx\viclient-x-0000.log), it turns out the problem is with the default time out value of the vSphere client for authentication.

The default timeout value is 30 seconds, and my suspicion is that the vCSA was taking slightly longer to respond to authentication…. changed the value to 60 seconds and it all worked fine!

Fire up vSphere Client and connect to another vCenter Server or ESXi host, then click Edit->Client Settings. Change the Client-Server Command Timeout value to Use a custom value and the Timeout in seconds to 60.


Here’s the VMware KB article about timeout values:, there’s also instructions on how to edit the Windows registry if you can’t bring up vSphere client.

Just for the sake of it, here’s the error log:

[viclient:Error :P: 3] 2016-09-06 10:12:35.520 RMI Error Vmomi.SessionManager.Login - 4
<Error type="VirtualInfrastructure.Exceptions.RequestTimedOut">
 <Message>The request failed because the remote server 'xxxxx' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)</Message>
 <InnerException type="System.Net.WebException">
 <Message>The command has timed out as the remote server is taking too long to respond.</Message>
 <Title>Connection Error</Title>
 <InvocationInfo type="VirtualInfrastructure.MethodInvocationInfoImpl">
 <StackTrace type="System.Diagnostics.StackTrace">
 <Target type="ManagedObject">SessionManager:SessionManager [xxxxx]</Target>
[viclient:Critical:M: 6] 2016-09-06 10:12:35.531 Connection State[xxxxx]: Disconnected
[viclient:SoapMsg :M: 6] 2016-09-06 10:12:35.532 Attempting graceful shutdown of service ...
[viclient:SoapMsg :M: 6] 2016-09-06 10:12:35.534 Pending Invocation Count: 0
[viclient:SoapMsg :M: 6] 2016-09-06 10:12:35.535 Graceful shutdown of service: Success
[ :Error :M: 6] 2016-09-06 10:12:35.543 Error occured during login
VirtualInfrastructure.Exceptions.LoginError: The server 'xxxxx' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)
 at VirtualInfrastructure.LoginMain.Process(BackgroundWorker worker, DoWorkEventArgs e)
 at VirtualInfrastructure.LoginWorkerImpl.Worker_DoWork(Object sender, DoWorkEventArgs e)
 at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
 VirtualInfrastructure.Exceptions.RequestTimedOut: The request failed because the remote server 'xxxxx' took too long to respond. (The command has timed out as the remote server is taking too long to respond.)
 at VirtualInfrastructure.Soap.SoapServiceWrapper.DoInvokeSync(ManagedObject mo, MethodName methodName, Object[] parameters, Int32 timeoutSecs)
 at VirtualInfrastructure.Soap.SoapTransport.VirtualInfrastructure.Transport.InvokeMethod(ManagedObject mo, MethodName methodName, Object[] pars)
 at VirtualInfrastructure.ManagedObject.InvokeMethod(MethodName methodName, Object[] pars)
 at Vmomi.SessionManager.Login(String userName, String password, String locale)
 at VmomiSupport.VcServiceImpl.LoginNormally(LoginSpec loginSpec)
 at VmomiSupport.VcServiceImpl.Login(LoginSpec loginSpec)
 at VirtualInfrastructure.LoginMain.Process(BackgroundWorker worker, DoWorkEventArgs e)
 System.Net.WebException: The command has timed out as the remote server is taking too long to respond.

 --- End of inner exception stack trace ---

Issues using Windows Session Credentials with vSphere Client and vCenter Server Appliance

So it seems there’s a known bug when using vSphere Client to log into your vCenter Server Appliance….. it actually affects vCenter Server Appliance 5.1, 5.5, and 6.0.

If you try to log in to vCenter Server by checking the “Use Windows Session Credentials”, it bombs out with a General System Error as follows:

Looking into the vpxd.log from the Web Client Log Browser, you will be able to see the following errors:

(Note: filter the vpxd.log using the time you tried to log in)

You can also view the vpxd.log file by logging into the console of the vCSA, enabling shell and navigating to /var/log/vmware/vpxd/

In there, you will see entries similar to:

<YYYY-MM-DD>T<TIME>+02:00 [7F1C10CCC700 error ‘GSSAPI’ opID=CEAEA705-00000004-2d] Cannot get user info for domain\user. Possible NSS configuration problem.
<YYYY-MM-DD>T<TIME>+02:00 [7F1C10CCC700 info ‘commonvpxLro’ opID=CEAEA705-00000004-2d] [VpxLRO] — FINISH task-internal-9727699 — — vim.SessionManager.loginBySSPI
<YYYY-MM-DD>T<TIME>+02:00 [7F1C10CCC700 info ‘Default’ opID=CEAEA705-00000004-2d] [VpxLRO] — ERROR task-internal-9727699 vim.SessionManager.loginBySSPI: vmodl.fault.SystemError:
(vmodl.fault.SystemError) {
dynamicType = <unset>,
faultCause = (vmodl.MethodFault) null,
reason = “Cannot get user info”,
msg = “”,

(Note: I ran a grep against the vpxd.log file looking for GSSAPI)


To work around this issue, manually enter user credentials instead of using the User Windows session credentials option.

Alternatively, to resolve this issue:

  1. Log in to vCenter Server Appliance as the root user.
  2. For vCenter Server Appliance 6.0 you need to enable the Bash shell in order to access the linux OS, to enable the Bash shell, run the shell.set –enabled True command.
  3. Open the /etc/nsswitch.conf file using a text editor (i.e. VI)
  4. Locate the passwd: compat ato entry and replace it with passwd: compat ato lsass.
    Note: Remove lsass from the line if it is currently displayed
  5. Restart the services using /etc/init.d/vmware-vpxd restart.

You can read more in the KB here: