Warning:
Remember for sysprep to join a VM to the domain you will need to have DHCP on your network where your vApp resides – alternatively you will need to use Sysprep to change the SID, and then use a script and something like netdom.exe or PowerShell to add the VM to the domain. This is because ALL sysprep “clients” start their life as DHCP clients, before any static address is assigned to them. This is true in vCenter and vCD.
One of things that foxed me recently was why after importing an .OVF template into vCloud Director catalog are all the guest customization options greyed out? I first I thought it was a problem with my .OVF file, and then I thought perhaps it was user rights issue.
Joining a computer to the domain using vCloud Director Customization
It turned out I had problem with my expectations. Really these options open out once you have created a vApp FROM the catalog. Once the vApp has “deployed” its possible to edit these values on each VM within the vApp and modify them. That can include such things as forcing a complete guest customization or a reset of the administrators password. What I do like about this customization is the way vCloud Director can pick up on the Organization’s OU location as well. My plan was to have VMs within a vApp join the domain automagically without having to do by hand – and to also ensure they were dropped in the right OU.
With this configuration (Use Organization’s domain) above vCD use the LDAP configuration set for the Organization (held in OrganizationName, Administration, Settings, LDAP) and uses the account specified in the System LDAP configuration (System, Administration, System Settings, LDAP)
In my case I wanted to drop the computer object into a sub-OU called “Servers” at this path ou=servers,ou=CorpHQ-Organization,DC=corp,DC=com rather than the computer accounts being located in the CorpHQ-Organization OU. So I overrided the Organization’s domain with specific path, and I also did a spot of delegation in Active Directory to allow the account called “joindom@corp.com” to have the right’s to join computers to the corp.com domain, but specifically only to the path ou=servers,ou=CorpHQ-Organization,DC=corp,DC=com
However, for this to work with my vApps on the Organization Network, I need to configure the NAT on the Edge Gateway to allow communications to the domain controllers (something I did a while back). Additionally, I needed to enable DHCP on the networks where my vApps reside. This can be in one of two places – either on the vCNS Edge Gateway that services the Organization Network or the vCNS Edge Gateway that services the vApp Network.
For the Organization Network (OrgName, Administration, Cloud Resources, Virtual Datacenter, vDCName, Edge Gateways, right-click Edge Gateway, Edge Gateway Services)
For the vApp Network (OrgName, My Cloud, vApps, select vAppName, Networking tab, right-click vApp Network, Configure Services)
Join the domain by script – without requiring DHCP:
Now, admittedly it could be the case that your “not allowed” to run DHCP on your network where your virtual servers reside. For me that’s a bit funny for a couple of reasons. Firstly, the management of the DHCP lies within the scope of the person who manages the Organization or the vApp – not the network guys. Who are these network guys to tell me what I can do in my own vApp? Secondly, by using vCloud Director were all ready handing out network IDs in the shape of VLANs, vCD-NI, Portgroup or VXLAN enabled networks – how’s a little DHCP going to harm things. Thirdly, I regularly use PXE to either install ESX (UDA or EDA are good virtual appliances for this!) or for AutoDeploy. PXE requires DHCP – so what gives…?
But seriously, I know that some shops see DHCP on server network as some cardinal sin. For that reason the other option is to use scripted methods.
Firstly, you need create this directory structure on the source VM that will become your vApp Template: C:\Windows\Setup\Scripts. On a Windows 2008 R2 server I found that the scripts directory did not exist and I had to create it.
Next, create .cmd file called: SetupComplete.cmd
Finally, edit this cmd file with notepad and add the required entries for the netdom.exe command:
netdom.exe join %COMPUTERNAME% /DOMAIN:corp.com /OU:ou=servers,ou=CorpHQ-Organization,DC=corp,DC=com /userd:corp\joindom /passwordd:Password1 /reboot
Note: Userd and passwordd are not typos. The extra D represents that this is a domain account used for joining computers to the domain/ou.
Finally my other tip for handling customization comes not from me but from Rick Vanover (and fellow vExpert) who works over at Veeam. He’s got a good blogpost on TechRepublic which shows how to use the tzutil to set the correct time zone. I thought I’d fixed this issue in my template in vCenter, but seems like the Sysprep process as triggered by vCloud Director resets the TZ to be Pacific Time. Although my bogus company Corp.com is based in New York, as I’m in the UK and the lab is in the UK, I set my TZ to be GMT. I found Rick’s article fixed my issue just fine:
http://www.techrepublic.com/blog/datacenter/set-a-windows-servers-time-zone-using-group-policy/3673
Observations:
So what’s the best way? Well, I actually like the script method. As it doesn’t require me to configure DHCP on every Organization Network or vApp Network. Enabling DHCP just once on the Organization Network is one time configuration that I don’t mind, but having it remember to do it for each and every vApp Network I create – and remembering to do that BEFORE the first power on seems to be a bit of administrative burden to me. But that’s just my opinion. I’m tempted to have Windows 2008 R2 vApp Template – one that does the join and one that doesn’t – which seems a bit excessive but the reality is not every VM I created in my lab needs to be joined to the domain. Although it can be handy because I can use the GPOs to turn off the Windows Firewall and enabled Remote Desktop Services. One thing I’ve noticed is if you take a vApp that has domain membership already, and copy that into the catalog – even when it gets customized it doesn’t seem to join the domain properly – it seems to think its existing domain membership is good enough – when actually a new computer account needs to be created in the OU. I’ve experimented with taking VMs within the vApp out of the domain before importing them into the catalog – and this seems to work much better. It means they are sysprep, renamed, and joined to the domain as net-new entities.