vCenter Server 6.0 Tidbits Part 7: Connecting to SSO/PSC using JXplorer

I have written about using JXplorer before which is a free LDAP browser utility that can connect to vCenter SSO's vmdird (VMware Directory Service) which you can find more details here. In vSphere 6.0, there are a couple of minor changes you will need to be aware of if you need to connect to SSO which is now located in the Platform Services Controller. The first change is that port 11711 is no longer used and has now changed to 389. The second change when using JXplorer to connect to the vmdird is that BaseDN property is no longer needed and if you try to specify it, you will not be able to connect.

Here are the updated instructions to connect to vmdird in vSphere 6.0 which is now located in the PSC or in an embedded deployment.

Disclaimer: Please take extreme caution when connecting to the vmdird database, this is primary for educational purposes. You should take extreme care in making changes while in the database else you can negatively impact your environment.

Host: Hostname/IP Address of PSC
Protocol: LDAPv3
Port: 389
Level: User + Password
User DN: cn=Administrator,cn=Users,dc=vghetto,dc=local
User DN: SSO Admin Password

In addition, I also wanted to also mention a couple more tidbits that could come in handy when connecting directly to the vmdird, especially in a troubleshooting scenario. The first is finding the SSO Domain Name which is displayed by expanding the tree, in my environment it is called vghetto.local and the second is finding the SSO Site Name which is under "Configuration->Sites" which can be seen in the screenshot below.

On top of that, if you wish to find all deployed PSC's, you can do so by expanding "Configuration->Sites->Servers" and by expanding each of those sub-entries you can also see if they are replicating to other PSC's.

If you wish to find all deployed and connected vCenter Servers associated with the current PSC, you can expand "Computers".


Quick Tip - How to change serial number for Mac OS X VM?

Last week I wrote an article on how to ensure unique serial numbers are generated when cloning Mac OS X VMs in vCloud Director and as part of that research, I also came across another neat trick that I learned from one of our Engineers, Regis Duchense. It turns outs that in recent releases of ESXi and Fusion, you can now set a specific serial number for a Mac OS X VM for customers who may require this for testing purposes.

To set a particular serial number, you simply just need to add the following setting to your VMX file (which can also be automated when working with ESXi via the vSphere API):

serialNumber = "SERIAL-NUMBER"

Although, I was not able to find the particular release of ESXi and Fusion that introduced this capability, this trick could come in handy for those of you who have this specific requirement.

How to deploy vSphere 6.0 (VCSA & ESXi) on vCloud Director and vCloud Air?

In case you missed the awesome news last Friday, George Kobar who works over in the vCloud Air team shared a really cool solution in which he demonstrates how to efficiently setup Nested ESXi running in vCloud Air which includes support for inner-vm guest communication without requiring Promiscuous Mode. Nested ESXi has been possible on vCloud Air for quite some time, in fact when I was first granted access I had to try it out myself and had written about it here. The great thing about vCloud Air is that it runs directly on vSphere which means you will get all the added benefits of the underlying vSphere platform including things like VHV (Virtual Hardware Assisted-Virtualization) to ensure that your Nested ESXi VM and its virutal workloads runs as efficiently and as performant as possible. If you are new to vCloud Air, I would recommend checking out this tutorial here which goes into some of the basic operations.

Given the updated news regarding Nested ESXi on vCloud Air, I am sure many of you are excited to try out this new trick for those requiring inner-vm guest communication. I figured most of you will be interested in trying out vSphere 6.0, especially with some of the new capabilities like SMP-FT and VSAN 6.0 which runs perfectly fine in a Nested ESXi environment for demo and learning purposes as shown here and here. I thought I would put together a quick guide on how to setup both Nested ESXi 6.0 as well as the new VCSA 6.0 (which does have a few minor caveats but can definitely run in vCloud Director and vCloud Air environment).

Disclaimer: The usual caveat ... Nested ESXi is not officially supported by VMware

ESXi 6.0

There is no version of vCloud Director for the Enterprise that supports vSphere 6.0 which means there is no direct support for the latest virtual hardware release which is 11 or support for ESXi 6.x guestOS type. This is also true for vCloud Air which is currently running on vSphere 5.5 and because of this reason, you will need to upload a VM that has been configured with ESXi 5.x as the guestOS type when looking to install ESXi 6.0. Once vCloud Air supports vSphere 6.0, then you can upload a VM that has been created with the ESXi 6.x guestOS type.

The easiest way to create Nested ESXi VM in a vCloud Director or vCloud Air environment is to simply import a VM that has already been configured with ESXi guestOS type (this does not need to be an already installed image). To help expedite the deployment of Nested ESXi in vCloud Air, I have built several Nested ESXi OVF Templates that that you can use. You will also need to upload an ESXi 6.0 ISO or whichever version of ESXi you plan on running since both ESX(i) 4.x and 5.x is possible.

VCSA 6.0

One of the challenges I came across when testing the new VCSA 6.0 in a vCloud Director based environment which also affect vCloud Air is that they do not support a few capabilities within the OVF specification, namely Deployment Options. Due to this limitation and few others, we can not directly import the VCSA 6.0 OVA into vCloud Director. Luckily, there is a workaround which I had looked into a few months before the GA of vSphere 6.0 and below are the steps to import a VCSA 6.0 OVA into a vCloud Director environment. If you are looking to run VCSA 5.5, then you can directly import the OVA without going through these steps.

Step 1 - Download and extract the contents of the VCSA 6.0 ISO

Step 2 - Convert VCSA 6.0 OVA located in vcsa/vmware-vcsa into an OVF by either using ovftool, tar or a tool like 7zip.

ovftool --sourceType=OVA vmware-vcsa vmware-vcsa.ova

Next, you will need to make several modifications to the OVF file. I do have to warn you, there are a few tweaks and I highly recommend that you use the OVF templates that I have already created for you. Make sure to also delete the .mf (manifest file) since you are making changes to the OVF else the OVF validation will throw an error because the files have been modified.

To save you some time, pain and troubles, I have pre-created the following 3 OVFs (based on vSphere 6.0 GA release of VCSA 6.0) which contains all the modifications mentioned in Step 3 which you can download and then jump to Step 4:

Step 3 - The first is to locate the "References" tag located at the top of the OVF file and remove the line containing the RPM reference. At the end it should look something like the following:

In addition, depending on the method you took to convert the OVA to an OVF, you may also need to rename the json and disk file names located in this section to match the extracted contents.

The second is to delete the following section from the OVF that starts with MigrationUpgradeRequisitesSection:

The fourth step is to specify the deployment option type that you wish to use. VCSA 6.0 supports the following: embedded, infrastructure (PSC) and management (VC). You will need to locate the following line containing guestinfo.cis.deployment.node.type and set the value property to one of the three options.

The fifth and final step is to specify the deployment size that you wish use for your VCSA, here are nine different supported options:

  • Embedded
    • tiny
    • small
    • medium
    • large
  • vCenter Server Management Node (only)
    • management-tiny
    • management-small
    • management-medium
    • management-large
  • Platform Services Controller Node (only)
    • infrastructure

Since both vCloud Director and vCloud Air does not support the Deployment Option OVF capability, you will need to specify the deployment you wish to use. Locate the DeploymentOptionSection and the first entry where it shows "default=true", you will need to change the id to match one of the entries show above. For example, if you wanted an Embedded VCSA deployment using the tiny size, you would specify "tiny" in the id field.

Once you have selected the type of deployment, you will also need to remove ALL entries referencing the other deployment types else it will always deploy an Embedded deployment.

Note: I would like to give a big shout-out to Doug Baer who works over in the VMware HOL team, he actually discovered the initial issue with the Deployment Options and found the workaround by removing the other disk references. If not, you would end up needing ~2TB of storage as VCD tries to aggregate all nine deployments into one! When I had initially worked out the steps to deploy a VCSA 6.0, I had only used the Embedded deployment option.

Step 4 - You are now ready to upload your VCSA 6.0 OVF to your vCloud Director or vCloud Air environment.

Note: For vCloud Air, you will need to use the "Manage in vCloud Director" link to upload the OVF as the vCloud Air interface does not support direct OVA/OVF uploads.

Step 5 - When you are are ready to deploy your VCSA, one very important step that you will need to do is to edit a few of the OVF properties in the VM before powering it on. If you power on the VCSA before performing this step, the system will need to be deleted and re-deployed as the OVF properties are only read in on the initial first boot which is required for proper configuration.

  • Make sure to disable guest customization, to do so right click on the VM and select Guest OS Customization and uncheck "Enable guest customization"
  • To edit the OVF properties, right click on the VM and select Properties. Click on Guest Properties and you will ONLY be editing the following three sections

Networking Configuration

System Configuration

SSO Configuration

For an Embedded Configuration, you will need to edit the following (below is an example of the data input):

Host Network IP Address:
Host Network IP Address Family: ipv4
Host Network DNS Servers:
Host Network Default Gateway:
Host Network Mode: static
Host Network Identity: vc-01a.corp.local
Host Network Prefix: 24
Tools-based Time Synchronization Enable: check OR NTP Servers
Root Password: VMware1!
SSH Enabled: check/uncheck
Directory Domain Name: vghetto.local
New Identity Domain: check
Directory Password: VMware1!
Site Name: virtuallyGhetto

For a vCenter Server Management Node only , you will need to edit the following (below is an example of the data input):

Host Network IP Address:
Host Network IP Address Family: ipv4
Host Network DNS Servers:
Host Network Default Gateway:
Host Network Mode: static
Host Network Identity: vc-01a.corp.local
Host Network Prefix: 24
Tools-based Time Synchronization Enable: check OR NTP Servers
Platform Services Controller: psc-01a.corp.local
Root Password: VMware1!
SSH Enabled: check/uncheck
Directory Domain Name: vghetto.local
New Identity Domain: uncheck
Directory Password: VMware1!
Site Name: virtuallyGhetto

For a Platform Services Controller Node only, you will need to edit the following (below is an example of the data input):

Host Network IP Address:
Host Network IP Address Family: ipv4
Host Network DNS Servers:
Host Network Default Gateway:
Host Network Mode: static
Host Network Identity: psc-01a.corp.local
Host Network Prefix: 24
Tools-based Time Synchronization Enable: check OR NTP Servers
Root Password: VMware1!
SSH Enabled: check/uncheck
Directory Domain Name: vghetto.local
New Identity Domain: check
Directory Password: VMware1!
Site Name: virtuallyGhetto

If everything was deployed successfully, you should now have a VCSA 6.0 instance running in either your vCloud Director or vCloud Air environment.

Quick Tip - Cloning Mac OS X VMs with unique serial numbers in vCloud Director

This week I learned about a really cool use case from one of our customers who is using vCloud Director to provision Mac OS X virtual machines to their end users both from a development standpoint but also for troubleshooting and demo purposes for their field and QA organizations. Instead of having to manage hardware assignment across large user base, they have built a completely self-service environment for requesting access to Mac OS X VMs, which I thought was pretty neat.

One issue that they were running into was that when they deployed a Mac OS X VM from their vCD Catalog which is a clone operation, they found that the cloned instances contained the exact same serial number as the source VM and that was giving them some problems. I had pinged a few of our engineers to see if they had any ideas and it turns out that the Mac OS X serial number is generated based off of the uuid.bios property of a VM.

Once I found this out, I knew the exact problem because this was something I had seen before when I had worked with vCD. When deploying a vApp from a Catalog in vCD, the bios.uuid property of the VMs are all kept identical and this would explain why the serial number was the same. This behavior is documented in this VMware KB 2002506 and it also includes a solution to the problem. Once the customer made the change, they were now able to deploy new Mac OS X instances with uniquely generated serial numbers. For regular vSphere or Fusion environments, when cloning a Mac OS X VM, the serial number should always be unique as this problem is only specific to vCD. I should also note that once the serial number has been generated, changing the existing bios.uuid will not force the serial number to change.

Configuring VCSA 6.0 as vSphere Web Client Server for vSphere 5.5

The vSphere 6.0 Web Client has been greatly improved with the release of vSphere 6.0 which includes a number of performance and UX enhancements. If you are interested in some of the details, be sure to check out this blog post by Dennis Lu, Product Manager of the vSphere Web Client. To really get the best possible user experience and to take advantage of all the new performance enhancements, it is recommend that you upgrade your entire vSphere environment which includes vCenter Server to vSphere 6.0. Having said that, I know this may not be possible for everyone immediately and it will take some time depending on your organizations software upgrade cycles and procedures, qualifications, burn in time, comfort left, etc. with vSphere 6.0 before completely moving over.

Over the last couple of weeks, I have seen quite a few requests from customers who have expressed interest in being able to just use the new vSphere 6.0 Web Client with their existing vSphere 5.5 environment as they make their transition over to vSphere 6.0. I can definitely understand where these customers are coming from and honestly, the vSphere Web Client should just be that, a UI Client. We should be able to decouple it from vCenter Server and be able to iterate on it based on feedback from our customers and partners. I did some investigation and I actually discovered that we in fact support something called Mixed-Version Transitional Environment in vCenter Server for Windows Upgrade. This is a bit of a mouth full but basically you can have a hybrid vCenter Server environment that consists of both vSphere 5.5 and 6.0 as you upgrade to full a full vSphere 6.0 environment.

I spent a couple of days researching this topic a bit more to see if I can come up with a solution that would ideally reduce number of changes introduced to a customers existing vSphere 5.5 environment while being able to leverage the new vSphere 6.0 Web Client. After many discussions, prototyping, snapshot reverts and with the help of one of my good GSS buddy G. Blair Fritz, we have come up with a very cool solution using the VCSA 6.0 as a "thin" vSphere 6.0 Web Client Server. The overall goal is to provide a period of time in which customers can use the new vSphere 6.0 Web Client with their existing vSphere 5.5 environment and when the time comes for a complete vSphere 6.0 upgrade, this "thin" vSphere 6.0 Web Client can be decommissioned and removed.

Disclaimer: Though this hybrid configuration is supported, using the VCSA as a "thin" vSphere Web Client Server is not officially supported. Please use at your own risk. It is still recommended that you upgrade your existing vSphere 5.5 environment to vSphere 6.0 as soon as possible to get the full benefits of the enhancements made to the vSphere 6.0 Web Client.


  • vSphere 5.5 running Windows using an External SSO Server
  • At least one vCenter Server 5.5 pointing to the External SSO Server

Here is the high level workflow as well as a diagram to help you visualize the process:

  • Step 1 - Upgrade your external SSO from vSphere 5.5 to new PSC 6.0
  • Step 2 - Deploy VCSA 6.0 and configure it to point the newly upgraded PSC 6.0
  • Step 3 - Running a configuration script within the VCSA 6.0 to optimize it as a "thin" vSphere Web Client Server

In my test environment, I have deployed a vCenter Server 5.5 which points to an external SSO (also running vSphere 5.5).

Step 1 - The first step is to upgrade the SSO server to the new PSC 6.0, you will follow the existing procedure by mounting the ISO and going through the guided installation. At this point, you can continue logging into the existing vSphere 5.5 Web Client and access your vCenter Server and its hosts and VMs.

Step 2 - Next, you will need to deploy a new Embedded VCSA 6.0 using either the Guided or Scripted Installation. You will need to make sure that it is joining to an existing SSO Domain by specifying the upgraded Windows PSC that you performed in step one. The SSO Domain Name should be vsphere.local as this was not a configurable option in earlier vSphere releases. At this point, you can now login to the VCSA 6.0 which provides the vSphere 6.0 Web Client but you will notice that you only see an empty inventory of the new vCenter Server 6.0 as well as an error message stating "Login failed due to invalid credentials for one or more vCenter Server systems"

The reason for this is that you need to restart the vpxd service on your vCenter Server 5.5 for it to be visible in the new vSphere 6.0 Web Client.

Note: It is important that if your external PSC is joined to an Active Directory Domain that you ensure the NTP Server specified in the VCSA 6.0 deployment also points to the same AD Server for the time source to be synchronized else you will run into problems later.

Step 3 - Login to your vCenter Server 5.5 and restart the vCenter Server service using the Services utility.

Step 4 - Once the vCenter Server service has restarted, you can now open a browser to the Hostname/IP Address of the VCSA 6.0 and you will see both vCenter Servers. You can now manage your vSphere 5.5 environment using the vSphere 6.0 Web Client.

I was pretty happy when I got this solution working but I was still not content. The smallest deployment size for an Embedded VCSA requires 8GB of memory, which is still a considerable amount of resources in my opinion. I wanted to optimize it further by turning off unnecessary services, modify the memory requirements for the unused services as well as un-registering the vCenter Server 6.0 endpoint so that you only see your vSphere 5.5 vCenter Servers only. Surprisingly, this took up the bulk of our research to figure out what could be turned off, how to properly turn it off and then un-registering the VC endpoint.

I have created the following shell script called which needs to be uploaded to the VCSA (need to enable Bash shell on the VCSA). The following three variables must be updated prior to running:

  • PSC_SERVER - The Hostname/IP Address of your external PSC
  • SSO_USERNAME - The SSO Administrator account
  • SSO_PASSWORD - The SSO Administrator password

Once everything completes successfully, you should turn off your VCSA and modify the memory from 8GB to 3GB. From my limited amount of testing, the overall memory utilization was sitting around ~2-2.5GB of memory, so I think configuring it to 3GB should be plenty and you can always adjust accordingly. Since we have disabled all the unnecessary services, the VCSA boot time should be pretty quick and now when you login to the vSphere Web Client, you should only see your vSphere 5.5 vCenter Servers and nothing else.

When the time comes and you are ready to fully upgrade your vSphere 5.5 environment to vSphere 6.0, you can decommission and remove this "thin" vSphere Web Client Server by following the procedure outlined in this VMware KB 2106736. I think it would be really nice to be able to update the vSphere Web Client outside of updating vCenter Server and truly providing a "client" that is decoupled. What do you think?