vSphere 6.5 – CLI VCSA External Deployment Walkthrough

By | January 12, 2017

The post below will walk through the deployment of an external vCenter Server Appliance (VCSA) 6.5 node and Platform Services Controller (PSC) to a target ESXi server using the command line interface (CLI) deployment method.

If you are interested in also seeing the GUI deployment or other GUI/CLI deployments, please see my post here which has links off to other individual articles for different deployment methods.

For each of the deployment methods I am providing a video as well. Please find the video for the VCSA External CLI deployment below. This has been recorded in FullHD, so best to watch it in Full Screen!


The VCSA can be deployed using either the new GUI installer or by CLI from Windows, Mac and Linux machines. After playing with the CLI a little in the lab, it has become my preferred deployment method over the GUI. A JSON file is used to define the configuration of the node(s) and then a one liner performs the deployment and configuration of the node(s) without the normal GUI “Next Next” trek.

The CLI deployment is fully supported by VMware in 6.5 and they have also done a great job of providing a number of JSON template files depending on your deployment scenario.

One thing to note is that I don’t think any of the template files have the NTP server defined. In my experience, DNS and NTP are the two biggest causes of issues when performing a deployment or upgrade. In the steps below I’ll show you where to enter the NTP settings into the JSON configuration file.

Let’s go ahead and get started.

First Steps

The first thing I do before deploying any appliance is making sure there is a DNS record with forward and reverse records. For this walkthrough I’m naming the PSC node labpsc01.lab.allford.id.au ( and the VC node labvc01.lab.allford.id.au (

Exploring the VCSA ISO

Next, let’s take a look at the VCSA ISO file that I’ve downloaded from VMware. If we mount the ISO file and then open it, you’ll see a folder named vcsa-cli-installer. Inside there, you’ll find folders for Linux, Mac and Windows, as well as a templates folder.

Let’s dive into the templates folder and take a look, as this is where the example JSON configuration files are installed. Inside the templates folder, there are subfolders for install, migrate and upgrade. The CLI tool can be used to perform a new installation, a migration from Windows VC to the appliance as well as an upgrade. Head into the install folder and you will see the JSON templates provided by VMware.

As you can see, VMware have provided template files for a number of deployment scenarios. In this walkthrough we’re going to be using two of these templates:

  • PSC_first_instance_on_ESXi.json – This will define the configuration for the first external PSC in a vSphere SSO domain
  • vCSA_on_ESXi.json – This will define the configuration for a vCenter Server being pointed to an external PSC

I’m going to copy these files from the ISO into C:\temp so I can edit them.

Create JSON files

With the JSON configuration files, you can go ahead and open these in any text editor to make the changes required. There is a bit of a description for each setting as to what is required. I recommend watching the video at the start of this post as I walk through each of the settings. Although you can open in a text editor, I came across a neat JSON online editor (http://www.jsoneditoronline.org/) that I show you in my YouTube clip as well.

I’ve put the output of my completed JSON files for the PSC and VC nodes below below. I’ve also entered in a section for the NTP server as well, which I recommend you do too. Make sure to put the comma on the line above the NTP.Servers entry and save the JSON file.

The vSphere 6.5 documentation contains information for all of the settings that can be used within the JSON file – https://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.install.doc/GUID-457EAE1F-B08A-4E64-8506-8A3FA84A0446.html



Using vcsa-deploy

Now that we have JSON files that specify the configuration of both of the nodes, we can dive into running the CLI utility to verify the data in the configuration file is correct and then move onto deploying the appliances.

Open up a command prompt and browse to the following location, where the drive represents the VCSA ISO file we mounted earlier (for me this is E:\) – E:\vcsa-cli-installer\win32

Run the following command to show the help and available options for the install configuration of the tool:

vcsa-deploy.exe install -h

Verify the JSON Files

This step is absolutely optional, you can just skip straight to deploying if you like, but I wanted to show that there is functionality to validate the file prior to attempting to deploy the VCSA.

Run the following commands to perform a verification of the JSON configuration files. With these switches we are acknowledging the CEIP (–acknowledge-ceip), accepting the End User License Agreement (–accept-eula) and suppressing a warning if the target ESXi node doesn’t have a valid SSL certificate installed (–no-esx-ssl-verify). The –verify-only switch determines that we just want to validate the configuration file and the details for the target ESXi node are correct. After running the below, you’ll be prompted to enter the password for the root account for the target ESXi node.

As you will see towards the bottom of the screenshot, the verification completed successfully, so we know that the data and ESXi host details we have provided in the JSON file for each node is valid.

Verify PSC:

vcsa-deploy.exe install –acknowledge-ceip –accept-eula –no-esx-ssl-verify –verify-only c:\temp\PSC_first_instance_on_ESXi.json

Verify VC:

vcsa-deploy.exe install –acknowledge-ceip –accept-eula –no-esx-ssl-verify –verify-only c:\temp\vCSA_on_ESXi.json

Deploy and Configure Appliances

It’s now time to run the command that will actually do the deployment for us. The commands below are similar to the above, but without the verify switch (–verify-only). This instructs the CLI utility to perform the deployment of the appliances. After running the below, you’ll be prompted to enter the password for the root account for the target ESXi node again.

Once these are started, go and grab a beer, as it will take around 15 minutes to deploy, configure and for the services to start up on each node.

Deploy PSC Node

vcsa-deploy.exe install –acknowledge-ceip –accept-eula –no-esx-ssl-verify c:\temp\PSC_first_instance_on_ESXi.json

Deploy VC Node

vcsa-deploy.exe install –acknowledge-ceip –accept-eula –no-esx-ssl-verify c:\temp\vCSA_on_ESXi.json


After the nodes have been deployed, we can go ahead and launch a browser to the vCenter Server and log in to the web client, where you can see that in this deployment we have two nodes; a Platform Services Controller and a vCenter Server.


As you can see, once you know how the deployment works this can become very powerful and easy to use. Entering a few details into the JSON file and then kicking off the deployment is much quicker than having to walk through the GUI installer and  the CLI deployment is required in my opinion if you are doing a lot of lab work.

I hope this post has been helpful for you and thanks for reading.

7 thoughts on “vSphere 6.5 – CLI VCSA External Deployment Walkthrough

  1. Daniel

    This is great, thanks for doing it! Two quick questions:

    1. If you are deploying multiple PSCs I assume you just run the PSC section a 2nd time (with different IPs and names of course).

    2. Have you tried running both of these as a single “script”? I assume the PSC services are started by the end of the PSC deployment, so by the time the vCenter deployment is ready to contact it during install it would succeed?

    1. Matt Post author

      Hi Daniel,

      No worries at all. Glad it was helpful!

      1. Yes that’s correct, but for the second PSC on wards you need to use a slightly different template. In the templates folder on the VCSA ISO, you will notice there is “PSC_first_instance*” and then “PSC_replication_on*”. When deploying the second PSC (or 3rd, 4th, etc), you need to use the second template of “PSC_replication_on*”. The difference is that these templates have a property of “replication-pertner-hostname”, where you specify the PSC name of the PSC you want this newly deployed PSC to replicate with.

      2. Yes, these can certainly be scripted. In fact, William Lam wrote a script to deploy a nested vSphere environment for lab purposes and I made some enhancements and changes. The details, including links to William’s original script can be found here – https://virtualtassie.com/2017/additions-to-vghetto-automated-vsphere-lab-deployment/

      Cheers, Matt.

  2. Wesley

    I’m a big fan of anything CLI so I find this post extremely informative. I”m used to using the GUI method of deploying vCSA. Will using CLI bring about any advantages? Is deployment via CLI faster than using GUI?

    1. Matt Post author

      Hi Wesley,

      Thanks for commenting.

      It’s probably one of those “it depends” type of things. If you work for a single organisation and don’t find yourself deploying many PSC or vCenter Server nodes, then there probably isn’t a huge operational benefit for you by doing the CLI based deployment over the GUI based deployment.

      In terms of “speed”, I’d say yes, the CLI based deployment would overall be faster. It’s not faster to deploy the actual machines or anything like that, but within a minute or so you can have a JSON file filled out from the template, kick off the CLI installer and then come back in 15 minutes and you have your machine fully deployed. Deploying via JSON (CLI) also allows you to document that JSON file and you know how your environment was deployed.

      When I’m doing testing in my lab, I often find myself spinning up 4-6 PSC / vCenter Server nodes for a test environment. The CLI based deployment allows me to spend 5 minutes getting some JSON files ready, and then I deploy the nodes with a simple “foreach” loop in Powershell, come back in an hour or so and everything is spun up for me ready to go.

      It also allows you to start thinking about other scenarios where the CLI deployment of vCSA is a part of a larger script or automated deployment, such as William Lam’s automated lab deploy script – https://github.com/lamw/vghetto-vsphere-automated-lab-deployment

      So, as I started with, the advantages come back to what you’re trying to achieve and that will determine if the payoff is worth it for you. I’d encourage you to try the CLI based deployment method and let me know your thoughts on the GUI vs CLI deployment options.

      Cheers, Matt.

  3. Keerthi Vardhan

    Hey Matt,

    It’s a wonder and clear article. Thanks for sharing it.
    Is there any way we can re-use the template to re-deploy more vCenters ? To be precise, is there any way we can pass some of the varying parameters on CLI , and the rest in JSON, so that we can re-use the same template for additional vCenter deployments to the same vCenter (e.g in cases we want to deploy more embedded PSC/vCenter) ?
    Appreciate if you can help with providing some inputs in such cases.

      1. Keerthi Vardhan

        Thanks Matt, The doc has some cool info on deploying multiple vCenters which is useful to deploy external PSC and ELM configurations. Though, that is half of what I needed, the other half is to have control on deployment parameters. Say, for example, in a lab environment, we’d have most common configuration parameters to deploy multiple vCenters. However, is there a way where we can have just one template for all the common/optional parameters and then provide the remainder varying parameters through CLI; like system.name, ip, appliance name etc. I thought it would be nice if we can wrap a lot of common parameters and re-use the template for varying deployments on the go. Appreciate your time with this.!
        – Keerthi.


Leave a Reply

Your email address will not be published. Required fields are marked *