Virtual Machine deployed from template fails to join domain

[Sugna]

I am using vCenter 2.5 Update 3 and I am having problems deploying a template using a Customization file that uses a custom sysprep answer file. The Virtual Machine builds and completes all the customizations from the custom sysprep answer file with the exception of joining the domain.

The section of the custom sysprep answer file that should join the domain looks like this:

CreateComputerAccountInDomain=Yes

JoinDomain = "TEST.LOCAL"

MachineObjectOU= OU="Workstations",OU="Test",dc="TEST",dc="local"

DomainAdmin="TEST\xyzaccount"

DomainAdminPassword="password"

When I however look at the $winnt$.inf, which is created during the customization process the sections of the custom sysprep answer file that should join the domain now looks like this:

CreateComputerAccountInDomain=Yes

JoinWorkGroup=WORKGROUP

The customization seems to strip out anything after CreateComputerAccountInDomain=Yes and replaces it with JoinWorkGroup=WORKGROUP

This only appears to happen on vCenter 2.5 Update 3 and does not appear to be a problem on earlier versions of vCenter.

Is anyone else having the same probems, and if so is anyone aware of a fix for this?

Thanks

[RealFairPlayer]

Hi!

Unfortunately you don't provide the OS you want to rollout with the unattendend.txt so this is only a shoot into the blue.

When you look here then you will see a example file with all the stuff you can put into the unattended.txt - here is the interesting part for you:

;[NetWork]

;Attend = Yes|No

; This value should not be specified for a complete unattended install

;

;JoinWorkGroup = <workgroup name>

;JoinDomain = <Domain name>

;CreateComputerAccount = <user_name, password>

;InstallDC = <domain name>

;InstallAdapters = <Install adapters section>

Hopefully this helps you solving the issue. Also, please note, that it is important that the vm can reach the DC at the point of trying it, as a example, if you setup your network later and there is no DHCP server, how should the machine create the cp-account or join the domain

kind regards,

Matthias

[Sugna]

Hi Matthais

I am having this problem with XP and Windows 2003.

I only posted the section of the $winnt$.inf that is causing the problem.

The vm can reach the DC and the network is available. The problem is that the $winnt$.inf does not contain the correct information after the customization process.

Regards

Trevor

[RealFairPlayer]

HI!

I checked my servers and in the winnt.inf i also have in the section identification only JoinWorkGroup=WORKGROUP

I cannot find any domain related information in this file, and the computer is a domainmember. Have you tried to create the computeraccount and the join into the domain manual with the credentials you use within the unattendend process?

br,

Matthias

[Sugna]

Hi Matthias

If I create the computeraccount and join the domain manually it works fine, howerver I am trying to avoid this step as I am trying to automate the build as much as possible.

What is weird is that this used to work in the previous versions of vCenter and has only raised its ugly head in vCenter 2.5 Update 3.

Maybe someone from VMware will have an answer to this????

Regards

Trevor

[dinny]

Hiya,

The way VC 2.5 uses sysprep during windows templating is now very different from the (apparently unsupported by Microsoft?) way that VC 2.0n used to use sysprep.

(I personally have found at least four differences).

The good news is that you can still add machines to a domain - but don't try and do it in the old way via an inf file - if you go through the new customisation spec wizard it should work OK (though it now seems to be done completely differently - not via the $winnt$.inf at all)

The bad news is that there is no way to add a machine to a specific OU anymore - though apparently (I was told by VMware Support this morning) that feature should be added to VC 2.5 u4

Dinny

[Sugna]

Hi Dinny

Thanks for your feedback.

I would normally use the new customization spec wizard. It allows me to join the vm to the domain, however sets the regional settings back to US!!

I use a custom sysprep answer file so that I can change the regional settins using the following lines:

LanguageGroup=1

SystemLocale=0809

UserLocale=00000809

InputLocale=0809:00000809

If you know of any way to do this using the new customization spec wizard please let me know?

Trevor

[dinny]

Hiya,

That's interesting.

I used to use the same 809 regional settings in VC 2.0 myself.

It's a few months since I last looked at my new VC 2.5 templates - but as far as I am aware I didn't do anything to keep those regional settings in my new builds from VC 2.5 templates - but they are definitely all still set to UK.

I'll have a think....

Are you absolutely certain that running the wizard style customisation against a regional template does reset it (admittedly it does seem likely that it would - but I don't recall doing anything special to retain them...)

Dinny

[Sugna]

Hi Dinny

I have a test environment running vCenter 2.5 Update 1 and a pre-prod environement running vCenter 2.5 Update 3. I now this is not ideal, however this is how the environment was when I started here.

The regional settings now appears only to be a problem on vCenter 2.5 Update 1 and is no longer a problem on vCenter 2.5 Update 3.

So going forward I think that if I us the wizard style customisation it will resolve my problem. Only problem with that is that you cannot specify which OU the server will be created in AD as it is automatically put into Computers.

Thanks for your help.

Trevor

[dinny]

Yup,

The undocumented differences between different versions on VC are a real pain...

After two months VM Support finally acknowledged the MachineObjectOU issue as a problem this morning:

Hi Dinny,

My sincere apologies for not getting in touch with you sooner.

After further investigations in regards to the "MachineObjectOU key in the "Identification" section no longer working, I can confirm that we do have a bug (PR 366691) opened to address this issue.

The fix for this PR has been targeted for Virtual Center Update 4.

Only way round it that I am aware of would be to write your own script to do it.

That would have to authenticate via a hardcoded ID/pwd - from a machine not yet joined to a domain though - so would be a pain to write..

Praps easiest to just move them manually till VC 2.5 u4 comes out?

Dinny

[Sugna]

Totally agree about the undocumented differences. Is extremelly frustrating as I have spent the past day on this.

Think we will follow the manual route and wait until vCenter 2.4 Update 4 comes out, which I am sure will have some undocumented features!!!!;)

Trevor

[koawmfot]

i am having the same problem.

the identification section of the customization file is being changed when it is injected into the vm. this began in update three and we just applied update 4 and the issue still persists.

this is extrememly annoying as the entire post build automation relied on the system properly joining the domain.

anyone with a solution that doesn't involve scripting something out?

[dinny]

As above - as long as you use the customisation wizard the machine will be added into the domain just fine.

You only need to script anything if you want to select a non default OU

Dinny

[koawmfot]

i use the customization wizard with a imported sysprep.inf and it does not work and changes the domain entry to workgroup. it does not join the domain fine. it does not join the domain at all.

[dinny]

OK,

More specifically - use the specific wizard fields to specify the domain - they will not work from an imported sysprep.inf - but they will when set directly from the wizard.

Dinny

[koawmfot]

any reason why this functionality was removed? i use an imported sysprep.inf file to compensate for the fact that the built-in guest customization wizard fields failed to give me the same flexability.

updates should enhance functionality, not break something that now requires more documentation, testing and release. and changes to functionality should be documented.

i have information from vmware support but need to go through it all. this is really just a waste of time when this should not have happpened in the first place. if this had been part of the documentation for the release of update 3, it would not have been applied.