How to automate the deployment of an un-configured VCSA 6.5 (Stage 1 only)?

In vSphere 6.5, the VCSA deployment has changed from a "Single" monolithic stage where a user inputs all of the required parameters up front and then the installer goes and deploys/configures the VCSA. In the new VCSA UI Installer, we still continue to provide a "Single" monolithic user experience but behind the scenes, the deployment is now actually composed of two distinct stages, creatively called Stage 1 and Stage 2.

• Stage 1 - Initial OVA deployment which includes basic networking + OS password
• Stage 2 - Applying the VCSA specific configurations (e.g. External Platform Services or Embedded VCSA)

One reason why this is so useful is that in previous releases of the VCSA, if you had fat fingered say the DNS entry or wanted to change the IP Address/Hostname before applying the actual application configurations, your only option was to re-deploy the VCSA, not a very good user experience. With this new deployment model, customers now have the ability to either go through both Stage 1 and Stage2 or they can stop just after Stage 1 which would allow them to make necessary edits before continuing to Stage 2. If you decide to stop after Stage 1, then to complete the deployment, you will need to open a browser and finish the configuration using the VCSA's Virtual Appliance Management Interface (VAMI) at https://[VCSA-HOSTNAME-OR-IP]:5480

Once on the VAMI UI, you will want to select the "Set up vCenter Server Appliance" which will then launch the configuration wizard. From here, you will have the option of changing some of the settings that you had provided in Stage 1 such as the IP Address or things like NTP or enabling SSH access as shown in the screenshot below. Once you have confirmed these settings, it will be saved and then you will move onto Stage 2 to complete the configuration of your VCSA deployment.

Everything that has been discussed so far is only available in the new VCSA UI Installer. If you are using the VCSA CLI Installer, this separate Stage 1 and Stage 2 option is not directly available. I assume the thinking here is that for an automated deployment, customers would want the system to be fully operational after deployment rather than needing additional configurations.

Having said that, you can replicate the exact same behavior as the VCSA UI Installer by stopping after Stage 1 using the VCSA CLI Installer. The trick is to leverage the new VCSA CLI Installer ovftool argument pass-through capability that I had blogged about a few weeks ago. The way the VCSA UI Installer accomplishes this is by setting the following OVF property guestinfo.cis.deployment.autoconfig to false during the deployment which will halt the installer after Stage 1. A nice use case that this enables is for customers or partners (like an System Integrator) who pre-provisions vSphere environments at a central site and then ships them out to remote locations. It allows them to now pre-deploy the VCSA using a temporarily configuration and once on site, the deployment can be finalized using the site-specific information such as IP networks, DNS, NTP, etc.

Below is an example JSON on deploying an Embedded VCSA 6.5 and configuring only Stage 1. Although the VCSA CLI tool will enforce you to fill out all the VCSA specific configurations like SSO information for example, it will not be applied and you can technically pass in valid "dummy" information.

{
    "__version": "2.3.0",
    "__comments": "Sample JSON to only deploy and configure Stage1 of the VCSA 6.5",
    "new.vcsa": {
        "esxi": {
            "hostname": "192.168.1.50",
            "username": "root",
            "password": "vmware123",
            "deployment.network": "VM Network",
            "datastore": "vsanDatastore"
        },
        "appliance": {
            "thin.disk.mode": true,
            "deployment.option": "tiny",
            "name": "VCSA-6.5-Pre-Staged"
        },
        "network": {
            "ip.family": "ipv4",
            "mode": "static",
            "ip": "192.168.1.151",
            "dns.servers": [
                "192.168.1.1"
            ],
            "prefix": "24",
            "gateway": "192.168.1.1",
            "system.name": "192.168.1.151"
        },
        "os": {
            "password": "VMware1!",
            "ssh.enable": false
        },
        "sso": {
            "password": "VMware1!",
            "domain-name": "vghetto.local",
            "site-name": "virtuallyGhetto"
        },
        "ovftool.arguments" : {
            "prop:guestinfo.cis.deployment.autoconfig" : false
        }
    },
    "ceip": {
        "settings": {
            "ceip.enabled": false
        }
    }
}

Once successfully deployed, you can then go to VAMI UI to edit the existing configurations like networking which is also available using the new VAMI REST API. If you need to update the IP Address of the VCSA to a completely different network, you can also login via the console and use the following VAMI CLI:

/opt/vmware/share/vami/vami_set_network STATICV4 172.30.0.200 255.255.255.0 172.30.0.1

You can also leverage the Guest Operations API (also available via PowerCLI and other SDKs) to perform this operation without the need of enabling SSH as an alternative. For Stage 2 configurations, you will need to use the VAMI UI as there is currently not an API for these operations. This is something the VCSA Engineering team is looking into for the future.