I ran into a bit of a challenge when trying to deploy a new 5.5 vCenter Server in which the VirtualCenter Server service would constantly fail to start. Peeking into the logs, I found this entry in the C:\ProgramData\VMware\VMware VirtualCenter\Logs\vpxd.log file:

[error ‘App’] [VpxVmomi] Failed to create Secure WebService socket: class Vmacore::SystemException(An attempt was made to access a socket in a way forbidden by its access permissions. )
[error ‘App’] [VpxdVmomi] Failed to start VMOMI services: An attempt was made to access a socket in a way forbidden by its access permissions.
[info ‘App’] Shutting down VMware VirtualCenter…

A bit of Googling landed me on VMware KB 2007152, entitled Starting the VMware VirtualCenter Server service fails with the error: Failed to create Secure WebService socket: class Vmacore::SystemException, which covers the issue – basically stating that something is hogging port 8085 (an important port used for SDK connections to vCenter) – and offers a method to discover the culprit.

Finding The Smoking Gun

As stated in the KB, I ran the netstat command to see who owns port 8085, which is needed for VMOMI. Below is the full command:

netstat -ano | find /N "8085"

For clarity, here’s an example from my lab as to what you should normally see: a list of TCP connections that are listening, established, or time_wait. The PID value, which is somewhat random, lets you know which process is involved with the TCP session. By enabling the PID column in the task manager, we can see that PID 3428 is owned by vpxd.exe (vCenter).

Looking at the various process PIDs on the new vCenter Server, I matched the owner to a process called GravitixService.exe. Sounds kinda like a virus, but apparently not! A bit more Googling brought me to the Lumension site, specifically for their PatchLink acquisition which used the GravitixService process as an endpoint agent. Interesting enough, their Endpoint Management and Security Suite (LEMSS) was also running on the server for compliance and patching reasons. Hey, stop stealing port 8085!

At this point, I had my smoking gun, although I literally could not find a darn thing on the web about LEMSS and the VMOMI service conflicting. Perhaps this is a niche case?

Either way, if anyone hits this issue, here’s the workaround.

Note: I ran into this issue using vCenter Server 5.0, 5.1, and 5.5 – I haven’t tested it with vCenter 4.x (but with 4.x support going away, I doubt it matters).

The LEMSS Workaround

If you allow the LEMSS service to start before vCenter Server, the GravitixService process will cause the VirtualCenter Server service (vpxd) to fail. However, if you kill both the LEMSS service and the GravitixService.exe process, then try launching the VirtualCenter Server service (vpxd), it runs fine. So:

1. Set the LEMSS service to manual
2. Wait for the VirtualCenter Server service to start
3. Launch the LEMSS service – either manually or via a boot / scheduled task script

Or you could just avoid using LEMSS on the vCenter Server 🙂