VMs not going through to domain join after customization

[MarkLomas]

Hi, we're setting up View in a lab environment.

Creating VMs on XP (SP3), based on templates (NOT linked clones) - the VM's provision, go through 'customizing' - but only some of them seem to be joined to the domain after customization is completed!

Any thoughts?

--

Mark Lomas

[MayurPatel · Accepted solution]

The first thing that comes to mind is are you deploying all your VM's from the same template and your XP template have been set to DHCP? If you have different Templates then check the NIC network label, you might have some pointing to a different VLAN or network where DHCP is not available and as a result the VM you are deploying does not have any network connectivity or has a wrong IP which cannot resolve to your Domain Controller.

MP

[MarkLomas]

Yes it's the same template - but if not DHCP, what should we set it to?

--

Mark Lomas

[Bart_Verbruggen]

You must set it on DHCP, otherwise you will have duplicat IP's on your network.

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!

Bart

[MarkLomas]

The VM Template is set to DHCP, there is no conflict. Is there somewhere I can look for clues as to why the customization is not completing the domain join?

--

Mark Lomas

[MayurPatel]

Hi Mark,

Yes, your VM which you templated should be set to DHCP (which you have), the important thing is make sure you set the correct network nic label on the VM Template. The fact that some of your newly deployed VM's are joining the domain indicates your nic settings are probably correctly. So the only place to look closely is the networking because in order for the new VM to join the domain it needs to receive a correct IP address via DHCP on the VLAN you are deploying the VM, secondly the DHCP scope must be configured correctly to issue the right router (GW) and DNS addresses for your VM to be able to resolve your AD Domain Controller.

The obvious place to check is your DHCP server, to see whether an IP address was issued to the machine which failed to joined the domain. Secondly, logon as local admin onto the VM which failed to join the domain via the console and check using ipconfig /all to see if the machine has the correct network address setting and try pinging the GW and also your Domain controller. If all is in place try joining the domain manually does this work?

MP

[Penic_Albin]

Hi Mark,

I had same issue at customer site. First think was that VMs didn't join to domain becuse i try to join them to NetBIOS domain name, this is fixed with FQDN, second issue was that VMs didn't recieve IP address fast enought. I resolve this second issue with only one concurrent deploy of VM.

AP

[MarkLomas]

OK, so it's primarily down to DHCP - we'll concentrate there.

One other issue is that, for non-persistent desktops, with all the 'destroying' and 'creating' of VMs that goes on, we end up with Computer Accounts in our domain that are disabled - and some of the newly provisioned 'replacement' VMs are getting joined under the disabled account names - and then prevent logon for the end user! Any advice on how to ensure computer accounts don't get disabled for non-persistant desktops?

--

Mark Lomas

[MayurPatel]

In my test environment where I have View setup, I created a new OU in AD called VDI and I have set this path the AD container to OU=VDI in the QuickPrep Settings so the link-cloned VM's get created in this OU as opposed to in the Computer folder.

I have not observed the problem you are seeing of machine accounts being disabled during the refreshes, the accounts are being deleted and recreated on the fly (by design). This could be due a Domain Policy setting in your case, also check that you have the correct privileges for the Domain User for View Composer if you are not using the same account as the VC administrator. Check page 104 of the Admin Guide for details on the correct permissions for the View Composer Role.

Hope this helps.

MP

Message was edited by: MayurPatel

The problem you are seeing of machines not always joining the domain could also be related to old machine names being disabled instead of being deleted.

Your problem of some machines not joining the domain could be partly related due to machine accounts existing in AD and when View tries to recreate a machine with the previous name (now disabled) and join to the domain this would fail for obvious reasons.

[MarkLomas]

Well I managed to get some closure on the issue finally.

Instead of allowing VMWare's 'customization' to join the domain, I instead configured to stay as workgroup, but then added a runonce command to the customization, to run a script I had embedded into my template, which in turn runs NETDOM. Coupled with an instruction in the customization to log on at least once automatically as the administrator, this seems to have sorted it out - when the machine is 'recycled' the new one joins the domain without the account becoming disabled.

I also managed to solve my DHCP issues by adding a command to the customisation (before my netdom script) to simply run ipconfig /renew.

Thank you all for your assistance! It has been very helpful!

--

Mark Lomas

[MayurPatel]

Mark, glad to be of help.

Just curious as to why you are running a custom script for NETDOM, in my setup I didn't need to run any customization I just used the QuickPrep within Composer and it did the job and yes for the benefit of others I had forgotton to mention to set autologon =1.

MP

[MarkLomas]

The reason I chose to try a Netdom script was that through my own research searching the web, I found a number of people advocating this approach, including several people basically saying they'd had poor results relying on VMWare customisation alone, posting such threads on these forums.

If it should indeed be possible to get VMWare customisation alone to join to the domain without resulting in disabled accounts (which my own research seems to reveal; is not a rare issue) - then are there any guidelines to follow to mitigate the problem?

Many thanks

--

Mark Lomas

[Wouter1]

We had a similar issue.

If the VM's were in the same subnet as the AD, everything worked fine.

But if the VM's were in a different subnet, they wouldn't join the domain. When the deploy was done and I joined them manually to the domain, everyhting worked fined. I solved it with a netdom script.

I never found out why they wouldn't join during the deploy, but they join fine when manually done.

Any idea?

[-TAZZ-]

Problems I had with VMs not joining the domain at different client sites were caused by:

1. Wrong version or missing Sysprep files;

2. DHCP scope out of free addresses;

3. Antivirus, firewall or malware software preventing Sysprep from working correctly;

4. Active Directory computer account already existed;

5. Local administrator account in template not blank;

6. Template VM connected to the wrong network/portgroup;

7. Account used to join the domain doen't have enough rights to join the domain.

It's a delicate process which can go wrong at many different stages.

More information regarding View can be found here:

More information regarding customization issues:

_______________________

www.VMGuru.nl

[NTurnbull]

Are there enough IP addresses left in yuor DHCP pool (reservations in mind)?

If you check a vm that does join and one that doesn't, do they both have the same IP configuration?

EDIT: Strange, as soon as I posted 10 more posts appeared, hmm...

Thanks,

Neil