Before the release of vCloud Automation Center 6.1.1, it was common to combine the use of the two below custom properties to assign a particular virtual machine to a particular portgroup/Network Path and a particular network profile:

VirtualMachine.NetworkN.Name: This custom property is used to put the virtual machine network adapter N, on the portgroup name supplied as a value for this custom property.

VirtualMachine.NetworkN.ProfileName: This custom property is used to tell the virtual machine network adapter N to obtain an IP from the network profile named in the value of this custom property.

I have seen the combined use of these two custom properties many time in the past and they seemed to work properly before vCAC 6.1.0 (It might have stopped working a bit earlier than that but I did not notice it). On the other hand using each of these custom properties on its own still work properly in vCloud Automation Center 6.1 and beyond, combining both custom properties on the same blueprint seems to produce some odd behaviors and unexpected results after 6.1. To avoid having such a problem, its highly recommended to use the newly introduced VirtualMachine.NetworkN.NetworkProfileName custom property.

VirtualMachine.NetworkN.NetworkProfileName kinda combine both custom properties in a single property. You supply it with the network profile name you want the blueprint to use when being deployed, and it will find out the portgroup/network path that network profile is assigned to and deploy the blueprint to it. This will get you to use a single custom property in place of setting each custom property independently & most importantly it works without any unexpected behaviors.

I can see some of you wondering what if I wanted to assign the same NetworkProfileName to multiple portgroups  within the same reservation, to be honest I don’t have a solution for that, but all I can say at the moment, it is not often the case as you usually want to have a different subnet per portgroup as each portgroup usually present a different VLAN. The only time you go differently is if you decided to have isolated/private networks using vCNS or NSX and at that time its a totally different game as you will probably be doing most of your network control at the multi-machine blueprint level.

I hope this help someone save time in figuring out why combining VirtualMachine.NetworkN.Name & VirtualMachine.NetworkN.ProfileName together produce unexpected behavior.