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
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.
Oh, and @vitalibaruh:
I verified that copying an OSCustomizationSpec using "New-OSCustomizationSpec -Spec" does _not_ result in this behavior when using PowerCLI v220.127.116.11 -- the resultant CustomizationSpec still had the password's PlainText value as "false".
Message was edited by mattboren: added a reference to @vitalibaruh.
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.
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
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?
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 someFolderstart-vm $vm
$spec = get-OScustomizationSpec TempOScust
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
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
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