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

0 Kudos
47 Replies
mattboren
Expert
Expert

Thanks for the discussion, guys.  Your conversation helped me get this working in my environment.

My symptom:  applying an OSCustomizationSpec that had password for the local admin would fail (it would set a password, but not the one that I had entered in the vSphere client when making the CustomizationSpec -- and, even less luck when creating an OSCustomizationSpec from scratch in PowerShell, but that is for another post).  I have been wrestling with this for a while.  As part of my VM deployment PowerShell script, I was copying the CustomizationSpec to a NonPersistent one in the PowerShell session.  I tried many different things -- setting the admin password in the CustomizationSpec in every way that I could figure out to, but never thought about it being related to the "PlainText" property of the password itself.

I now see that copying a CustomizationSpec via the New-OSCustomizationSpec cmdlet results in a CustomizationSpec whose admin password is stored as PlainText (the .ExtensionData.Spec.Identity.GuiUnattended.Password.PlainText value is "true" for the resulting new object).

The good news:  Duplicating a CusomizationSpec via the DuplicateCustomizationSpec() method of a CustomizationSpecManager View object results in a persistent CustomizationSpec whose admin password is in the same format as the source CustomizationSpec (keeps the .ExtensionData.Spec.Identity.GuiUnattended.Password.PlainText value unchanged).  The resultant Persistent CustomizationSpec can then be manipulated as needed (set its OSCustomizationNicMapping, set credentials for adding to the domain, etc.).

@vitalibaruh:  your comments led me to:

## get a customization spec manager View object
$csmSpecMgr = Get-View 'CustomizationSpecManager'
## duplicate the given customization spec to another of the given new name
$csmSpecMgr.DuplicateCustomizationSpec("OurCustomizationSpec", "OurCustomizationSpec-copy")
## retrieve the cloned spec
$oscCopy = Get-OSCustomizationSpec -Name "OurCustomizationSpec-copy"
## ...use the CustomizationSpec at will...

So, pretty much what you suggested, but using the DuplicateCustomizationSpec() method instead of "manually" duplicating.

Thanks

0 Kudos
broedi
Contributor
Contributor

Hi mattboren,

thanks for the example with the DuplicateCustomizationSpec() method.

Works fine for me too on Version 4.1 and Version 4.1.1 🙂

Regards,

Broedi

0 Kudos
mattboren
Expert
Expert

Oh, and @vitalibaruh:

I verified that copying an OSCustomizationSpec using "New-OSCustomizationSpec -Spec" does _not_ result in this behavior when using PowerCLI v4.1.0.0 -- the resultant CustomizationSpec still had the password's PlainText value as "false".

Message was edited by mattboren:  added a reference to @vitalibaruh.

0 Kudos
mattboren
Expert
Expert

Supergreat!  Glad to hear it.  Now if we can get those cmdlets to work as expected...

0 Kudos
admin
Immortal
Immortal

Hi,

We are awere of that problem and as I said in previos post, there's a bug filed for that. In some future release this will be fixed.

Thanks!

Vitali

PowerCLI Team

0 Kudos
mattboren
Expert
Expert

Thanks for the reiteration/followup, @Vitali!

0 Kudos
broedi
Contributor
Contributor

Hi Vitali,

thanks for your support and for opening an issue for that problem.

Regards,

broedi

0 Kudos
sowensby
Contributor
Contributor

Has this been fixed yet?  I seem to be experiencing the same issue in PowerCLI version 5.  I will test the workarounds to see if that fixes my issue.

0 Kudos
admin
Immortal
Immortal

Hi there,

Unfortunately we didn't manage to fix it in this release.

Vitali

PowerCLI Team

0 Kudos
sowensby
Contributor
Contributor

Too bad it did not get addressed in this release..  The workaround(s) still work for me, however.  Thanks.

0 Kudos
jingleharish
Contributor
Contributor

Thanks MattBoren, The duplication really helped me in provisioning the VMs with Local Admin Password set.

0 Kudos
LucD
Leadership
Leadership

Note that there is a cmdlet, New-OSCustomizationSpec with the OSCustomizationSpec parameter, that allows you to clone/copy an existing OSCustomizationSpec. No need to call the SDK method.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

0 Kudos
QuikJean
Contributor
Contributor

That's correct but it works only with PowerCLI 4.0

I made the test with 4.1.1 and 5.0 and it fails for Windows osCustSpec because the password is not copied correctly.

That's why we must use the workaround.

0 Kudos
faceytime
Contributor
Contributor

sorry to bump such an old thread, but this happens with 5.0, 5.0u1, and 5.1 rc1, while it seems the setting stays correct, the unattend xml file still has it has clear true, so it explodes.

the work around is to use -template instead of -vm, that seems to fix it

0 Kudos
np123
Enthusiast
Enthusiast

I recreate the error with Powercli 5.0, ESXi 5.0, and a Windows 2008R2 guest, but only when calling new-OScustomizationSpec with -spec. Here's a new workaround: instead of -spec, I'm piping the output from get-OScustomizationSpec to new-OScustomizationSpec. This workaround succeeds with 64bit Windows 2008R2 and 32bit Windows 2003R2  guests. With 2003 (but not with 2008R2), calling new-vm with -template instead of -vm appears to be an alternative workaround. So I'm guessing faceytime was using a 2003 guest?

So here's how I'm setting the local administrator password without the DuplicateCustomizationSpec method:
Get-OSCustomizationSpec -Name existingSpec | New-OSCustomizationSpec -Name TempOSCust -type NonPersistent
$adminPwd = read-host -prompt "new local admin pwd?"
set-OScustomizationSpec TempOScust -adminPassword $adminPwd
$vm = New-VM -vm someVM -name newVMname -OSCustomizationSpec TempOScust -VMHost name.domain.tld -Datastore someVol -diskStorageFormat Thin -Location someFolder
start-vm $vm
If using a variable for the spec name in new-vm -spec (let's say $spec for my TempOScust), then be sure to refresh the variable after updating the spec. So before New-vm and after set-OScustomizationSpec, you'd need a line like
$spec = get-OScustomizationSpec TempOScust
0 Kudos
faceytime
Contributor
Contributor

nope, 2008 r2 and 2008 32 bit and 64 bit with -template

0 Kudos
np123
Enthusiast
Enthusiast

Interesting... with 64bit 2008R2 were you using new-OScustomizationSpec with -spec or piping output from get-osCustomizationSpec, or maybe doing something different?

Side note, fwiw: I did not have good luck tinkering with $spec.ExtensionData.spec.Identity.GuiUnattended.Password

0 Kudos
faceytime
Contributor
Contributor

me neither it always reverted back to true....

i am deploying vm's from a csv

using -vm (so it clones a vm and not a template) resulted in the error, the -template (after converting the vm to a template) makes it all kindas happy and works as expected

whats the best way to show powercli code on these things?

$spec = Get-OSCustomizationSpec $custspec

$spec | Get-OSCustomizationNicMapping | Set-OSCustomizationNicMapping -IpMode UseStaticIP -IpAddress $ip1 -SubnetMask $mask -DefaultGateway $defgw1 -Dns $dns1,$dns2

New-VM -Name $vmname -template $vm.template -Datastore $datastore -DiskStorageFormat Thin -ResourcePool $rp -OSCustomizationSpec $spec -RunAsync

}}

0 Kudos
np123
Enthusiast
Enthusiast

Okay, our scenarios are a bit different, because you're not using new-OScustomizationSpec. Sounds like a related problem, though.

0 Kudos
np123
Enthusiast
Enthusiast

Sorry to keep yammering on an ancient thread, but this fun fact seemed worth sharing: when cloning a Windows 2003 server, I'm able to set a new local administrator pwd only when the pwd is blank on the source vm. I haven't been able to update an existing pwd.

edit: ok, it's a sysprep thing http://support.microsoft.com/kb/200607

Message was edited by: np123

0 Kudos