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
I had an issue trying to create a new spec through the command line. This issue was being caused by the the x64 version of the CLI client. If you use the x86 version then the command should complete fine.
I posted this a month or so back and it should be getting fixed I hope.
PowerCLI encrypts password fields in customization specification objects. Currently the encryption library that we use is only 32bit so if you want to use customization functionality you should start PowerCLI in 32 bit mode.
thanks for the Info, but I use the 32-Bit Version (on Windows 7 32-bit).
On the same Computer the New-OSCustomizationSpec is working with PowerCLI Version 4.1 but not working with PowerCLI Version 4.1 U1 😞
I understood something incorrect...
Can you tell about the error in your fisrt post - this error is result from New-OSCustomizationSpec call or it is result from New-VM -Template .... - OSCustomization .... call?
thanks for your quick reply 🙂
I get the error in the VM-Box during the Windows-Setup/Customization process after the second reboot.
The Commands "New-OSCustomizationSpec" or "New-VM" are running without any error.
I think that there's some other change in your environemnt which leads to this error. Can you check the same customization operation thru the UI client or with the previous version of PowerCLI ?
I have done already some Tests:
I worked with PowerCLI 4.1 -> the New-OSCustomizationSpec (I mean the OSCustomizationSpec created by the New-OSCustomizationSpec Command) worked fined
Then I upgraded to PowerCLI 4.1U1 (VMware-PowerCLI-4.1.1-332441.exe) -> after using the New-OSCustomizationSpec. I got the Windows-Setup Error 😞
I also noticed, that the Parameter "-Spec" of the Command "New-OSCustomizationSpec" changed to "-OSCustomizationSpec" with PowerCLI 4.1.1. Is the old "-Spec" Parameter still supported?
If i use the vCenter Client to "Duplicate" a OSCustomizationSpec, the duplicates Spec is working.
So I uninstalled the PowerCLI 4.1U1 and reinstalled the PowerCLI 4.1 (VMware-PowerCLI-4.1.0-264274.exe) -> The New-OSCustomizationSpec command is working again :smileyconfused:
I'm using a VM Template with a Windows Server 2008 R2 (Standard) for the Tests.
Thanks for the info. We should do some research. It will be really helpful if you export the customization spec and attach it here. Don't forget to remove all of your passwords!
About the parameter name change - yep, Spec is still supported as alias to the OSCustomizationSpec.
so did some more tests.
Maybe the problem is the setting of:
I found this setting in two sections of the exported XML-File:
Section: "<password>" and "<domainAdminPassword>"
I'm going to modify my script to change these two settings after creating the new Spec and run a new Test.
I'll inform you as soon as I got the results of the test...
I tried to build a work-around by setting the two parameters to "False":
$myOS_Cust_Spec.ExtensionData.Spec.Identity.Identification.DomainAdminPassword.PlainText = $false
$myOS_Cust_Spec.ExtensionData.Spec.Identity.GuiUnattended.Password.PlainText = $false
But the problem is, that the changed data will not be saved to the database 😞
So if i check the value of
I get the return value "False".
But if i read the Object from the Database with Get-OSCustomizationSpec, the value of $myOS_Cust_Spec.ExtensionData.Spec.Identity.Identification.DomainAdminPassword.PlainText
is set to "True" again 😞
The same happens to the second parameter $myOS_Cust_Spec.ExtensionData.Spec.Identity.GuiUnattended.Password.PlainText 😞
Any other ideas?
Yes, chaining the properties of the ExtensionData doesn't change the object on the server. You should call the proper method of the CustomizationSpecManager if you want to update the customization spec.
Can you attach the script file , so we will be able to reproduce the situation. Again, if there are passwords, just replace the values with some dummy value.
I created a smal Script.
Runs fine on PowerCLI 4.1 but not on PowerCLI 4.1 U1 (the script runs also fine, but the OSCustomizationSpec is not working, so the windows setup fails).
I also noticed, that the new created VM (I dont use the -Location parameter) placed one different locations, depending on the PowerCLI version.
By using V4.1, the new VM is placed in the same folder as the VM-Template.
Using V4.1.1, the new VM is placed in the root folder of the Cluster/ESX-Host.
I'll try to reproduce the same situation and will write later.
About the folder - yes, in the newer release New-VM creates the VM in the root folder, but you always can change this by passing something on Location parameter. And this change is not related with the customization spec problem.
I tried similar customization as yours and all of them succeeded without problems - the error log of sysprep is empty. I guess that the message in your initial post is obtaiend from sysprep log, right? Please, where did you find the error message?
The last thing that we can try is to analyze the syspre.xml file that is produced from New-VM command. How to do it?
Remove the Start-VM call . After the New-VM completes , go to the datastore where the VM lives and download a file with name icmXXX.tmp. This is archive file that you can open with 7zip or WinRar or something similar. Extract from it the sysprep.xml file. You can edit it to remove any sensitive information as you did the last time. After that attach it here.
thats very interesting because I installed the PowerCLI on a second System with the same results. :smileyconfused:
After some investigation, I'm quite sure that the problem is the setting of the "PlainText=true" Fields.
I found this "wrong" setting two times in my OSCustomizationSpec:
This settings usualy set to "false" except if I use the PowerCLI 4.1.1(332441) to create the OSCustomizationSpec.
The password is always encrypted in the Spec so the setting "PlainText=true" is not correct so the Windows-Setup shows the error because of the wrong settions.
Is there a method to change the two settings to "true" in an existing OSCustomizationSpec (to use it as a work-around)?
Unfortunately you are right. The problem lies in the cloning operation of your script - if you check these properties right after getting the initial spec from the VC server, they are OK with value $false. But the copy of the spec is wrongly filled up.
My first advice is to use directly the spec obtained from the server. If i found some other solution I will write you.
I will file a bug for this issue.
Let's try another way of cloning customization spec, that won't harm PlainText fields:
# getting the source spec
$spec = Get-OSCustomizationSpec -Name <source name>
# we will use the ExtensionData property as input parameter to the CreateCustomizationSpec method
# so we need to change the Name field with the desired name
$spec.ExtensionData.Info.Name = 'MySpec'
# getting customization spec manager
$cm = Get-View 'CustomizationSpecManager'
# creating new spec
# getting the cloned spec
$mySpec = Get-OSCustomizationSpec -Name 'MySpec'
# apply the spec
New-VM -Template ..... -Spec $mySpec .....