none
MDT 2013 update 2 UDI wizard - domain join credentials issue RRS feed

Answers

  • Hi again,

    I found a work arround:

    Instead of using the default OSDJoinAccount value in the UDI wizard, I created a custom variable in the TS and used this. I called it OSDJoinAccount_1

    edit: I had to remove/disable the old OSDJoinAccount step in the TS for it to work.


    /ESK


    • Marked as answer by yelling softly Wednesday, June 1, 2016 12:16 PM
    • Edited by EMS-edgemo Wednesday, June 1, 2016 12:17 PM
    Wednesday, June 1, 2016 11:43 AM

All replies

  • Dear Sir,

        I have test in my lab with the TS variables (ConfigMgr 1602, MDT 2013 update2), which got the same error:

       

         You could read this blog for reference and test it own. If you have the same error, I think the best way for you is to open a case with Microsoft Support, inform them the issue so that they could take some measures to fix it.

        https://buckingthesystemcenter.wordpress.com/2015/06/22/how-to-set-the-domain-join-credentials-and-local-admin-password-in-udi-task-sequence/

    Best regards,

    Jimmy


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Monday, May 16, 2016 8:49 AM
    Moderator
  • I tested it just like in the blog article still no avail.  Hmm, I'm going to keep looking but if I don't find anything else I may need to open a case with Microsoft.  I would think they would be aware of this issue since its been out since December but I've been through the release notes and doesn't seem to be any note on known issues for this.
    Tuesday, May 17, 2016 2:44 PM
  • Hi,

    I am having the exact same issue. Did you hear anything from MS on this?


    /ESK

    Wednesday, June 1, 2016 9:55 AM
  • Hi

    i've just installed a fresh 1511 and migrated data from the old sccm server.

    I then created a new MDT task Sequence and set it up as I wanted..

    On the computerName UDI page it keeps failing with wrong user name (see screenshot)

    I've already set 2 TS variables which I'd hoped the UDI would use/read in the beginning of the TS: OSDJoinAccount & OSDJoinPassword

    any ideas?


    Kindest regards, Martin

    • Merged by TorstenMMVP Wednesday, June 1, 2016 10:49 AM merged
    Wednesday, June 1, 2016 10:44 AM
  • Hi again,

    I found a work arround:

    Instead of using the default OSDJoinAccount value in the UDI wizard, I created a custom variable in the TS and used this. I called it OSDJoinAccount_1

    edit: I had to remove/disable the old OSDJoinAccount step in the TS for it to work.


    /ESK


    • Marked as answer by yelling softly Wednesday, June 1, 2016 12:16 PM
    • Edited by EMS-edgemo Wednesday, June 1, 2016 12:17 PM
    Wednesday, June 1, 2016 11:43 AM
  • Sorry for the late reply but I was able to get it to work using the same thing.  If you create two custom variables and place them before the UDI Wizard step runs and then go into the UDI wizard editor and place your custom variables as the default value (i.e. %OSDJoinaccountcustom%, %OSDJoinPasswordCustom%) it will work.

    Maybe it will help someone I wrote up a little tutorial on how and where to place the variables.

    https://whenrebootingisnottheanswer.wordpress.com/2016/06/01/mdt-2013-update-2-udi-wizard-domain-join-credentials-issue/


    Wednesday, June 1, 2016 12:16 PM
  • custom variable worked for me as well..

    Kindest regards, Martin

    Thursday, June 2, 2016 10:49 AM
  • Strange.. it's doesn't quite works.. it doesn't seem to be accepting the password.. it fills in the information (at least it looks like it does).. but it doesn't accept it until I manually write it..

    Kindest regards, Martin

    Thursday, June 2, 2016 11:21 AM
  • Goddammit..

    nevermind.. I spotted a spelling error in the password... I missed a capital P..

    I did actually change it from p to P but because I didn't actually change any text... it ignored the change from small to capital.. but after writing some gibberish instead of the proper password, applying and clicking OK,  and then adding the correct password.. it works.

    If you don't click "OK" after apply.. it'll actually still ignore your changes...

    stupid TS!


    Kindest regards, Martin

    Thursday, June 2, 2016 11:25 AM
  • Really that wasn't something I used to have to do.  What changed?  Thanks for the reply though that's good to know.  I simply put them into my task sequence variables instead to solve my problem but the collection variable is probably the safer more secure way of doing it.
    Wednesday, October 19, 2016 12:42 PM
  • 
    #We can use powershell to do the encoding
    
    PS> $Base64PWDString=[Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes("'Why do we need to use base 64 ?'"))
    
    PS> $Base64PWDString
    
    JwBXAGgAeQAgAGQAbwAgAHcAZQAgAG4AZQBlAGQAIAB0AG8AIAB1AHMAZQAgAGIAYQBzAGUAIAA2ADQAIAA/ACcA
    
    #And then the reverse either by 
    
    PS> powershell.exe -encodedCommand $Base64PWDString
    
    Why do we need to use base 64 ?
    
    #Or
    
    PS> [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($Base64PWDString))
    
    'Why do we need to use base 64 ?'
    
    #Note: the above adds the single quotes to your string…

    Wednesday, May 16, 2018 1:07 AM