hello,
I have an issue when creating or modifying an oscustomisationspec by command line
if I modify the administrator password or domain password I have an issue when using the customisationspec
error is cannot decrypt password
the public key in the specification does not match the vcenter public key...
when I create this oscustomisationspec from my xp machine I have no issue
when I create it from my administration server I have the issue
and when I create it from the vcenter itself I have the issue too
I can not understand why I am using the right key from my computer and not from a server
if I create the customspec from the vsphere client on the vcenter or on the administration server it works well
an other thing
if I export the customisation from my computer the plaintext value for passwords is false
if I export the customisation from the servers the plaintexst value is true
my machine is xp
the servers are win2003 and win2008
can someone help ?
Hello, DanielSoares-
This might be related to the bug referenced in the thread at http://communities.vmware.com/thread/297748. There, broedi and vitalibaruh eventually find that the PlainText property for passwords in the spec is set to $false instead of $true when. They are discussing this issue when using New-OSCustomizationSpec to clone an OSCustomizationSpec, but I have had the same behavior as you describe when creating a new persistent OSCustomizationSpec using New-OSCustomizationSpec.
In the thread (the post at http://communities.vmware.com/thread/297748?start=18), vitalibaruh (of the PowerCLI Team) mentions that he is filing a bug for this behavior.
So, for now, the workaround seems to be to create the OSCustomzationSpec via the vSphere client, and, if you want to work with a copy of the spec (to add/change credentials, for example), use the API to clone the spec (via the DuplicateCustomizationSpec() method), and then use Set-OSCustomizationSpec to make changes to the clone. I posted a snippet on using this Duplicate method in that same thread.
Not ideal, but it works. Hopefully that helps.
Could you perhaps show us the commands you are trying to execute and the eventual error messages you receive ?
Is the encryption/decryption done from the same client with the same account ?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
one of the commands I use is
New-OSCustomizationSpec -Name test -Spec Custom_Server
create a new oscustom caled test from a custom caled custom_server
but if I want to create the custom from scratch I have the same error
New-OSCustomizationSpec
-Name Spec `
-OSType Windows `
-Description "temporaire! si vous voyez ce customspec supprimez le." `
-FullName societe`
-OrgName societe`
-NamingScheme vm`
-ProductKey "XXXX-XXXX-XXXX-XXXX-XXXX" `
-LicenseMode Perseat `
-AdminPassword password `
-Domain mydomain`
-DomainCredentials (import-credential domainaccount)`
the error is that the 2 passwords are not created on the new customspec
if I open the customspec from the vsphere client attached is the error
I do not have the issue if I start those commands from my xp computer
When you click <OK> and reenter the passwords are they accepted ?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
yes they are
all actions from the vshpere client are ok
Hello, DanielSoares-
This might be related to the bug referenced in the thread at http://communities.vmware.com/thread/297748. There, broedi and vitalibaruh eventually find that the PlainText property for passwords in the spec is set to $false instead of $true when. They are discussing this issue when using New-OSCustomizationSpec to clone an OSCustomizationSpec, but I have had the same behavior as you describe when creating a new persistent OSCustomizationSpec using New-OSCustomizationSpec.
In the thread (the post at http://communities.vmware.com/thread/297748?start=18), vitalibaruh (of the PowerCLI Team) mentions that he is filing a bug for this behavior.
So, for now, the workaround seems to be to create the OSCustomzationSpec via the vSphere client, and, if you want to work with a copy of the spec (to add/change credentials, for example), use the API to clone the spec (via the DuplicateCustomizationSpec() method), and then use Set-OSCustomizationSpec to make changes to the clone. I posted a snippet on using this Duplicate method in that same thread.
Not ideal, but it works. Hopefully that helps.
thanks Mattboren
My issue is not linked to the bug you refer to, but you helped me to find a solution
in fact the version of powercli I installed in my computer is 4.1 but I continue to install the 4.0 version on the servers in charge of executing tasks throw the vcenter (to be able to transfer scripts from one to the other)
but it seems that if vcenter see a 4.1 version of powercli it change the way of encrypting the passwords in oscustomisationspec
so I installed the 4.1 version of powercli in the server and it is able now to modify the oscustomisationspec
I only have to upgrade my 3 servers using 4.0 to 4.1 and every thing will be find
if some one have more informations about the way the encryption is done and the incompatibility between versions do not hesitate to share
Hi Daniel,
PowerCLI version prior 4.1 didn't encrypt password fields of customization specification objects. It is not VC server conditional behaviour, but PowerCLI way of using the VC capabilities. Current version of PowerCLI encrypts password fields against all vCenter versions after 2.5.
Regards,
Vitali
PowerCLI Team