We are noticing 2 issues with Windows VMs in our vCD 1.5 and want to know if this is a bug in 1.5 and if it is solved in 5.1 ... or is this expected behavior and has anyone found a solution as users are going to do this and torch their machines and may be angry when they perform a hostname change.
We have also noticed that during this, the random admin password claims to be reset, but is not and unless you write down the old password, you are effectively locked out as the AD trust is also broken.
Here is clarifications from a co-worker in a ticket we opened with GSS:
Issue 1: The initial domain join is handled by vCloud Director using the customize guest settings.
This works without issue. The issue occurs when you rename the computer using the vCD
interface (with the machine powered off), when you power it back on, it changes the
computer name and reboots. This should either follow the correct method for
a domain joined machine (using the existing credentials it used to join in the
first place) or simply fail if that method isn't supported (so we can
instruct users to do it manually or script a solution). The issue here is that it shouldn't
do this action if it doesn't now how to correctly handle it, otherwise it leaves the
machine in an unusable state due to broken trust with AD. Issue 2: I'll give you steps to reproduce the password reset issue. Power down an already customized
domain-joined Windows VM, rename the VM to something else, power it back on. At no point
should this ever need to change the admin password (the one it had set initially) but it shows a
new password within the vCD interface. I guess the main issue is the fact the new
password doesn't actually work, and in combination with issue 1 from above, the VM is basically
unusable if we don't have the original admin password.
Suggestions?
Regards,
dion