Similar to VCF Management Services (VCFMS), VCF Automation (VCFA) can also be deployed to a non-management network using an API workflow. A typically deployment workflow is to first upgrade to VCF 9.1, deploy VCFMS and then deploy VCFA as a Day-N operation using the new VCF Operations Fleet Lifecycle Management (Fleet LCM) capability, located within VCF Operations under Build->Lifecycle->VCF Management.

When using the Fleet LCM UI to deploy VCFA, you will see that the required IP address input uses a CIDR format. This is not ideal for VCFA, which requires exactly 5 IP addresses for the VCF services runtime; the smallest CIDR that meets this requirement is a /29, which ends up consuming 8 IP addresses.

The good news is that we can use the Fleet LCM API to select an alternative vSphere-based network (VLAN or NSX Overlay) and we also get added benefit to use an alternative IP allocation method, which would allow us to specify the exact number of IP Addresses that is required!
Note: This solution is only applicable for brand new deployments of VCFA, for existing Aria Automation 8.x or VCF Automation 9.0.x/9.1.x deployments, the upgrade workflow will use the existing network that VCFA is deployed on and will availabled IP Addresses from that network.
This combined deployment approach means you do not have to leverage another API if your end goal is to have both VCFMS and VCFA reside on the same non-management network. However, if you need to deploy VCFA onto its own isolated non-management network, then the solution in Scenario 1 should be used.
Scenario 1
This solution will be using the Fleet LCM Component Validation and Component Create API. To assist users with this API workflow, I have created PowerShell script called fleet_lcm_deploy_vcf_automation_to_non_management_network.ps1 that you can easily use after updating the variables within the script with your desired values.
You will need to provide similar input as the Fleet LCM UI which includes: VCFA FQDNS along with list of IP addresses you wish to use (instead of CIDR), VCFA credentials and the VCFMS and VCF Fleet FQDN for API accessing the LCM Fleet API. You will also need to provide the name of the VCF Instance name which can be found by logging into VCF Operations and navigating to Operate->Inventory and copy the label.
Note: Make sure your Fleet Depot Service is connected to an Online/Offline Depot and that it has successfully synced VCF metadata and VCF binaries for VCFA which includes the VCD Migration Engine component before starting your deployment or will fail due to missing binaries.
For specifying the vSphere Portgroup/NSX Overlay, you will need to define the Gateway CIDR (e.g. 172.30.70.1/24) and MoRef ID. The easiest way to fetch this value is to use PowerCLI Get-VirtualPortGroup cmdlet and make a note of the value under the key column. In my example, I am deploying to a Distributed Virtual Portgroup called DVPG_FOR_FLEET_MANAGEMENT and the MoRef ID is dvportgroup-58
![]()
By default, the script will only run the validation API and not actually perform the deployment as shown in screenshot below.
![]()
Once you pass the validation, you can update the variable $ValidateOnly to false to start the deployment, which will also run through the validation.

Once the deployment has begun, you can login to VCF Operations and navigate to Build->Lifecycle->VCF Management->Tasks to monitor the progress of the deployment.

For those interested, here is a complete working JSON payload for deploying VCFA onto a non-management network:
{
"componentSpecs": [
{
"componentType": "VCFA",
"deploymentType": "VspComponentSpec",
"sddcLcmId": "f8bdbc5c-be7f-4034-bc1c-a882d4ff65a6",
"fqdn": "auto03.vcf.lab",
"version": "9.1.0.0",
"configSpec": {
"adminSystemPassword": "VMware1!VMware1!",
"size": "small"
},
"vspClusterSpec": {
"deploymentType": "VspClusterSpec",
"sddcLcmId": "f8bdbc5c-be7f-4034-bc1c-a882d4ff65a6",
"platformFqdn": "vcf-asr03.vcf.lab",
"systemUserPassword": "VMware1!VMware1!",
"size": "small",
"ipv4Pool": {
"addresses": [
"172.30.70.65",
"172.30.70.66",
"172.30.70.67",
"172.30.70.68",
"172.30.70.69"
]
},
"networkMoId": "dvportgroup-58",
"gatewayCidrIpv4": "172.30.70.1/24"
}
}
]
}
Scenario 2
This solution builds on my earlier work of deploying VCFMS to non-management network using the SDDC Manager API and we are simply appending the VCFA specification to include that in the deployment specification.
To assist users with this advance workflow, I have created PowerShell script called sddcm_deploy_vcf_management_service_to_non_management_network.ps1 that you can easily use after updating the variables within the script with your desired values.
You will need to provide the following:
- SDDC Manager FQDN, credentials along with the vSphere Portgroup/NSX Overlay label and netmask/gateway information
- VCFMS requirements including VCF Operations credentials, SDDC Manager credentials, VCFMS FQDNs along with list of IP addresses you wish to use (instead of CIDR) and the vSphere Portgroup/NSX Overlay to deploy VCFMS.
- VCFA requirements including the VCFA FQDNs along with list of IP addresses you wish to use (instead of CIDR) and the credentials
Note: Make sure your SDDC Manager is connected to an Online/Offline Depot and that it has successfully synced latest VCF 9.1 metadata and the VCF binaries for VCFMS and VCFA which includes the VCD Migration Engine component before starting your deployment or will fail due to missing binaries.
By default, the script will only run the validation API and not actually perform the deployment as shown in screenshot below.

Once you pass the validation, you can update the variable $ValidateOnly to false to start the deployment, which will also run through the validation.

Once the deployment has started, you can login to VCF Operations and navigate to Build->Tasks to monitor the progress.
For those interested, here is a complete working JSON payload for deploying both VCFMS and VCFA onto a non-management network:
{
"vcfOperationsSpec": {
"nodes": [
{
"type": "master",
"sslThumbprint": "6B:D3:FC:4F:AC:2A:5D:0B:87:D0:71:ED:B8:92:D8:51:E9:E3:9F:50:91:1B:23:E3:B0:FC:20:EE:0F:64:A2:E9",
"hostname": "vcf02.vcf.lab"
}
],
"adminUserPassword": "VMware1!VMware1!",
"loadBalancerFqdn": "",
"useExistingDeployment": true
},
"vspClusterSpec": {
"platformFqdn": "vcf-msr03.vcf.lab",
"systemUserPassword": "VMware1!VMware1!",
"ipv4Pool": {
"addresses": [
"172.30.70.170",
"172.30.70.172",
"172.30.70.173",
"172.30.70.174",
"172.30.70.175",
"172.30.70.176",
"172.30.70.177",
"172.30.70.178",
"172.30.70.179",
"172.30.70.180",
"172.30.70.181",
"172.30.70.182"
]
},
"size": "small",
"internalClusterCidrIpv4": "198.18.0.0/15",
"instanceFqdn": "vcf-int03.vcf.lab",
"fleetFqdn": "vcf-flt03.vcf.lab",
"useExistingDeployment": false
},
"vcfManagementComponentsInfrastructureSpec": {
"localRegionNetwork": {
"networkName": "DVPG_FOR_FLEET_MANAGEMENT",
"subnetMask": "255.255.255.0",
"gateway": "172.30.70.1"
},
"xRegionNetwork": {
"networkName": "DVPG_FOR_FLEET_MANAGEMENT",
"subnetMask": "255.255.255.0",
"gateway": "172.30.70.1"
}
},
"licenseServerSpec": {
"hostname": "vcf-lic03.vcf.lab"
},
"vidbSpec": {
"hostname": "vcf-idb03.vcf.lab"
},
"fleetLcmSpec": {},
"sddcLcmSpec": {},
"fleetDepotSpec": {},
"telemetryAcceptorSpec": {},
"saltSpec": {},
"saltRaasSpec": {},
"vcfAutomationSpec": {
"hostname": "auto03.vcf.lab",
"platformFqdn": "vcf-asr03.vcf.lab",
"adminUserPassword": "VMware1!VMware1!",
"ipPool": [
"172.30.70.65",
"172.30.70.66",
"172.30.70.67",
"172.30.70.68",
"172.30.70.69"
],
"internalClusterCidr": "198.18.0.0/15",
"nodePrefix": "vcf-m01-node-01",
"size": "small"
}
}
if i do this in my production deployment, is it supported from broadcom?
Yes. https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/deployment/deploying-a-new-vmware-cloud-foundation-or-vmware-vsphere-foundation-private-cloud-/deploying-vcf-operations-and-vcf-automation-on-custom-networking/deploy-vcf-management-components-on-a-dedicated-management-network-by-using-vcf-installer.html
Works like a charm, but a shame that this is not even in the offical docs.
William: You should make L229 a configure option, as we already have VCFA 9.1.1.0100 in place
https://github.com/lamw/vmware-scripts/blob/d0c7b2638f1ae1af898ec8db4796652f78e5dff0/powershell/fleet_lcm_deploy_vcf_automation_to_different_network.ps1#L229
It works perfectly if you connect Automation to a different network than Management and if you want to use less than 10 IPs (Scenario 1).
After executing the script with PowerShell 7, we had the issue stated in https://knowledge.broadcom.com/external/article/453066 (Failed to obtain SDDC Manager token) and we solved it by following https://knowledge.broadcom.com/external/article/450375.
Then we had another issue solved by disabling the Ops proxy temporarily: https://knowledge.broadcom.com/external/article/441312/unable-to-register-components-with-vcf-o.html
Thanks William!
Homelab "3" Minisforum A2 7940 Cpu units, Upgraded VCF 902 to 9.1, next will be 9.1.1 but 1st must upgrade Automation and Log. Following the Fleet LCM process there is no upgrade of Automation but a net new 3 Appliances for automation then a data migration of your original 1 VM Automation. With VCFMS taking an additional 40 CPU and 82 GB RAM, now HA deployment with no option for "Simple" for Automation things are really tight. I know you documented a process to slim down the VCFMS post deployment, just trying to finish the upgrade to 9.1 1st.
Is the Simple model for Automation removed?
Thanks always William for your hard work.
Tom
William, I mis-spoke, you can do a simple deployment of Automation, nice, but you already knew that "smile". So I upgraded 9.0.2 to 9.1, then 9.1.1 just to learn. Scraped it all to learn the "installer" way of installing VCF 9.1.1. Really like you can deploy Edge nodes right from vCenter, it does a great job. 1st time I used the installer and installed all components it crushed my CPU's, sometimes hitting 140% util. I started over and determined I missed "esxcli system settings kernel set -s entropySources -v 2". Since, put all the tweaks in a note for VCF tweaks based upon all your information. Having it all in one place works great when you are always rebuilding to test. Deployment of VCF takes 4 hours then add 2 hours for Automation. Awesome and the CPU is running very well even during he deployment of Automation. I can't imagine trying to get all this to work without having you as an Advocate! Thank you