Asked by:
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=RootSDE2010-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=02010-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 5, 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 9, 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:
- 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)
- 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)
- 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 6, 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:
- Right click on the OU your new computers will appear in (Normally “Computers”) and select Delegate Control
- On the first screen of the wizard, click Next
- Click Add and then click Object Types, select Computers and click OK
- Enter the name of the computer WDS is running on, followed by a dollar sign, e.g. WDS01$, and click Check Names
- Enter the user name of the account you have for WDS installations e.g. InstallUser, and click Check Names
- Click OK and Next
- Select Create a Custom task to delegate and click Next
- 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.
- In the Permissions box, select the Write all Properties check box, and click Next and Finish.
- On your WDS server, open regedit
- Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\AutoApprove key
- Open the x64 subkey, and double click on User
- Change from Domain Admins to InstallUser
- Open the x86 subkey, and double click on User
- 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 -
Thanks to everyone. Steps 1-8 from Cleitet's answer did the trick for me.Tuesday, August 7, 2012 8:43 PM