barnette08's Accepted Solutions

No worries, I figured it out.  Looks like the closest equivalent is to deploy a NAT network profile so that an edge and logical switch are deployed each time a blueprint is requested - so that the duplicates don't conflict.  I would have have thought just allowing an on demand logical switch would be far less complex but the NAT allows for more capability so maybe that's why the vApp Network was deprecated.

In a distributed deployment, login to the Windows Server running as the Infrastructure Manager Server.  Run the below command with the name you need removed from the UI.  In my situation the agent was already untalked from Windows. Path:  C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data Command:  Repoutil.exe Agent-Unistall -n “dem-worker”

I worked with support today who has identified this as a bug and is already planned for a patch planned for release later this month.  The vCenters will now be listed in alphabetical order after patch.

This seems to get the job done.  Thanks for the help. $csv = Import-Csv "C:\Book2.csv" -UseCulture | %{     foreach ($line in $csv){         $oNewVM = New-VM -VMFilePath $_.VMXPath -Name $_.Name -VMHost $_.VMHost         $oNewVM | Get-NetworkAdapter -Name "Network adapter 1" | Set-NetworkAdapter -NetworkName $_.PortGroup1 -MacAddress $_.MacAddress1 -StartConnected:$true -Confirm:$false         $oNewVM | Get-NetworkAdapter -Name "Network adapter 2" | Set-NetworkAdapter -NetworkName $_.PortGroup2 -MacAddress $_.MacAddress2 -StartConnected:$true -Confirm:$false         $oNewVM | Set-Annotation -CustomAttribute Owner -Value $_.Owner     } }

Update:  After a little testing and a support call with VMware I was able to get this working with a few work arounds. 1.  The default action for a datastore cluster (without DiskFormat specified), is to deploy the same as format as the source.  I had suspected this, but didn't confirm it until a few weeks ago. 2. The VMware SDK engineer recommended running New-VM and specifying the disk format, and then Move-VM to have SDRS apply its recommendations. $csv = Import-Csv "C:\ANT_VMs.csv" -UseCulture | %{        foreach ($line in $csv){                # Connect to a vCenter                Connect-VIServer usddrmvctr1                # Clone VM From Template                $oNewVM = New-VM -Name $_.Name -Template $_.Template -ResourcePool (Get-Cluster $_.Cluster | Get-ResourcePool -Name "Resources") -DiskStorageFormat $_.DiskFormat                # Reconfigure VM                $oNewVM | Get-NetworkAdapter | Set-NetworkAdapter -NetworkName $_.PortGroup -Confirm:$false | Set-NetworkAdapter -MacAddress $_.MacAddress -StartConnected:$true -Confirm:$false                # Reconfigure VM                $oNewVM | Move-VM -Datastore (Get-DatastoreCluster -Name $_.Datastore)                # Set Annotation Owner                $oNewVM | Set-Annotation -CustomAttribute Owner -Value $_.Owner                #Power On VM                Start-VM $oNewVM                } }

mattboren - Update:  I looked back at our original thread and took note about the -portgroup vs. -networkname and used it here since I remembered the similar error.  Thanks again for all your help.  Below is my final product that seems to be working just fine. Script: $csv = Import-Csv "C:\ANT_VMs.csv" -UseCulture | %{     foreach ($line in $csv){         $oNewVM = New-VM -Name $_.Name -Template $_.Template -ResourcePool (Get-Cluster $_.Cluster | Get-ResourcePool -Name "Resources") -Datastore $_.Datastore  -OSCustomizationspec $_.Customization         $oNewVM | Get-NetworkAdapter | Set-NetworkAdapter -NetworkName $_.PortGroup -Confirm:$false | Set-NetworkAdapter -MacAddress $_.MacAddress -StartConnected:$true -Confirm:$false         $oNewVM | Set-Annotation -CustomAttribute Owner -Value $_.Owner         Start-VM $oNewVM     } } CSV Example: Template Name Cluster Datastore DiskFormat Customization PortGroup MacAddress Owner LabCloud_w2k12 vm-d01148 Cloud - Lab Cluster III (FID 30) 8000-10kSP1-LUN02 Thin LabCloud_w2012R2 vNet 10.108.26 00:50:56:2c:1b:67 zzz

I compared a working one that I had from the same customer and I found the culprit:                             <vcloud:DestinationPortRange>Any</vcloud:DestinationPortRange>                             <vcloud:DestinationIp>external</vcloud:DestinationIp>                             <vcloud:SourcePort>-1</vcloud:SourcePort>                             <vcloud:SourcePortRange>Any</vcloud:SourcePortRange>                             <vcloud:SourceIp>internal</vcloud:SourceIp>                             <vcloud:EnableLogging>false</vcloud:EnableLogging>

There were stale entries in the vCNS database that vCD was getting stuck on during the creation process.  Once engineering removed the stale entries, a repair on the PvDC and/or a recreate of the PvDC allowed the creation of the network pool to go through.

This ended up being a permissions issue.  Although I was running this as a domain admin with full control of the system, the installer only seems to run happily the local Administrator account.  I have requested that VMware update their documentation on this.

Solved: This turned out to be an array level issue related to VAAI.  We are running R31 code on our VNX storage array and 'VAAI nested clone support' didn't come into play until R32/INYO for VNX.  I have temporarily switched to FC storage since doing an upgrade right now is not an option for us, but I did some testing by mounting some NFS datastores from an INYO array to these hosts and the same tasks succeeded without issue (very quickly I might add).