I've recently been working on some automation for deploying SQL and SharePoint for a project I'm working on and ran into an issue that I don't believe I've ran into before. To begin the process of figuring out the recipe for the automation scripts I'm building using vCloud Automation Center I began working through the process using the normal process of deploying templates from vCenter. A dependency for my in-guest scripts to run was that the virtual machines were added to the domain during deployment. Luckily (but not absolutely necessary), vCenter guest customization can do this for you. So during deployment I use guest customization to add my virtual machines to my test domain (test.local).
Now, I have a knack of taking things out of context, or simply believing that most people don't know what they are talking about and often want A when they ask for B, and as a result of this disorder that I possess I do things like the following.
In the screenshot below you can see that we have the option to either keep the new virtual machine in a workgroup called "WORKGROUP", or add it to an active directory domain. As previously mentioned, I have to be in a domain, so I went ahead and specified my domain, test.local. I then needed to provide credentials that have the right to add a machine to the domain, in this case I'm using the domain admin account, test\administrator. I provided the password and that should do it right? Well, not so much. What ended up happening was that my virtual machine was added to a workgroup called TEST.
So, setting my disorder aside, I decided to leave off the qualifying realm from the username, and just provided the username of "administrator", with the password of the domain admin account. This worked. Windows itself will make a distinction when you specify usernames like this but there seems to be something in the XML that this wizard creates, or in sysprep that doesn't care for the syntax. In either case, I've now documented it and so I will never forget this again.
Enjoy.
-alex