VMware Cloud Community
broedi
Contributor
Contributor

New-OSCustomizationSpec problem with PowerCLI 4.1.1 (332441)

Hi,

Im using PowerCLI to automate the deployment of new VMs by using VMware Templates and an OSCustomizationSpec.
During the process, I create a new OSCustomizationSpec from a Template with the Command:
New-OSCustomizationSpec -Spec Spec_Tempate -Name MyNew_Spec

The Command works fine with PowerCLI 4.1 (264274), but after Upgrading to PowerCLI 4.1.1 (332441) the OS-Setup of Windows 2008 R2 failed 
Error: "Install Windows"
Windows could not parse or process unattend answer file [C:\Windows\Panther\unattend.xml] for pass [oobeSystem].
The settings specified in the answer file cannot be applied.
The error was detected while processing settings for component [Microsoft-Windows-Shell-Setup]

The Error is reproduceable.

All ESXi and vCenter Server using Version 4.1

Is there another way to create a new OSCustomizationSpec?

Has anyone used that Command with success?

Thanks for any feedback

Willibald

Reply
0 Kudos
47 Replies
matt948
Enthusiast
Enthusiast

Resurrecting an old thread...

Can anyone confirm that this is still an issue in PowerCLI 5.1 r1? I am still having the issue, but in the release notes it says it has been resolved

https://www.vmware.com/support/developer/PowerCLI/PowerCLI51/powercli51-793510-releasenotes.html

Resolved Issues
The following issues have been resolved in VMware vSphere PowerCLI 5.1 Release 1:

•New-OSCustomizationSpec
Cloning a server-side customization specification with New-OSCustomizationSpec changes the values of the PlainText properties from true to false.

This only seems to be an issue for NonPersistent, for Persistent I have no problems.

I have tried checking the value of .ExtensionData.Spec.Identity.Identification.DomainAdminPassword.PlainText but when I do it .ExtensionData has no values at all.

$tempSpec = "temp-spec"
$spec = "W2K8R2STD"

$custSpec = New-OSCustomizationSpec -OSCustomizationSpec $spec -Type NonPersistent -Name $tempSpec

Reply
0 Kudos
np123
Enthusiast
Enthusiast

I'm not sure. If you haven't already, you might try the workaround I mentioned above:

$custSpec = Get-OSCustomizationSpec -Name $spec | New-OSCustomizationSpec -Name $tempSpec -type NonPersistent
Reply
0 Kudos
BenConrad
Expert
Expert

I'm happy to say that cloning a VM (using -VM) seems to be working well in the latest build of PowerCli

PowerCLI C:\> Get-PowerCLIVersion

PowerCLI Version
----------------
   VMware vSphere PowerCLI 5.1 Release 2 build 1012425

When using a previous version (PowerCLI 5.0.1 build 581491) create a VM from template worked, but had to perform some workarounds to ensure that PlainText = $false by using the DuplicateCustomizationSpec() method.

I just started allowing our deployment scripts to clone existing VMs, but they were taking a really long time in the customization phase, weren't joining the domain and the local admin password was all screwed up

[this did not work in 5.1 build 1012425]

$spec = Get-OSCustomizationSpec _tmpSpec_ben-deploy3
new-vm -name 'ben-deploy3' -vm 'ben-deploy2' -datastore MYDATASTORE -vmhost MYVMHOST -OSCustomizationSpec $spec -DiskStorageFormat Thin
Start-VM -VM ben-deploy3 -Confirm:$false -ErrorAction Stop

But after a quick test works on Powercli 5.1 R2 build 1012425.  The VM goes through customization quickly, joins the domain and the local password is what I expected.

FYI, I don't put passwords in the $spec, rather I create template specs from vCenter and allow the passwords to live in those specs.

Ben

Reply
0 Kudos
enclsoed
Contributor
Contributor

Hi!

I've been playing with this a lot and as far as I can tell this has not yet been fixed even in PowerCLI 5.5 R1, at least for nonpersistent customizations. Anyway, it doesn't look to be directly related to the PlainText attribute and actually it seems like it should be set to true in this particular case (I suspect that it is being decrypted right before sysprep is executed and that cryptic password actually becomes a PlainText). I compared Sysprep.xml files generated from a template cloned using a nonpersistent customization and from a persistent one and I noticed that EncryptedValue property (for local Administrator) in case of nonpersistent customization is significantly longer that in case with persistent. I suppose that Sysprep fails just because the value is longer than the max length of the password. As for the value itself, I think that initially it gets encrypted for Sysprep not from the plain text password, but from it's encrypted value as it is stored as VMware.Vim.CustomizationPassword.

I hope my comments will be useful for the PowerCLI team.

Thanks a lot!

Reply
0 Kudos
Tigger879
Contributor
Contributor

Hi,

I'm glad I'm not the only one banging my head against the OSCustomization wall. I have a script created the deploys VMs from template, Adds extra HDD, puts them on the required port group and then starts the VM. If my understanding is correct the OSCustomization doesn't kick in until the VM starts which is fine, however with W2K8R2 the first thing requested is to change the Administrator PW. I think that this may be just one of the issues that is making the OSCustomization fail even though the Sysprep is configured for Auto Logon. I tried stepping through the process manually but in the order of the script. Even doing it manually the Auto Logon count seems to be ignored and I had to logon to continue. The script is made up of snippets gathered from the internet and my self taught knowledge of PowerCLI.

Any advice or insight into this issue would be gratefully recieved.

:smileyconfused:

Reply
0 Kudos
astardjiev
VMware Employee
VMware Employee

@enclsoed,

Thanks for reporting this against 5.5 R1. I confirm the defect exists.

When the fix goes into a GA build, it will be listed in release notes; internal ref. 764063.

Best,

Hristo

Reply
0 Kudos
nathancurtis
Contributor
Contributor

Hello,

I was wondering if this has been updated?  The being forced to change passwords is still happening to me in 5.5 R1.  Windows vers. Win2k8 R2 Datacenter is what is being deployed from a template with a nonpersistant spec.

This is the snippet where i'm specifying the customization spec:

            #Create a temporary OSCustomizationSpec to use to set IP addresses.

  if ($spec = New-OSCustomizationSpec -Type NonPersistent -Name $vm.Name -NamingScheme VM -FullName $Env:USERNAME -OrgName $vm.DomainName -ChangeSid -Workgroup $vm.Workgroup -AdminPassword $localPassword )

  {

  $nicmap = Get-OSCustomizationNicMapping -OSCustomizationSpec $spec.Name

  Set-OSCustomizationNicMapping -OSCustomizationNicMapping $nicmap -IpMode UseStaticIP -IPAddress $vm.IPAddress -SubnetMask $vm.Netmask -DefaultGateway $vm.Gateway -Dns $dnsServers

        

  #Create the VM from template.

  Write-Host $vm.Name will be cloned from $vm.Template on $curhost, datastore $datastores[$drand] in network $vm.Network

  $newvm = New-VM -Name $vm.Name -Template $template -OSCustomizationSpec $spec.Name -DiskStorageFormat Thin -VMHost $curhost -Datastore $datastores[$drand] -Confirm:$confirm

  $nvview = Get-View $newvm.Id

            }

  else

  {

                #Or fail and move on.

                Write-Host Could not create a OSCustomizationSpec called $vm.Name

                Write-Host $vm.Name will be cloned from $vm.Template on $curhost, datastore $datastores[$drand] in network $vm.Network

  $newvm = New-VM -Name $vm.Name -Template $template -DiskStorageFormat Thin -VMHost $curhost -Datastore $datastores[$drand] -Confirm:$confirm

  $nvview = Get-View $newvm.Id

            }

Reply
0 Kudos
DustinGiles
Contributor
Contributor

Hello,

I am seeing similar issues. Was this ever resolved?

Thanks,

Dustin Giles

Reply
0 Kudos