1 of 1 people found this helpful
You have the section to join the domain a bit wrong:
You already specify Domain in the line above it. When trying to join the domain it will try now with the user NCE\NCE\Sysprep
Remove NCE\ from the username and it will work a lot better.
I'm certain the response above had something to do with my problem, but the condition persist. When I load an image created by a former admin here with using my deployment script, it works excellent! When I try and load any other image, it doesn't. I've double checked the firewall service but alas, nothing works! I can get all teh way to the end, the Workgroup carries the Domain name and that is what joins, the workgroup. Everything else works great! I just can't get it to stay on the domain?
Is there something more in the windows load you have to do in order to get it to work correctly? (besides shut down the firewall)?
I would like to ask, are you saying you deploy a image made by a former admin using your osd script AND your answer file and it works?
If this is the case then it points to your answer file and osd script being good. However if the image is a .TBI use TBIVIEW and see if there is a answer file in the windows\panther or windows\system32\sysprep folder or windows\system32\sysprep\panther folder. It could be running that and not your answer file.
Using LD 9.5 am I to capture the image using Audit (no Generalize) or am I to use OOBE with Generalize? I referenced an older doc that said to use Audit and No Generalize.
We tryed using Audit and had problems with drivers not being installed on the deploy side. We are using OOBE with generalize on the capture side.
We are using LD 9.5
I use ODBE with Generalize and I didn't have any problems joining it to the domain until I used the option to move the computer into a specific OU in AD. If you are using that option then you may want to first try it without. I am currently trying to figure out how to get that working.
Using Full-Qualified-Domain-Name can help too:
Also check the netsetup.log in Windows 7 (c:\windows\debug), it should give you an error as to why the join domain fails.
Saw simaler thread..... Here is the section we use. The catch is that if you do not supply a MachineObject domain join will attempt to in default Computer OU. Which begs the question. Does your account have access to that OU?
<component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">