Configure vRealize Automation to use Platform Services Controller as External Identity Provider

I was doing some research on an inquiry that I had received from a customer who was interested in configuring their vRealize Automation (vRA) instance to use vCenter's Platform Services Controller (PSC) as an External Identity Provider (IDP) rather than the default VMware Identity Manager (vIDM) which vRA supports natively out of the box. vIDM already supports a large number of websso applications as seen here and it itself can also be used as an External IDP to integrate with things like Active Directory Federation Services (ADFS) for example.

For some customers who are more familiar with the PSC, this is a convenient way to unify their authentication between the different vRealize products which support vIDM and integrating that directly with PSC. Since both solutions spoke SAML, it was merely figuring out process on setting up the External IDP using the PSC. In reading some of our internal Wikis and working with one of the vIDM Engineers, since I was stuck on a particular step, I was able to finally get this to work which I have outlined the steps below. I also learned that we had officially supported this since vRA 7.0 which was great to hear as well.

I know there are number of customers who would also like to see the reverse of this configuration, where PSC can use vIDM as an External IDP. I know this is something the PSC team is currently looking into for External IDP support. If this is something that you are interested in or would like to see specific External IDP setup/configuration, feel free to leave a comment.


  • Join Platform Services Controller (PSC) to Active Directory (instructions here & here)
  • Join vRealize Automation (vRA) Appliance to Active Directory (instructions here)

In my lab environment, I have deployed an Embedded VCSA 6.5 (this also works with an External PSC) and vRealize Automation 7.2 (this was prior to 7.3 getting released but should work as well).

Continue reading

Automating the new native VCSA bootstrap "Easy Install" in vSAN 6.6

In case you missed the previous article, have a read here which goes into greater detail behind the new VCSA bootstrap installer (also known as vSAN Easy Install) which is part of the new vSAN 6.6 release. As I hinted at the end of the previous post, customers not only have a simplified way of bootstrapping the VCSA on vSAN from a UI standpoint but they can also completely automate this leveraging some of the new vSAN Management 6.6 APIs, which are the same APIs that the UI uses.

A new Managed Object called VsanVcsaDeployerSystem is now available when connecting to either a standalone ESXi host as well as a vCenter Server. It contains the following three methods:

Here is the workflow for automating the VCSA bootstrap installer:

Step 1 - Connect directly to the ESXi host which you wish to bootstrap vSAN. You will use the VsanPrepareVsanForVcsa() API which accepts a list of disks for either a Hybrid or All-Flash vSAN datastore.

Step 2 - Deploy the VCSA like you normally would using the CLI Installer. You will specify the ESXi host that you had just prepared in Step 1 which includes the vSAN Datastore that was setup as part of that process.

Step 3 - Once the VCSA has been successfully deployed, you will connect to the vCenter Server and use the VsanPostConfigForVcsa() API which will create a vSphere Datacenter, vSphere Cluster and enable it with vSAN (which can also include Dedupe/Compression if you are using an All-Flash setup) and then automatically add the ESXi host that you had just bootstrapped. If you have provisioned other ESXi hosts that have not been configured with vSAN, you can also include that into the API request. The really nice thing about this "post" API is that rather than having to call into several existing vSphere APIs to setup vCenter Server, you can do all of that just using this single API!

To help demonstrate the use of the these new vSAN Management APIs, I have created a simple Python script which exercises these new APIs called The script supports three operations: listdisk, prepare and post.

Here is an example of running the listdisk operation which will list all available disks that are currently not in use and can be used by vSAN:

python -s -u root -p VMware1! --operation listdisk

Once you have the disks information, you can then use the prepare operation as shown below to bootstrap your ESXi host:

python -s -u root -p VMware1! --operation prepare --cache "SAMSUNG MZVPV128" --capacity "Samsung SSD 850"

At this point, you are now ready to deploy the VCSA using the CLI Installer. Once that has completed, you can complete the process by using the post operation and provide the required parameters to setup vCenter Server including the ESXi host that you had just bootstrapped so it can be added to the vCenter Server inventory as shown below:

python -s -u [email protected]' -p VMware1! --operation post --datacenterName "VSAN-Datacenter" --clusterName "VSAN-Cluster" --esxName --esxUsername root --esxPassword VMware1!

Once the post operation has completed, you will have a fully configured vCenter Server which you can check by logging into the vSphere Web Client. Pretty slick, if you ask me!

Project USB to SDDC - Part 3

OK, the wait is finally over! In this final article, we will now walk through the process of getting access to this project as well as how to get this deployed in your own environment. For those that just want to see the code, you can find it at the Github project below:

Github Project:

Below are the details outlining the environment and software requirements as well as the instructions to consume this in your own home lab environment. The content below is a subset of what is published on the Github project, but this should get you going. For more details, please refer to the Github project and if you have any issues/questions, feel free to file a Github issue.

Environment Requirements:

  • USB key that is at least 6GB in capacity
  • Access to either macOS or Linux system as the script that creates the USB key is only supported on these two platforms
  • No additional USB keys must be plugged into the hardware system other than the primary installer USB key
  • Hardware system must have at least 2 disk drives which can either be 1xHDD and 1xSSD for running Hybrid vSAN OR 2xSSD for running All-Flash vSAN
  • Both Intel NUC 6th Gen and Supermicro E200-8D and E300-8D have been tested with this solution. It should work with other hardware systems that meet the minimum requirements but YMMV

Software Requirements:

Note: Other ESXi / VCSA 6.5.x versions can also be substituted, this includes the latest ESXi 6.5d (vSAN 6.6) release which I have also verified myself.

Continue reading

Updated Nested ESXi 6.0u3 & 6.5d Virtual Appliances

I finally found a bit of "extra" spare time to update my Nested ESXi Virtual Appliances to support some of the recent releases of ESXi, 6.0 Update 3 and 6.5d, which enables customers to easily and quickly deploy vSAN 6.6 in their environment for testing, development or learning purposes. If you have not used this appliance before, please have a look at this article which goes into greater detail on how to deploy and use the Nested ESXi VA.

As part of this update, I also spent some time looking at all the feedback that I had received from the community since releasing the VA and I took this opportunity to also add some nice enhancements that folks have been asking about 🙂 Jump towards the bottom to see what's new. To reduce the number of VA's that I need to manage and due to usage, the following VA's have recently been decommissioned. I only plan on supporting the latest versions which you can find in the links below.

Decommissioned VA's:

  • ESXi 5.5 Update 3 (Nested_ESXi5.x_Appliance_Template_v2.ova)
  • ESXi 6.0 Update 2 (Nested_ESXi6.x_Appliance_Template_v5.ova)
  • ESXi 6.5 GA (Nested_ESXi6.5_Appliance_Template_v1.ova)

New VA's:

What's New:

  • Support for DHCP 
    • I know this might sound pretty basic but before you were required to specify a static IP (even if you had DHCP). By default, you no longer need to fill out the networking section as highlighted in yellow below.
  • Support for default root password
    • You no longer need to provide root password, it will default to the famous VMware1! The issue in the past was that I had randomly generated a password which I discarded and when the customization failed, it was very difficult to troubleshoot since I do not actually have the password 😉 Hopefully we do not have any other bugs, but this will make debugging easier and also reduce the amount of input if you want to quickly spin up an ESXi instance.
  • Support for VLAN ID
    • Though not a huge number of requests, there were still of you who asked for 802.1q (trunk) support on Management VMkernel interface. This is an optional field and obviously this is only applicable if you provide a static IP Address.
  • Automatic removal of Customization VIB
    • As some of you may or may not know, the way in which these OVF properties are processed within the Nested ESXi instance is a special firstboot script which reads in these values and then applies the ESXi customization. If everything is successful, there really is no use for this to exists further and although you could set a certain advanced setting to force re-customization, it was quicker to just re-deploy. With that in mind, the customization VIB is now automatically removed once its done its job. I have included a special debug option that would allow it to not be deleted in scenarios where there are issues and we need to take a look at the state of the system. With this change, you really now have a "vanilla" ESXi instance 🙂
  • Fixed dvFilter param for eth1

Hope you enjoy some of these new updates and happy Nesting!

Auditing & Automating Disabled Protocols (TLS/SSLv3) for ESXi 6.0u3 & 6.5 using PowerCLI

A couple of weeks back, I had received a question from one of our TAMs in regards to automating the disablement of specific TLS/SSL protocols for their ESXi 6.0 Update 3 hosts. As of vSphere 6.0 Update 3 and vSphere 6.5, customers now have the ability to completely disable TLS 1.0, TLS 1.1 and SSLv3 using the new TLS Reconfiguration Tool. Mike Foley did a nice write up here if you are interested in more details.

The TLS Reconfiguration Tool works well if you have the same version of vSphere for both your vCenter Server and ESXi host, but has challenges when you are in a mixed environment like this particular customer. In their environment, they are running vCenter Server 6.5 and ESXi 6.5 Update 3 which prevented them from using the TLS Reconfiguration Tool as this is a limitation with the tool today.

UPDATE (05/11/17) - Added support for ESXi 6.5 hosts as well

Given the TLS Reconfiguration Tool was written in Python, I was able to take a closer look at its implementation and I found that the settings that controlled the disabled protocols were just merely a few ESXi Advanced Settings which meant that this could be automated using standard vSphere Automation Tools that our customers were already familiar with. As part of this exercise, I also discovered the tool currently does NOT support disabling TLS/SSLv3 protocols for the Small Footprint CIM Broker (SFCB) service which is also required if you want to be in full compliance for a particular TLS protocol. Although there is not a direct SFCB API that allows you to manage the sfcb.cfg configuration file, there is still a way we can automate this without requiring SSH to the ESXi host which would technically be the alternative. Lastly, I was a bit surprised to see the TLS Reconfiguration Tool did not have a "query" option for listing the current disabled protocols for all ESXi hosts, but they do have it for vCenter Server itself.

To help this particular customer and others who may have specific TLS compliance requirements, I have created the following PowerCLI script called ESXiDisableProtocolConfiguration.ps1 which includes the following two functions:

  • Get-ESXiDPC - Retrieve the current disabled protocols for all ESXi hosts within a vSphere Cluster
  • Set-ESXiDPC - Configure the specific disabled protocols for all ESXi hosts within a vSphere Cluster

Continue reading