none
Unable to deploy a Windows 8.1 image using WDS name and approve! RRS feed

  • Question

  • Hello,

    Hopefully some of you residing Windows 8.1/2012R2 WDS experts are able to answer this question that has been tormenting me for 3 weeks now!

    I have been trying to deploy a custom Windows 8.1 image to a test VM using an answer file and WDS for a mostly unattended process (outside of selecting the image to apply).

    The image and installation process actually works flawlessly if I let WDS handle all known and unknown clients.  The problem comes when I try to "name and approve" the stations.  All I do is enter the name and leave everything else blank and/or at their default settings but it always fails no matter the tweaks I've been trying to apply to the answer file, UnsecureJoin true or false with the credentials and whatnot does not matter.  For the sake of simplicity, I'll post the "specialize" portion of my answer file which worked using UnsecureJoin without name and approve here:

        <settings pass="specialize">
            <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <Identification>
                    <UnsecureJoin>true</UnsecureJoin>
                </Identification>
            </component>
            <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <ComputerName>%MACHINENAME%</ComputerName>
                <RegisteredOrganization>Organization</RegisteredOrganization>
                <RegisteredOwner>Utilisateur</RegisteredOwner>
            </component>
            <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <InputLocale>1009:00001009</InputLocale>
                <SystemLocale>en-US</SystemLocale>
                <UILanguage>fr-FR</UILanguage>
                <UserLocale>en-US</UserLocale>
            </component>
        </settings>

    The error I retrieved from C:\Windows\panther\setuperr.log is: "[DJOIN.EXE] Unattended Join: At least one of JoinWorkgroup/JoinDomain must be specified: 0x57".  Thus, I retry with name and approve but by specifying the JoinDomain with the %MACHINEDOMAIN% value as such:

    <Identification>
    	<UnsecureJoin>true</UnsecureJoin>
    	<JoinDomain>%MACHINEDOMAIN%</JoinDomain>
    </Identification>

    This seems weird since WDS should already have this information which is specified in the WDS server properties.  Still, I add the requested information and try again which then gives me the following error fetched from C:\Windows\debug\NetSetup.log: "NetpGetDomainData: Failed to find the domain data: 0x6e"

    Anybody else ran into this and know the fix for it?

    Also, as an additional note, not sure if it is relevant, but doing only "Approve" will not work at all either as it gives me the following error when I attempt to do so: "The name provided is not a properly formed account name." despite the fact that I've formatted it to use "CVL%MAC" which should pass by fine.

    Tuesday, November 18, 2014 9:34 PM

Answers

  • Thanks for the info Roger.

    However, we ended up contacting Microsoft regarding this and after several weeks of useless tests, turns out there is a bug in WDS when using admin approval and PXE booting when using UEFI over BIOS and unattended domain joining is simply non-functional over UEFI when pxe booting with WDS name and approve.

    Long story short, keep using BIOS if you want automated joins with WDS name and approve.  If you are forced to use UEFI, the only other alternative would be to use a logon script after deployment but this assumes the account that will be logged in is an administrator.  Either that or manually join the domain post-deployment!

    Hope this helps somebody else with this same problem.  I know it caused me some major headaches.

    Cheers!
    • Marked as answer by naashkyr Monday, December 22, 2014 6:13 PM
    • Edited by naashkyr Monday, December 22, 2014 6:14 PM
    Monday, December 22, 2014 6:13 PM
  • For the community's information, as an answer was given to this very question on another question here on Technet (https://social.technet.microsoft.com/Forums/Lync/en-US/7affbcce-628c-43ff-b237-9d430d244e7b/wds-uefi-uattended-domainjoin-problems?forum=winserversetup) as well as on ServerFault (https://serverfault.com/questions/642587/unable-to-perform-an-unattended-domain-join-using-wds-and-an-answer-file-on-wind/798591#798591) where I posted a clone of this question at the same time, 4 years ago.  A proposed solution was provided by techraf on ServerFault (all credits to him):

    Added info, this also occurs with 2008 Std R2 with W7 Pro machines.

    To all whom it may concern, since this issue is applicable only at the Domain Admin group level, I thought to try with an account give all rights through Delegation control at the domain root level, which works as well, so there is no need to go and change the security settings on each and every UEFI computer object :).

    How-to:

    1. I created a user WDSinstall, whose only group membership is Domain User.
    2. Then I simply ran through the Delegate Control wizard (in this case, right-click your root Domain node and select Delegate Control).
    3. Add your newly created account and click Next.
    4. Select Create custom tasks to delegate and click next.
    5. Keep "This folder, existing objects in this....." selected, click Next.
    6. Make sure that all 3 options under "Show these permissions" are ticked, meaning: General, Property-Specific and Creation/Deletion of specific child-objects.
    7. In the Permissions box, simply tick Full Control, this will select all other permissions as well. Click Next.
    8. Click Finish.

    Now you have an account which is in essence a Domain Admin account, and as such, you can use it for all your WDS and deployment needs.

    I hope this helps someone as much as this original post helped me (a lot).


    • Marked as answer by naashkyr Monday, October 22, 2018 6:36 PM
    Monday, October 22, 2018 6:33 PM

All replies

  • Edit: I found the following info on the last error I got about the failed to find the domain data:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/898e5287-08c2-4db9-b7ef-67b8b72b235d/netpgetdomaindata-failed-to-find-the-domain-data-0x6e-when-doing-unsecurejoin?forum=winserversetup

    The answer specifies using the machine password.  I tried adding the %MACHINEPASSWORD% variable to the answer file as such:

    <Identification>
    	<UnsecureJoin>true</UnsecureJoin>
    	<JoinDomain>%MACHINEDOMAIN%</JoinDomain>
    	<MachinePassword>%MACHINEPASSWORD%</MachinePassword>
    </Identification>

    But this resulted in this new error from NetSetup.log:

    • NetpLdapBind: ldap_bind failed on DC.ad.domain.com: 49: Informations d'identification non valides
    • NetpJoinCreatePackagePart: status:0x52e.

    This roughly translates to "Invalid credentials" which should be supplied by WDS directly so I'm a bit at a loss here...  I've been running around in circles from there.  I'm going to try removing the joindomain setting next to see if it changes anything and then I'm going to try unchecking the "Join this computer to the domain" box from the WDS name and approve window to see if that does it as well.  In the meantime, any expert's input would be appreciated.

    Thanks!

    Tuesday, November 18, 2014 10:25 PM
  • Hi,

    Sorry for my dilatory reply. We do need some more time to make reasearch with your problem.

    Please be paint, thanks for your understanding.



    Roger Lu
    TechNet Community Support

    Tuesday, December 2, 2014 2:43 AM
    Moderator
  • Hi,

    Firstly, I need to confirm how the name setting got passed? Because according to my test, if the device named uncorrectly, it would prompt the error and couldn't go to next step:

    As far as I know, the naming standard is different between Device Identity and ADDS server naming policy, the second naming policy should be like: %61username%#

    Therefore, please check your PC device name if there is any problem with it. You can also refer to the contents of the link below for more details about Naming Standard:

    http://programming4.us/desktop/21662.aspx

    Note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    For another problem, Unsecure join, according to the contents of the link below. since Vista, shared computer password is a dynamically generated, no need to assign the password manually.

    http://technet.microsoft.com/en-us/library/cc730845(v=ws.10).aspx


    Roger Lu
    TechNet Community Support


    Friday, December 5, 2014 9:32 AM
    Moderator
  • Thanks for the info Roger.

    However, we ended up contacting Microsoft regarding this and after several weeks of useless tests, turns out there is a bug in WDS when using admin approval and PXE booting when using UEFI over BIOS and unattended domain joining is simply non-functional over UEFI when pxe booting with WDS name and approve.

    Long story short, keep using BIOS if you want automated joins with WDS name and approve.  If you are forced to use UEFI, the only other alternative would be to use a logon script after deployment but this assumes the account that will be logged in is an administrator.  Either that or manually join the domain post-deployment!

    Hope this helps somebody else with this same problem.  I know it caused me some major headaches.

    Cheers!
    • Marked as answer by naashkyr Monday, December 22, 2014 6:13 PM
    • Edited by naashkyr Monday, December 22, 2014 6:14 PM
    Monday, December 22, 2014 6:13 PM
  • Is this ever going to be fixed?

    I'm not 100% certain but this may have been related to this:

    https://social.technet.microsoft.com/Forums/Lync/en-US/7affbcce-628c-43ff-b237-9d430d244e7b/wds-uefi-uattended-domainjoin-problems?forum=winserversetup

    Wednesday, September 19, 2018 9:03 PM
  • For the community's information, as an answer was given to this very question on another question here on Technet (https://social.technet.microsoft.com/Forums/Lync/en-US/7affbcce-628c-43ff-b237-9d430d244e7b/wds-uefi-uattended-domainjoin-problems?forum=winserversetup) as well as on ServerFault (https://serverfault.com/questions/642587/unable-to-perform-an-unattended-domain-join-using-wds-and-an-answer-file-on-wind/798591#798591) where I posted a clone of this question at the same time, 4 years ago.  A proposed solution was provided by techraf on ServerFault (all credits to him):

    Added info, this also occurs with 2008 Std R2 with W7 Pro machines.

    To all whom it may concern, since this issue is applicable only at the Domain Admin group level, I thought to try with an account give all rights through Delegation control at the domain root level, which works as well, so there is no need to go and change the security settings on each and every UEFI computer object :).

    How-to:

    1. I created a user WDSinstall, whose only group membership is Domain User.
    2. Then I simply ran through the Delegate Control wizard (in this case, right-click your root Domain node and select Delegate Control).
    3. Add your newly created account and click Next.
    4. Select Create custom tasks to delegate and click next.
    5. Keep "This folder, existing objects in this....." selected, click Next.
    6. Make sure that all 3 options under "Show these permissions" are ticked, meaning: General, Property-Specific and Creation/Deletion of specific child-objects.
    7. In the Permissions box, simply tick Full Control, this will select all other permissions as well. Click Next.
    8. Click Finish.

    Now you have an account which is in essence a Domain Admin account, and as such, you can use it for all your WDS and deployment needs.

    I hope this helps someone as much as this original post helped me (a lot).


    • Marked as answer by naashkyr Monday, October 22, 2018 6:36 PM
    Monday, October 22, 2018 6:33 PM