Troubleshooting OSD in SCCM

Posted by Wayne on July 16th, 2009 filed in Vista Deployment, Windows 2008, Windows 7

You just have to love TLA’s! OK, TLA = three letter acronym and SCCM is four letters, but you know what I mean; our industry thrives on acronyms. Translating: Troubleshooting Operating System Deployment in System Center Configuration Manager 2007. Hang on, this blog is for Vista and Windows 7, not System Center! Well, it is, but Kyle agreed I could also blog about Server products as well. And, in reality, a lot of you will be looking to some form of managing your operating system deployments; Windows 7, Server 2008, Vista, Server 2003 and Windows XP can all be managed through the OSD component of Config Manager 2007. As such, this rather lengthy post will deal with some troubleshooting tips.

Enable the Debug Shell on your boot image

Boot images have an option to enable a command shell while running in Windows PE.  This is turned off by default for security reasons (since it would allow an end user to open a command shell during the re-imaging process) but can be enabled on the “Windows PE” property page.

  1. Open the boot image’s properties dialog
  2. On the Windows PE tab check the “Enable command support (testing only)” option
  3. Update the boot image on the distribution points
  4. Rebuild any media that uses the boot image (e.g. capture media, boot media, or stand-alone media)

When a task sequence is running in Windows PE you can open a command shell by pressing F8.  As long as the command-shell is open the task sequence will not reboot the machine. This will give you a chance to verify network connectivity, diagnose driver issues, and view/copy the log files (see Client Log Files section below the screenshots).

boot image properties

Client Log Files

All actions in a task sequence log to the smsts.log file.  This file is moved around during different stages of an operating system deployment so that it does not interfere with the imaging process. 

  1. While in Windows PE the log file is stored in the windows temp directory on the RAM-disk (typically x:\windows\temp\smstslog)
  2. While in a full operating system that has a ConfigMgr client installed the log file is located in the smstslog subdirectory under the client logging path (typically %windir%\system32\ccm\logs\smstslog)
  3. While in the full operating system that does not have a ConfigMgr client installed the log file is located in the Windows temp directory (typically %windir%\temp\smstslog)

When the task sequence completes, the log file is “finalized” to one of the following locations depending on the state of the machine:

  1. If the task sequence finishes in Windows PE the log file is copied to an SMSTSLog directory on the largest available partition.
  2. If the task sequence finishes in the full operating system and a ConfigMgr client is installed then the log is copied to the client logging path (typically %windir%\system32\ccm\logs)
  3. If the task sequence finishes in the full operating system and there is no ConfigMgr client installed then the log is copied to the Windows temp directory.

Task Sequence Reports

When running, task sequences send status messages back to the server for each step in the task sequence.  Included in these status messages are the last 1024 characters of stdout/stderr text from the action.  Many times, this information can be used to remotely diagnose a task sequence issue (especially useful if an error has occurred in Windows PE and the debug shell was not enabled).  The “History – Specific task sequence advertisements run on a specific computer” report provides a list of these status messages for a specific advertisement and computer and can be opened from the Reports node in the ConfigMgr console.

I hope this gives you an idea of what and how to start tracking down problems when deploying images, flick me an email if you found this article useful.

Lastly, a shout-out to my course 6451 students this week, it’s been a fun 5 days: Colin (WSUS), Stewart, Nirav, Nathan and, last but not least, Ruth  – her pc supplied the screenshots and is my first student to ever get the Emulated Windows Mobile Device lab to work!!.

targets down, patch out.

Wayne

Leave a Comment

Locations of visitors to this page