Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, June 14, 2012 1:50 PM
Good Afternoon!
I have had much experience with SCCM 2007, but am still getting used to SCCM 2012. Today, I set up and deployed my first test OSD deployment.
Everything worked fine except one little thing - the computer did not join to the domain.
Below is what I've tried to get this resolved...
- Verified credentials in TS were correctly entered
- Tested and was able to join the same computer TS was run on to the domain using the same credentials (including their formatting) which are in the TS.
- Checked the NetSetup.log in C:\Windows\Debug - It didn't exist. After joining the domain manually in the step above, it did, though.
- I didn't see anything that stood out in the smsts.log.
I'll be happy to attach any log files if needed. Any suggestions? THanks!
Ben K.
All replies (19)
Thursday, June 14, 2012 3:16 PM
Hello Ben, can you check the following logs, under C:\Windows\Panther\UnattendGC: setupact.log setuperr.log If you're using the Apply Operating System step to join the domain, it is not SCCM that is actually doing the job. It only injects the required information in the unattend.xml. The OS then joins the domain on its own, not using SCCM.
Thursday, June 14, 2012 4:35 PM
Thanks -
I just looked and found those two logs.
The setupact.log was about 400k (which i had to take ownership to view) and the setuperr.log was totally empty, though. I looked through the setupact.log, but didn't see anything that stood out. I'm going to try to reimage again and see what happens.
setupact.log did end with "windeploy.exe exiting with code 0x0", though.
Any other suggestions?
Thanks!
Ben K.
Thursday, June 14, 2012 5:32 PM
I think that ConfigMgr did not try to join it to the domain if netsetup.log does not exist. Have you reviewed the status messages from that client or used the SRS reporting point to view the TS related reports? Any errors during the execution of the task sequence? Are you using the default TS step to join the domain?
Torsten Meringer | http://www.mssccmfaq.de
Friday, June 15, 2012 8:14 PM
Thanks for your reply...
I've reviewed tons of logs and looked through messages. Still, I can't find anything related. I even created a new, plain TS with similar settings which didn't join either.
Log Files
I just rechecked the TS yest again, then ran it once more on a physical computer. I even moved the Drivers step above the Network Settings step as suggested.
I compressed all log files into an RAR which is below. In the root of it is ccmsetup.log. setupact.log, and setuperr.log (empty). The Logs folder is a direct copy of the C:\Windows\CCM\Logs folder except a find/replace was done on some things.
Log Files (Dropbox Link - 133kb)
If you have a chance to take a look and help me out, I'd really appreciate it!!! Thanks again for your help!
Ben K.
Sunday, June 17, 2012 3:39 PM
The Apply Network Settings task populates values in the unattend.xml file in use; from there its completely up to Windows Setup to join the domain using these values thus there will be nothing in smsts.log.
Moving the Apply Drivers tasks above this task has zero effect because as mentioned, all this task does is populate the unattend.xml file.
When are you checking for the netsetup.log? It won't exist until after the Setup Windows and ConfigMgr task.
Jason | http://blog.configmgrftw.com | Twitter @JasonSandys
Tuesday, August 20, 2013 6:53 PM
Hi,
This is an old post but I am having the same issue.
- The machine does not join the domain
- I am placing the computers into and OU and not the "Computers" container
- The netsetup.log does not exist
- The report mentions "No adapter environment available"
- The drivers install fine
Any help or idea would be appreciated
Tuesday, August 20, 2013 8:47 PM
Where are you looking for netsetup.log? It's not going to be in the ConfigMgr logs folder because (as mentioned) it's not a ConfigMgr process.
If the netsetup.log does not exist in the normal Windows location, then you are not even getting to that part in Windows setup which indicates you do not have the proper NIC derivers available during Windows setup.
Jason | http://blog.configmgrftw.com
Tuesday, August 20, 2013 9:09 PM | 1 vote
Correct.
The Netsetup.log is a windows process and resides in the C:\Windows\debug directory. And, yes the log isn't there.
Which avenues do you suggest I investigate.
________________________________
Aly
Tuesday, August 20, 2013 9:24 PM
As mentioned, your issue is within Windows setup so now you need to dive into the other Windows setup logs: http://technet.microsoft.com/en-us/library/dd744583(v=WS.10).aspx
So exactly what state is the target system left in when the TS exits?
Jason | http://blog.configmgrftw.com
Tuesday, August 20, 2013 9:37 PM
After the TS finishes, the system is automatically logged into the local administrator account without joining the domain.
A
Tuesday, August 20, 2013 9:57 PM
I also notice the OU path and domainjoin account details are available in the unattend file located in C:\Windows\Panther\unattend\unattend.xml
Tuesday, August 20, 2013 10:15 PM
ConfigMgr OSD never logs into the target system -- are you sure that this isn't stand-alone/LiteTouch MDT?
Are you trying to do something odd like use auto-login?
The OU Path and join account in the unattend.xml is normal -- that's how Windows setup gets that information.
Jason | http://blog.configmgrftw.com
Friday, June 20, 2014 11:51 AM
Well, this topic may be old and unanswered, but exactly now I'm facing the same error as AlyGr.
It has to be mentioned that I did not have issues with the first version of my image (v0.1). However, somewhere along the way, something got changed in the image, and now the domainjoin fails (v0.5).
As a test I made one task sequence with the domain-join step included, and tested it on both images. V0.1 joins the domain and completes the task sequence. V0.5 only installs the drivers (WinPE) and then (re)boots to Windows. Instead of rebooting and "installing devices" (the black screen with "installing devices" at the bottom".
Any help or tips are very welcome!
If you found this post helpful, please “Vote as Helpful”.
If it answered your question, please “Mark as Answer”.
Christian Gude | www.itexperience.net
Friday, June 20, 2014 11:57 AM
What's the difference between V0.1 and v0.5? What has changed? Have you already examined netsetup.log?
Torsten Meringer | http://www.mssccmfaq.de
Friday, June 20, 2014 12:35 PM
Hi Torsten,
there is no netsetup.log. As stated earlier in this topic, I'm also convinced that the phase where it goes wrong has nothing to do with SCCM. It looks like the hardware installation phase is somehow skipped.
The difference between version v01 and v05 are feature installations and software installations. We are building a thick image. It has now grown to approx. 30 GB. Nothing's really special about the image. Except the large application installations.
We capture the image with a SCCM Capture task, which has always done his job right. :)
I'm now going to recapture the image. I hope this was just a small bug with the last capture. I use TSMBAutorun to capture to an image. Since I am at a customer now and this is my last day over here, I cannot guarantee to give feedback on the status of the capture and imaging task. If possible, I will post the result in this topic.
If you found this post helpful, please “Vote as Helpful”.
If it answered your question, please “Mark as Answer”.
Christian Gude | www.itexperience.net
Friday, July 18, 2014 9:02 AM
My colleagae found the problem:
Somewhere between version V01 and V05, we enabled IIS Admin Service in the operating system and then captured the image. It looked like there was an issue that causes sysprep to crash when IIS Admin Service was started (or: sysprep could not start, because the IIS Admin service fails to start during image deployment).
More info and discussion:
http://social.msdn.microsoft.com/Forums/en-US/8c71a9e8-3e9c-4880-84bc-fcae16f85bda/sysprep-problem-on-wes-7?forum=quebecservicingdeployment
Solution: sc delete "IISADMIN" before starting sysprep.
Then later in task sequence, recreate the IISAdmin service if required...
If you found this post helpful, please “Vote as Helpful”.
If it answered your question, please “Mark as Answer”.
Christian Gude | www.itexperience.net
Wednesday, December 30, 2015 3:07 AM | 1 vote
don't know if you have your issue resolved yet but I ran into the same issue before. Try this.. For the Network Settings TS, put in the Domain information and leave the Domain OU: field empty. If you Browse to the Domain OU and point it to "Computers" OU container, it will cause issues. If you point it into a proper structure OU container other then "Computers" or leave it empty, you should be fine.
hope this help
Tuesday, May 3, 2016 4:37 PM
don't know if you have your issue resolved yet but I ran into the same issue before. Try this.. For the Network Settings TS, put in the Domain information and leave the Domain OU: field empty. If you Browse to the Domain OU and point it to "Computers" OU container, it will cause issues. If you point it into a proper structure OU container other then "Computers" or leave it empty, you should be fine.
hope this help
So if you leave your OU field empty and don't specify a target OU for your Computer, where does it place the Computer if not in the Computer OU?
Wednesday, May 4, 2016 2:56 AM
There's no such thing as the Computers OU -- there is a default Computers container. This is core of the problem and is explicitly why you can't specify it. If you leave the OU blank, then the container or OU specified as the default in AD will be used and by default, this is the Computers container.
Jason | http://blog.configmgrftw.com | @jasonsandys