none
Problems autojoining Win 7 client to domain using unattend-file

    Question

  • Hi

    I am trying to create an unattend file for my Windows 7 Enterprise x64 installations. We are using WDS to push the images. The machines are prestaged in AD with mac as id, using wdsutil /add-device. Below if the error-messages I get after installation, and my answerfile (edited for sensitive data).

    Can anyone see what might be wrong here? The user I use here is a domain-admin, and I can join the computer manually to the domain after installation. But I want the installation to automatically register the computer in the domain, and after installation, I just want a logon-screen for the domain, not a local user.

    2010-03-05 17:04:26, Info       [0x0b007b] WDS    DomainJoinInformation: Join Domain = [Y]
    2010-03-05 17:04:26, Info       [0x0b007b] WDS    DomainJoinInformation: Account Exists = [Y]
    2010-03-05 17:04:26, Info       [0x0b007b] WDS    DomainJoinInformation: Prestage Using MAC = [N]
    2010-03-05 17:04:26, Info       [0x0b007b] WDS    DomainJoinInformation: Reset Boot Program Path = [N]
    2010-03-05 17:04:26, Info       [0x0b007b] WDS    DomainJoinInformation: Machine Name = [testmaskin101]
    2010-03-05 17:04:26, Info       [0x0b007b] WDS    DomainJoinInformation: Machine Domain = [domain.no]
    2010-03-05 17:04:26, Info       [0x0b007b] WDS    DomainJoinInformation: Machine OU = []
    2010-03-05 17:04:26, Info       [0x0b007b] WDS    DomainJoinInformation: Machine Dn = [CN=testmaskin101,OU=PC,DC=domain,DC=no]
    2010-03-05 17:04:26, Info       [0x0b007b] WDS    DomainJoinInformation: First Name = [Install]
    2010-03-05 17:04:26, Info       [0x0b007b] WDS    DomainJoinInformation: Last Name = [User]
    2010-03-05 17:04:26, Info       [0x0b0079] WDS    ProcessDomainJoinInformation: This machine will attempt to join a domain.
    2010-03-05 17:04:26, Info       [0x0b0083] WDS    -> WdsMgResetAccount
    2010-03-05 17:04:26, Info       [0x0b0083] WDS    -> MgLibpOpenLdapConnectionFromDN
    2010-03-05 17:04:26, Info       [0x0b0083] WDS    MgLibpOpenLdapConnectionFromDN: DN=CN=testmaskin101,OU=PC,DC=domain,DC=no
    2010-03-05 17:04:26, Info       [0x0b0083] WDS    MgLibpOpenLdapConnectionFromDN: Domain Name=domain.no
    2010-03-05 17:04:26, Info       [0x0b0083] WDS    -> MgLibpOpenLdapConnection
    2010-03-05 17:04:26, Info       [0x0b0083] WDS    MgLibpOpenLdapConnection: Domain=domain.no
    2010-03-05 17:04:26, Info       [0x0b0083] WDS    GetDSSServer: Domain=domain.no
    2010-03-05 17:04:26, Info       [0x0b0083] WDS    GetDSServer: Domain FQDN=domain.no
    2010-03-05 17:04:26, Info       [0x0b0083] WDS    MgLibpOpenLdapConnection: Domain FQDN=domain.no
    2010-03-05 17:04:26, Info       [0x0b0083] WDS    CLdap::Open: Server=domain.no, Port=389, DN=RootSDE

    2010-03-05 17:04:27, Info       [0x0b0083] WDS    CLdap::Search2: BaseDN=, Filter=(objectClass=*), Scope=0

    2010-03-05 17:04:27, Info       [0x0b0083] WDS    CLdap::Open: Server=domain.no, Port=389, DN=DC=domain,DC=no

    2010-03-05 17:04:27, Info       [0x0b0083] WDS    <- MgLibpOpenLdapConnection=0
    2010-03-05 17:04:27, Info       [0x0b0083] WDS    <- MgLibpOpenLdapConnectionFromDN=0
    2010-03-05 17:04:27, Info       [0x0b0083] WDS    -> MgLibpGetSamAccountName
    2010-03-05 17:04:27, Info       [0x0b0083] WDS    MgLibpGetSamAccountName: DN=CN=testmaskin101,OU=PC,DC=domain,DC=no
    2010-03-05 17:04:27, Info       [0x0b0083] WDS    CLdap::Search2: BaseDN=CN=testmaskin101,OU=PC,DC=domain,DC=no, Filter=ObjectClass=*, Scope=0

    2010-03-05 17:04:27, Info       [0x0b0083] WDS    MgLibpGetSamAccountName: samAccountName=testmaskin101$
    2010-03-05 17:04:27, Info       [0x0b0083] WDS    <- MgLibpGetSamAccountName=0
    2010-03-05 17:04:27, Info       [0x0b0083] WDS    -> MgLibpResetAccount
    2010-03-05 17:04:27, Info       [0x0b0083] WDS    <- MgLibpResetAccount=5
    2010-03-05 17:04:27, Info       [0x0b0083] WDS    <- WdsMgResetAccount=5
    2010-03-05 17:04:27, Error      [0x0b007c] WDS    CreateOrResetMachineAccount: Error resetting machine account [CN=testmaskin101,OU=PC,DC=domain,DC=no]. Error [0x80070005].
    2010-03-05 17:04:27, Info       [0x0b007e] WDS    ProcessDomainJoinInformation: MachineName = [(null)], MachineDomain = [(null)]
    2010-03-05 17:04:27, Warning    [0x0b0093] WDS    ProcessDomainJoinInformation: Error resetting machine account. Error [0x80070005].

    ------------------------------------------

    <?xml version="1.0" encoding="utf-8"?>
    <unattend xmlns="urn:schemas-microsoft-com:unattend">
        <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>
                    <Credentials>
                        <Domain>domain.no</Domain>
                        <Password>Password</Password>
                        <Username>Username</Username>
                    </Credentials>
                    <JoinDomain>domain.no</JoinDomain>
                    <MachineObjectOU>ou=pc,dc=domain,dc=no</MachineObjectOU>
                </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">
                <ProductKey>My-Key</ProductKey>
                <ComputerName>%MACHINENAME%</ComputerName>
            </component>
        </settings>
        <settings pass="oobeSystem">
            <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">
                <AutoLogon>
                    <Password>
                        <Value>YgBlAFQAVAAxADEfdgAbwBrAFAAYQBzAHMAdwBvAHIAZAA=</Value>
                        <PlainText>false</PlainText>
                    </Password>
                    <Domain>domain.no</Domain>
                    <Enabled>true</Enabled>
                    <LogonCount>1</LogonCount>
                    <Username>username</Username>
                </AutoLogon>
                <OOBE>
                    <HideEULAPage>true</HideEULAPage>
                    <NetworkLocation>Work</NetworkLocation>
                    <ProtectYourPC>1</ProtectYourPC>
                </OOBE>
                <UserAccounts>
                    <AdministratorPassword>
                        <Value>ZQBjAGwAaQBwgAHMAZjgQAwADIAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgBQAGEAcwBzAHcAbwByAGQA</Value>
                        <PlainText>false</PlainText>
                    </AdministratorPassword>
                    <DomainAccounts>
                        <DomainAccountList wcm:action="add">
                            <DomainAccount wcm:action="add">
                                <Group>Administrators</Group>
                                <Name>Domain Admins</Name>
                            </DomainAccount>
                            <Domain>domain.no</Domain>
                        </DomainAccountList>
                    </DomainAccounts>
                </UserAccounts>
            </component>
        </settings>
        <cpi:offlineImage cpi:source="catalog://myserver/install_windows 7 enterprise.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
    </unattend>

    Friday, March 05, 2010 4:30 PM

All replies

  • It turns out that this was caused by a different answer-file that we used for x64 and x86 architecture for the disc configuration and WDS initialization part of the install. There was a seperate answer file for this, which held credentials in the WinPE section used to access the Image selection in WDS. These credentials were an Installuser with only domain user access. For some reason, these credentials were saved and used later for domain join, even though the following user is a domain admin, which was specified under domainjoin:

    <Identification>
                    <UnsecureJoin>true</UnsecureJoin>
                    <Credentials>
                        <Domain>domain.no</Domain>
                        <Password>Password</Password>
                        <Username>Username</Username>
                    </Credentials>

    So when the computer attempted to join AD, where a prestaged computeraccount had been created with GUID linked to the computer, the following error occured:

    2010-03-05 17:04:27, Error      [0x0b007c] WDS    CreateOrResetMachineAccount: Error resetting machine account

    This action requires domain admin, but my unattended computer install attempted to use the wds credentials from earlier to do this, so it failed every time.

    Quick question to the Microsoft guys: Is this how this is supposed to work, or did I misunderstand how this works? I thought the credentials specified under section 4 (Spezialization) Identification were used, and assumably overwriting any other credentials used earlier in the process. Is this perhaps a bug, or is this how it is intended?
    • Proposed as answer by Jonathan Hall Thursday, March 14, 2013 5:33 PM
    Tuesday, March 09, 2010 12:18 PM
  • I stumbled over the same problem, thanks for your post and the solution!
    Wednesday, March 23, 2011 2:59 PM
  • http://technet.microsoft.com/en-US/library/cc765972.aspx states:

    If UnsecureJoin is enabled, do not create settings for Domain, Username, or Password.

    And further explains how UnsecureJoin works, so I won't bother you with repeating that.

    However I am currently experiencing the same issue as you, however, with UnsecureJoin = true and no settings for Domain, Username or Password.

    It seems that WDS creates the machine account in AD with the credentials you provide as explained in http://technet.microsoft.com/en-us/library/cc754005%28v=ws.10%29.aspx#general under "Prestage Computer". However, after the machine account is created by WDS, it will be linked to the installed computer with the credentials of the InstallUser, thus giving this error. The same document above explains under "Join the domain":

    If the computer is prestaged, then the user performing the installation (or the credentials in the Unattend file for the domain join) needs the appropriate JoinDomain rights. If the computer is not prestaged (meaning Windows Deployment Services will create a computer account in AD DS), the user performing the installation (or the credentials as specified in the Unattend file for the domain join) need rights to add a prestaged computer and the appropriate JoinRights.

    Since you cannot provide credentials for a UsecureJoin, your install user needs the JoinRights You can add them by:

    1. Delegate Control of the Computers OU in AD for the Install User (or wherever you put your newly installed computers) and add a custom task, Computer Objects,  Full Access. (Worked for me)
    2. Follow the instructions in http://technet.microsoft.com/en-us/library/cc754005%28v=ws.10%29.aspx#Perf2 Item: Prestage a computer to join the domain (untested)
    3. Use UnsecureJoin = False (security issue)

    Remember that using a username and password for domain joins (UnsecureJoin = true), actually is less secure that using Unsecure=false. This is further explained in http://technet.microsoft.com/en-us/library/cc730845(v=WS.10).aspx This means that with SecureJoin, any user with access to the computer can press shift+F10 and run notepad c:\windows\panther\Unattend.xml and read your username and password while the computer is installing.

     

     

    Tuesday, March 29, 2011 2:19 PM
  • ok I've gotten this far... I got the same error. here you wrote: 

    Delegate Control of the Computers OU in AD for the Install User (or wherever you put your newly installed computers) and add a custom task, Computer Objects,  Full Access. (Worked for me)

    The setup i have here is I booted the machine to WDS it was an unknown client. I named ant and approved it. I have and unattended file setup for the WINPE part of the setup then I have another unattended file associated with the install image. In the second unattended file I have the UnsecureJoin enabled but it does not work. I tried modifying different things but have not gotten it to work. I renames the computer to the correct name in AD but it doesn't join. The WDS server computer account has full control over the computers OU. I'm not sure which Install User you are talking about. Any assistance would be appreciated. 


    Wednesday, April 06, 2011 5:34 PM
  • I've tried it both ways, secure and unsecure with and without credentials and it hasn't worked since I applied the imageunattend.xml to the image. If I just use the PE-Unattend.xml, it works flawlessly - Of course, there's no customization which is a bigger downside than not joining the domain. It would just be nice if this worked the way it should.

     

     

    Tuesday, April 26, 2011 10:38 PM
  • The WDS server computer account has full control over the computers OU. I'm not sure which Install User you are talking about. Any assistance would be appreciated.
    You need to delegate permission to the user you use to log on when you start the WinPE environment; i.e. the credentials you enter before picking an install image. When you use UnsecureJoin, that user account is the one that is used for the domain join, not the computer account of the WDS server.
    Wednesday, June 29, 2011 2:51 PM
  • Ouch, this is an old thread, but here is what I have working:

    In Active Directory Users and Computers:

    1. Right click on the OU your new computers will appear in (Normally “Computers”) and select Delegate Control
    2. On the first screen of the wizard, click Next
    3. Click Add and then click Object Types, select Computers and click OK
    4. Enter the name of the computer WDS is running on, followed by a dollar sign, e.g. WDS01$, and click Check Names
    5. Enter the user name of the account you have for WDS installations e.g. InstallUser, and click Check Names
    6. Click OK and Next
    7. Select Create a Custom task to delegate and click Next
    8. Select Only the following objects in the folder. Then select the Computer Objects check box, select Create selected objects in this folder, and click Next.
    9. In the Permissions box, select the Write all Properties check box, and click Next and Finish.
    10. On your WDS server, open regedit
    11. Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\AutoApprove key
    12. Open the x64 subkey, and double click on User
    13. Change from Domain Admins to InstallUser
    14. Open the x86 subkey, and double click on User
    15. Change from Domain Admins to InstallUser

    Now computers are generated in AD, and are owned by the InstallUser user, which makes it possible to reinstall them from WDS and rejoin them to the domain as well.

    • Proposed as answer by ryanhoskin Tuesday, August 07, 2012 8:43 PM
    Tuesday, July 19, 2011 1:37 PM
  • Thanks to everyone.  Steps 1-8 from Cleitet's answer did the trick for me.
    Tuesday, August 07, 2012 8:43 PM