You would be surprised at the number of times I have heard this question get asked and this is not regarding the installation path but the specific server a given vCenter Server 5.1 component is installed on. I am just wondering if people are somehow miss-placing their infrastructure? I would hope that most organizations have some type of CMDB (Configuration Management Database) even if it is just a spreadsheet or at a minimum a memorable hostname. In any case, this question is only relevant for those of you who decided to separate out the vCenter SSO (Single Sign-On) Server, vSphere Web Client, Inventory Service and the vCenter Server and are now wondering where a given component is installed at.
To begin, you will need to know at a minimum where your vCenter Server is installed at. If you do not know that, then you should take the walk of shame and install this utility (be-careful with port scanning tools, as it may not be allowed by your Security Operations team). Go to the advanced settings of your vCenter Server and look up one of the following settings:
  • config.vpxd.sso.sts.uri
  • config.vpxd.sso.groupcheck.uri
  • config.vpxd.sso.admin.uri

All three of these settings should contain the same hostname or IP Address which is the location of where your SSO Server is installed. You can also find this information by looking at the vCenter Server configuration file located in the following location:

Windows vCenter Server: C:\ProgramData\VMware\VMware VirtualCenter\vpxd.cfg
vCenter Server Appliance: /etc/vmware-vpx/vpxd.cfg

Next, you will need to login directly to your vCenter Server (RDP or SSH) depending on the version you are using. Using the hostname or IP Address of our vCenter SSO Server, we will now connect to the Lookup Service which is installed alongside the vCenter SSO Server. This service will provide us with the location of all services registered to vCenter SSO and we will be able to identify the location of the remainder vCenter Server components.

For Windows vCenter Server, make sure you have the JAVA_HOME environmental variable set to C:\Program Files\VMware\Infrastructure\jre and open up a command prompt and run the following (subsitute in the hostname or IP Address of your vCenter SSO Server):

“C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli\ssolscli.cmd” listServices https://winvc.primp-industries.com:7444/lookupservice/sdk

We can take a look at the serviceName which describes the specific vCenter Server component such as the vSphere Web Client or Log Browser and endpoints property will tell you which server it is installed on.

For vCenter Server Appliance, there is a similar command by running the following:

/usr/lib/vmware-sso/bin/vi_regtool listServices https://172.30.0.186:7444/lookupservice/sdk

The only vCenter Server component that we have not found is the Inventory Service. To find the server where this component is installed, we just need to look at the vCenter Server Extensions and and we can simply open up a web browser and connect to the following URL (substitute in your vCenter Server address):

https://vcsa.primp-industries.com/mob/?moid=ExtensionManager&doPath=extensionList[%22com.vmware.vim.inventoryservice%22].healthInfo

Hopefully at this point you are able to figure out where all your vCenter Server 5.1 components are installed at and you are also documenting all this information in your CMDB or spreadsheet :)

4 thoughts on “Dude, Where’s My vCenter Server 5.1 Components Installed At?

  1. It’s not very surprising really, when you have multiple people managing your vSphere environment. Your core setup (VCenter and DB) is easy as its well documented (at least it should be), but additional components such as UM, vShield and what not tend to get installed somewhere along the way“ at least thats my experience. Or rather “What the f&ck is [change|config|asset] management?”

    • If vCenter & DB is well documented, so should other core infrastructure components, there should not be any exceptions. IMHO, this means people are not taking the time to properly document their environment and there is no change management or accountability. When something goes wrong, time is of the essence and having these things documented is going to be important also along with updates/patching. I’m hoping this article will help those that may not have documented their environment, but I’m hoping that any piece of software/hardware that’s installed is documented somewhere in a users environment :)

  2. Hi William,
    Thanks for informative blog.
    I have a query regarding LookupURI.

    Can i configure this lookupURI to point to a third party SSo Service provider like OpenAM ?

    I am badly struck with it.
    Yours help will be highly appreciable.

    Thanks in advance
    Rohit Dwivedi

Thanks for the comment!