Creating vCloud Director 5.1 direct org vDC networks using PowerCLI

Our networking team recently presented us with a new network to be used in vCloud Director (vCD) as an external network.  Each vCD organization would have access to the external network via a direct org vDC network.  I didn’t really feel like adding these networks to each org by hand so I reached for PowerCLI’s New-OrgNetwork commandlet only to find out that it can only be ran against vCloud 1.5 and lower.  This makes sense because org networks were changed to org vDC networks as of vCloud 5.1.  I thought there must be a new commandlet named New-OrgVdcNetwork, but there isn’t.

Google led me to the following links.  The first one covers isolated networks and the second one covers routed networks.
I needed direct networks and figured it would be a simpler case than either isolated or routed.  My problem was even easier because every org has access to the same underlying vCenter resources and the org vDC networks were to be added to each org vDC in every org.  If your situation is different, it may be more difficult.

# vCD External network that the org vDC networks will connect to.  
$externalNetworkName = 'External VLAN7' 

# Each org vDC network will have the format of "{org name} Direct VLAN7"
$orgVdcNetworkPostfix = ' Direct VLAN7' 
$orgVdcNetworkDescription = 'blah'

# Make the network shareable to other org vDCs in the org.  
$isShared = $true

# Retrieve the external network
$externalNetwork = Get-ExternalNetwork $externalNetworkName

# For each org in vCD, get each org vDCs in the org and create the org vDC network.
Get-Org | % { 
  $org = $_
  Get-OrgVdc -org $org | % {
    $orgVdc = $_

    # Create a new org vDC network
    $orgVdcNetwork = new-object 'VMware.VimAutomation.Cloud.Views.OrgVdcNetwork'
    
    # Create a new org vDC network configuration object.  This is where we will store some of the configuration options. 
    $orgVdcNetwork.Configuration = New-Object 'VMware.VimAutomation.Cloud.Views.NetworkConfiguration'
    
    # Set the new org vDC's parent network to the external network's reference.
    $orgVdcNetwork.Configuration.ParentNetwork = $externalNetwork.href

    # Set fence mode to bridged, which is direct within vCD's UI
    $orgVdcNetwork.Configuration.FenceMode = 'bridged' 
    
    # Create new ipscopes object.
    $orgVdcNetwork.configuration.ipscopes = new-object vmware.vimautomation.cloud.views.ipscopes
    
    # Since we are using a direct/bridged network, we won't be specifying any ipscopes because we will just use what is configured on the vCD External network.
    $orgVdcNetwork.configuration.ipscopes.ipscope += $externalNetwork.ExtensionData.Configuration.IpScopes.IpScope
    
    # Set remaining options
    $orgVdcNetwork.isShared = $isShared
    $orgVdcNetwork.Name = $org.name + $orgVdcNetworkPostfix
    $orgVdcNetwork.Description = $orgVdcNetworkDescription

    # Since the CreateNetwork method is in the org vDC's view object, we need to get the view (extension data (I think it's the same))
    $orgVdcView = $orgVdc.ExtensionData
   
    # Create our network and store the result, which should be the newly created network. 
    $result = $orgVdcView.CreateNetwork($orgVdcNetwork)
  }
}

This probably won’t be exactly what you need, but you should be able to take pieces of it to accomplish what you need.


vCloud Director wipes out DNS search suffixes in Windows upon customization

I noticed that in vCloud Director 5.5.1.2 (not sure about prior versions) that when you perform guest customization on a Windows VM (not sure about Linux) that the DNS suffixes for the NIC are removed and replaced with the DNS suffix of the network that the VM’s primary NIC is connected to.   This was causing an issue with Windows activations because the DNS srv records were not in the DNS domain that was being applied to the vCloud VMs.  This caused the VMs to be unable to find a KMS server and activate Windows.

Here are the DNS suffixes that I’m referring to under the NIC’s properties

2014-07-16_20-49-06

2014-07-16_20-48-56

2014-07-16_20-48-46

The workaround was to apply all of the DNS suffixes after postcustomization using Customization Script section on the VM’s Guest OS Customization tab.

if "%1%" == "precustomization" (
goto end) else if "%1%" == "postcustomization" (
reg add HKLM\System\currentcontrolset\services\tcpip\parameters /v SearchList /d domain1.vmware.local,domain2.vmware.local,domain2.vmware.local /f
)
:end

 This added all three domains to the search list and allowed the VM to find its KMS server and activate.