Hi guys,
we had exactly the same issues in our environment and I just want to summarize the gathered information from some blog articles (thank you all!) needed to fix the issues here:
https://communities.vmware.com/thread/417865?start=0&tstart=0
- This describes the missing value in the extended vApp parameter „vm.vmname“ but DID NOT fix our issue. However it may be the cause for other (customer's) problems!
http://www.virtuallypeculiar.com/2016/05/unable-to-connect-vdp-61-to-web-client.html
- This article led us to the „final fix“ – but as you can imagine we won’t take the risk of installing packages from "unreliable sources" in our production environment…
After some more time of searching I found your question / link here:
https://communities.vmware.com/thread/533954?start=0&tstart=0
- It's some kind of unedifying that the discussion around this (imho) major incident was started several months ago and the vmware support is still struggling with advices on that,
but the customers involved pointed out that the issues are connected to the use of distributed switches (which I couldn’t imagine so far…) - thank you all for that!
Though the title of the linked KB article in the blog replies (29th of July) is rather misleading – and therefore hard to find for customers with that issue – it has done the trick:
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=21456...
Hopefully the mentioned bug get’s fixed soon in a new VDP / vCenter release or patch and moreover I hope that the support team is able to associate upcoming issues like this with the known bug.
It would be very helpful to have a KB article on this which is not only addressing deployment issues but issues with VDP and the use of distributed switches!
Kind regards, pw
