Thanks to a fellow colleague, Abdullah, who reached out after coming across my blog posts (HERE and HERE) on how to deploy VCF Management Services (VCFMS) and VCF Automation (VCFA) on a non-management network as part of a VMware Cloud Foundation (VCF) 9.1 upgrade. Using the same techniques, he was able to successfully deploy VCF Operations for Networks on a non-management network, which I thought was worth sharing an updated script with the broader community.
Similar to VCFMS and VCFA, VCF Operations for Networks (VON) is deployed using the Fleet Lifecycle Management (LCM) workflow in VCF Operations and, by default, both the platform and collector nodes are deployed onto the management network.

As you have probably guessed, we can use the Fleet LCM API to override this behavior and deploy VON on a non-management network!
To assist users with this API workflow, I have created another PowerShell script called fleet_lcm_deploy_vcf_operations_for_networks_to_different_network.ps1 that accepts the same input as the Fleet LCM UI including VON version, platform and controller IP Addresses along with admin credentials. Since VON does not currently run within VCFMS, it is still using the traditional appliance, the API specification needs to use the OvaComponentSpec which the PowerShell script incorporates but when specifying the non-management network information, you will need to provide other pieces of information such as the vSphere Portgroup name along with the additional the netmask, gateway and DNS/NTP information within the script.
Similar to the previous scripts, it 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.

For those interested, here is a complete working JSON payload for deploying VON onto a non-management network:
{
"componentSpecs": [
{
"componentType": "OPS_NETWORKS",
"deploymentType": "OvaComponentSpec",
"sddcLcmId": "34cf98e3-4a59-413f-8ff3-d1294aad8a7e",
"nodeSpecs": [
{
"nodeType": "PLATFORM",
"version": "9.1.0.0.25318550",
"deploymentSpec": {
"fqdn": "vcf-net02.vcf.lab",
"deploymentOption": "small",
"password": "VMware1!VMware1!",
"networkName": "DVPG_FOR_FLEET_MANAGEMENT",
"ipv4Settings": {
"address": "172.30.70.150",
"netmask": "255.255.255.0",
"addressType": "Static",
"gateway": "172.30.70.1"
},
"dnsServers": "192.168.30.29",
"dnsSuffix": "vcf.lab",
"ntpServers": "96.19.94.82"
}
},
{
"nodeType": "COLLECTOR",
"version": "9.1.0.0.25318550",
"deploymentSpec": {
"fqdn": "vcf-netc02.vcf.lab",
"deploymentOption": "small",
"password": "VMware1!VMware1!",
"networkName": "DVPG_FOR_FLEET_MANAGEMENT",
"ipv4Settings": {
"address": "172.30.70.151",
"netmask": "255.255.255.0",
"addressType": "Static",
"gateway": "172.30.70.1"
},
"dnsServers": "192.168.30.29",
"dnsSuffix": "vcf.lab",
"ntpServers": "96.19.94.82"
}
}
],
"configSpec": {
"adminPassword": "VMware1!VMware1!"
}
}
]
}
Note: The deployment size is sourced from the VCF Operations for Networks OVAs which support small, medium, large, extra_large and double_extra_large as string values.
Hi William, Where should the collector node suppose to be placed ? In local-region network like VCF Ops cloud proxy or in the same network with platform node in overlay segment ? Official documents does not mentioned any thing regarding this.
Hi William, do you have any recommendation regarding this ?
Hi William, Where should the collector node suppose to be placed ? In local-region network like VCF Ops cloud proxy or in the same network with platform node in overlay segment ? Official documents does not mentioned any thing regarding this.
Sorry, I thought I had replied back I guess not ...
You won't see a recommendation mainly as long as it has connectivity back and you're within the latency requirements. For some users, you may place the Platform within Management Network while the Collector will be closer to where collection happens