DanielSoares
Contributor
Contributor

issue when creating oscustomisationspec in command line

Jump to solution

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 ?

0 Kudos
1 Solution

Accepted Solutions
mattboren
Expert
Expert

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.

View solution in original post

0 Kudos
7 Replies
LucD
Leadership
Leadership

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

0 Kudos
DanielSoares
Contributor
Contributor

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

0 Kudos
LucD
Leadership
Leadership

When you click <OK> and reenter the passwords are they accepted ?


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

0 Kudos
DanielSoares
Contributor
Contributor

yes they are

all actions from the vshpere client are ok

0 Kudos
mattboren
Expert
Expert

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.

View solution in original post

0 Kudos
DanielSoares
Contributor
Contributor

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

0 Kudos
admin
Immortal
Immortal

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

0 Kudos