3 Replies Latest reply on Feb 8, 2016 8:01 AM by markuszierer

    Inheritance of password variables

    Lucky Rookie

      Hi @ all.


      I have a question about the inheritance of password variables in the 2015.1.4. Within my OS-Set (in the configuration package) i've defined a parameter for the AD join user, password and OU. This three points I read from the variables pane and enter it as installation parameter in my configuration package. Then the installation parameters are set in the unattend.xml.

      Then i go ahead and move my client to the defined OU and reinstall the computer. Normally all variables should be inherited from the OU to the computer except the password is everything ok. But when the computerobject already exists in the defined OU and i retype the password in the variable field everything works.

      Is this a issue or am i just missing something. Here are two screenshots from the variables and the configuration package and from the unattend.


      password variable.jpg


      The password looks like this in the unattend.xml when the join won't work. When i type the password again, then i see the password correct.





        • 1. Re: Inheritance of password variables
          markuszierer Apprentice



          there is a known Bug in 2015.1.x with the password variables. The encrypted value of the password is not transferred back correctly when the ODS Variable is used. This causes problems when passwords should be used.


          As far as i have seen in the RN of 2015.2.2, this issue should be fixed in that version. But since i'm busy with other topics, i did not have the time to verify that again. Please have a look in the RN of 2015.2.1 and 2015.2.2, there should be something written about this issue.

          • 2. Re: Inheritance of password variables
            Lucky Rookie

            Thanks for your fast answer.


            Do you know if there is a workaround for this?

            • 3. Re: Inheritance of password variables
              markuszierer Apprentice

              Well, the only "workaround" i know is to use a regular password field instead of an ODS Variable. Then the password is transfered correctly. But as this not really a workaround but back to the originally intended function, i would not call it a workaround.


              Had the same problem with a script to change the local admin password at a customer. And the answer from support was, i have to wait for DSM 2015.2...