How to split vCenter Servers configured in an Enhanced Linked Mode (ELM)?

An interesting question that came up on the VMTN forum the other day (thanks to Andreas Peetz for sharing via Twitter) was how to split two vCenter Servers configured in an Enhanced Linked Mode (ELM)? Due to an organization changes in the customers environment, they needed to separate out their two vCenter Servers and run them independently of each other. Although this may sound like an rare event, I have actually seen this use case come up several times now which maybe from a business unit restructuring, spinning out or selling off company assets which then requires the customer to split their existing vCenter Servers that is configured with ELM.

Below is a diagram depicting an example where the original source environment (left) which is composed of two vCenter Servers and two external Platform Services Controller (PSC) configured in an ELM and the desired destination environment (right) which are two separate vCenter Server instances no longer configured in ELM.

The solution to this problem is actually pretty straight forward and leverages the existing vCenter Server and/or Platform Services Controller (PSC) "decommission" workflow. Rather than decommissioning the nodes, we are just simply keeping them around. Below are the instructions on how to achieve this outcome.

Disclaimer: Although this solution uses an existing supported workflow, this particular use case has not been tested by VMware. As such, this would not be officially supported by VMware until the appropriate testing has been done by our Engineering teams. One potential option in the short term if you are looking for support from VMware is to file an RPQ request through your VMware account team.

Continue reading

vSphere 6.5b prevents vSphere Web Client logins for users w/o VC permissions

A patch update was just released for vCenter Server 6.5, dubbed vSphere 6.5b. While glancing through the release notes, I caught one interesting "resolved issue" which I thought was worth sharing.

Users with no vCenter Server permissions can log in to the vSphere Web Client

Users without permissions can log in to the vSphere Web Client. Users can click the menu options, but no inventory is displayed.

Users with no permissions can no longer log in to the vSphere Web Client.

To enable the login, set the allow.user.without.permissions.login = true property in the file.

This particular behavior has been something that has confused a few customers and has been asked about since the introduction of vCenter Single Sign-On (SSO) service. The issue or rather the confusion is that prior to the SSO service, vCenter Server handled both authentication as well as authorization.

With SSO, authentication was no longer being handled by vCenter Server and this meant that even if you had no permissions in vCenter Server but you could authenticate to SSO (especially common when Active Directory is configured), you would still be allowed to login to the vSphere Web/H5 Client.

Although vCenter Server would does the right thing and does not display any inventory if you do not have any permissions, it was still not a desired behavior in addition to the confusion it caused. I was pleasantly surprised to see that we have changed this default behavior by disallowing logins to the vSphere Web/H5 Client if a user has no VC permissions. Below is the message you will receive if you try to login without VC permissions.

If you wish to revert to the original behavior, you can do so by simply adding the allow.user.without.permissions.login = true setting into the vSphere Web/H5 Client configuration file ( and restart the vSphere Web/H5 Client service. I think many of our customers will appreciate this fix as well as the new default behavior!

Exploring new VCSA VAMI API w/PowerCLI: Part 10

In Part 10, we are going to take a look at local user management for the VAMI interface. By default, only the root local user exists but customers have the option of creating additional accounts. In vSphere 6.5, the VAMI has been enhanced to support different roles such as Admin, Operator and SuperAdmin. You can refer to the VAMI documentation on what each of the roles provides.

VAMI UI Area of Focus

There is not a VAMI UI for user management, this is currently only available using the VAMI REST APIs.


  • GET /appliance/techpreview/localaccounts/user
  • POST /appliance/techpreview/localaccounts/user
  • DELETE /appliance/techpreview/localaccounts/user/{user-id}

PowerCLI Function

Sample Output

To retrieve all VAMI users, use the Get-VAMIUser function. By default, your system will probably only have the root user unless you have already added additional VAMI users.

To create a new user, we will use the New-VAMIUser which requires a few input parameter that should be pretty self explanatory. The role parameter can be one of three values: admin, operator or superAdmin as defined in the VAMI documentation.

Here is an example of creating a new user called lamw:

New-VAMIUser -name lamw -fullname "William Lam" -role "operator" -email "[email protected]" -password "VMware1!"

If we now re-run our Get-VAMIUser command, we should see the new user that we had just created.

To remove a VAMI user, you simply use the Remove-VAMIUser and specify the name of the user you wish to remove. Below is an example of deleting the user we had just created.

One thing to note is that when using the Connect-CisServer cmdlet to interact with the VAMI REST API, it currently does not support connecting with local VAMI users, only SSO users. This is a limitation with the PowerCLI implementation and does not affect direct use of the VAMI REST API or using it through other SDKs. This is something that will be resolved in a future update of PowerCLI, so something to keep in mind as I was scratching my head when trying to use a local user to authenticate.

Installing the Horizon View Agent on a Domain Controller

A couple of weeks back, a fellow colleague needed to install the Horizon View Agent on a Microsoft Windows Domain Controller to be able to take advantage of the Direct Connect feature to efficiently connect into a lab environment. In general, this is not a recommended practice. In fact, by default the Horizon View Agent includes several pre-checks, one of which that prevents the installation if it detects the underlining system is a Domain Controller.

In this particular scenario, the Domain Controller was not being used for a real production environment but rather as part of a vPod that is hosted in a Hands-On-Lab type of environment. I could also see another use case where this might occur in personal home labs where you might consolidate several types of roles on a single Windows system and wish to be able to use the Direct Connect feature of the Horizon View Client.

The individual had searched extensively online but all the suggested command-line flags were not applicable to the Horizon View Agent. After pinging me for ideas, I reached out to a few of our End-User Computing folks and thanks to them, we found a neat little work around by tweaking the MSI installer.

Disclaimer: This is not officially supported by VMware, please use at your own risk. There are no guarantees that the behavior described here will continue to function going forward and it can change without notice.

Continue reading

PowerCLI module for Proactive HA (including simulation)

Proactive HA is a very cool new feature that was introduced in vSphere 6.5, which enables our hardware vendors to communicate their hardware specific health information directly into vSphere and specifically with vSphere DRS. This hardware health information can then be leveraged by vSphere DRS to take proactive actions to guard against potential hardware failures. Brian Graf, Product Manager for Proactive HA, DRS and overall vSphere Availability has a nice blog post here where he goes into more details on how Proactive HA works.

As Brian mentioned, a few of our select hardware vendors are already in the process of developing and certifying Proactive HA integrations for vSphere, so stay tuned for those announcements in the future by both VMware and our partners. In the meantime, there was an interesting comment from one of our field folks asking whether it would be possible to "simulate" the new Quarantine Mode operation for an ESXi host to be better understand how this feature might work?

Quarantine Mode is new mode for ESXi, which can only be triggered by Proactive HA. It functions similar to the Maintenance Mode operation, but instead of migrating all VMs off, it will allow existing VMs to continue to run but prevent additional new VMs to be placed on the host.

Proactive HA does provide a set of public vSphere APIs under the healthUpdateManager which is primarily targeted at our hardware vendors to consume. However, these APIs could also be used by our customers to get visibility into the current Proactive HA configuration as well as the health of the ESXi hosts from the Proactive HA provider standpoint. Going back to our initial question, it is possible to "register" a fake Proactive HA provider and manually generate health updates to simulate what a real Proactive HA solution could look like.

Disclaimer: This is for educational and lab purposes only. Creating a fake or simulated Proactive HA provider is not officially supported by VMware, please use at your own risk. The creation of Proactive HA providers as well as publishing health updates is for our hardware vendors to consume which in turn will provide native integrations that include customer visible interfaces within the vSphere Web Client.

Continue reading