PowerCLI Workspace ONE

PowerCLI Issue Deploying vApps from Content Library

So I was hoping to have a productive weekend playing around with the new Workspace ONE Access 21.08 appliance until I ran into a couple snags. The first I ran into while configuring the new appliance and it turns out it was recently added to the “Known Issues” section of their release notes. You cannot set the initial passwords because the appliance complains the root password has expired and needs to be reset to continue. No fun! I guess I will have to wait until they either post a public solution or release a new appliance.

So I decided to work on my Workspace ONE Access deployment PowerCLI script and add a couple new features, clean up some code, etc. In one use case I run into, I have a VDI workstation available to me. I am having to download the OVA to the local hard drive of the VDI desktop and then deploy the vApp with the script. I thought it would be better if I could just deploy the appliance directly from a Content Library on the vCenter. That way, I could run my script locally, but not need to download the OVA first.

Initially, I looked through the PowerCLI Reference to see what options were available to me to deploy a vApp from a Content Library. I had been using the Import-VApp to load the vApp from the local hard drive:

Import-VApp -Source $wsoSourceOva -OvfConfiguration $OVFConfig -Name $vmName -VMHost $vmhost -Location $cluster -Datastore $ds -DiskStorageFormat thin -Confirm:$false

However, that command doesn’t have an option to pull a source from a Content Library. I looked around and found that New-VApp does have an option to import from a ContentLibraryItem, but it won’t allow you to provide OVF Configuration settings as part of the call.

Looking around the Command Reference, I found in New-VM an option to 1 – pull from a ContentLibraryItem and 2 – provide an OVF Configuration to configure the VM. Victory! (or so I thought…) I adjusted my script and provided the following command:

New-VM -ContentLibraryItem $wsoContentItem -OvfConfiguration $OVFConfig -Name $vmName -VMHost $vmhost -Location $vmFolder -Datastore $ds -DiskStorageFormat Thin -Confirm:$false

I’m still leveraging the same options and settings from my first call, which simplifies the script setup. However, every time I ran the script, the resulting vApp would have the following settings:

Notice anything missing? Namely all of the network settings. Which in the case of the Workspace ONE Access appliance means it defaults to DHCP. This is not what I wanted to do at all. Out of curiosity, I ran the script with the exact same OVA stored locally, with all of the same settings and commands, but using the Import-VApp command and the following happens:

Everything is set the way it was advertised to be. Frustration levels were starting to rise. Especially since I couldn’t find any reason for the difference. I did note that the keys specified in vCenter do not match the keys in the vApp’s OVF Configuration. When I tried switching the keys to the ones specified in vCenter, it errored out on those calls.

So I went to the VMware Communities pages. First for Workspace ONE, and then for PowerCLI once I realized the error wasn’t in the appliance, but in the PowerCLI modules. After some great feedback from LucD, I submitted a Feature Request to the PowerCLI team to fix this discrepancy. Please check out the request and if it’s something you might find useful, please vote on it. That will help increase it’s priority and likelihood of being implemented.

That was my weekend in full. Overall, not very productive, but I did manage to ferret out a possible bug in PowerCLI. Happy #HomeLabbing

Leave a Reply