Problems autojoining Win 7 client to domain using unattend-file

All replies

• 

  

  2

  Sign in to vote

  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 9, 2010 12:18 PM
• 

  

  0

  Sign in to vote

  I stumbled over the same problem, thanks for your post and the solution!
  

  Wednesday, March 23, 2011 2:59 PM
• 

  

  1

  Sign in to vote

  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
• 

  

  0

  Sign in to vote

  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 6, 2011 5:34 PM
• 

  

  0

  Sign in to vote

  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
• 

  

  0

  Sign in to vote

  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
• 

  

  2

  Sign in to vote

  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 7, 2012 8:43 PM

  Tuesday, July 19, 2011 1:37 PM
• 

  

  0

  Sign in to vote

  Thanks to everyone.  Steps 1-8 from Cleitet's answer did the trick for me.

  Tuesday, August 7, 2012 8:43 PM