jump to navigation

Troubleshooting Database Issues with MDT 2010 November 4, 2009

Posted by tmintner in MDT 2010, Troubleshooting, Uncategorized, VBscript.
Tags: , , ,
add a comment

There have been a few really great posts on how to troubleshoot database connection issues with BDD and MDT over the past couple of years.  Ben Hunter wrote a great post on this here: http://blogs.technet.com/benhunter/archive/2007/07/10/bdd-2007-troubleshooting-database-issues.aspx.  However, if you try to do this with MDT 2010 you will get a few errors in the output.  In MDT 2010 the structure of the scripts have changed somewhat and the functionality of ztigather has been extended to also gather additional information that now requires some compiled code.  So with MDT 2010, you can perform the same steps with the following modifications:

1. Create a folder on the client device and copy the following files from the deployment point to this folder:

  • ZTIGather.wsf
  • ZTIGather.xml
  • ZTIUtility.vbs
  • CustomSettings.ini
  • ZTIDataAccess.vbs (new script file in MDT 2010 for accessing data sources)
  • Create a Tools folder and create an X86 and X64 folders underneath the Tools folder.  Copy the Microsoft.BDD.Utility.dll file from the Tools\X64 and Tools\X86 folders in your deployment share to your newly created Tools\X86 and Tools\X64 folder

  2. Delete C:\MININT directory if it already exists. This folder can also be located at X:\MININT if the C drive is not available.

NOTE: MDT stores configuration and progress information in the MININT folder, if this folder is not removed between tests then the results will be invalid.

  3. From the command prompt navigate to the newly created folder and execute the rule processing script using the following command:

“cscript.exe ZTIGather.wsf /debug:true”

      The script will then be processed and the results outputted to the command prompt and a log file ( .\MININT\SMSOSD\OSDLOGS\ZTIGather.log)

NOTE: The script can be run within Windows PE or the host operating system.

  4. Review the results of the script.

Enjoy!

Tim Mintner is a Principal Consultant with Xtreme Consulting Group

Recovery cmd.exe in Litetouch WinPE October 29, 2009

Posted by keithga in MDT 2010, Troubleshooting.
2 comments

(New for MDT 2010)

One of the things we worked on for MDT 2010 were improvements to the user interface for “New Computer” scenarios in the Windows Pre-installation Environment (WinPE).

WinPE is used by MDT 2010 Litetouch, and SCCM to prepare the machine for OS installation. It’s a bare bones implementation of Windows, with out the Windows Shell (Start Button), and typically only runs with a command prompt “console” window.

One of the distracting things about BDD 2007 and MDT 2008, was the Console window that appeared at the start of the WinPE Litetouch New Computer” process. It really didn’t do anything, was a little distracting, and didn’t give MDT the feel of a polished product.

It’s fairly easy to use a different shell for WinPE, however we were concerned about proper error recovery. If something goes wrong with any child script in the process, we want to ensure that we have a chance to debug the problem before the machine reboots. If we replaced the standard WinPE shell with something that didn’t properly handle errors, then WinPE could reboot before we knew what happened.

We also wanted the ability to break out into a cmd.exe prompt if we needed to debug a background process or verify something else.

The final solution was to make some modifications to BDDRun.exe to act as a wrapper around wpeinit.exe. It does two things:

  • It calls wpeinit.exe, and if wpeinit.exe returns any failure, it will launch a cmd.exe prompt allowing debugging.
  • It also launches a thread in the background monitoring for the user to press the F8 button, if pressed, it will launch a cmd.exe window for debugging.
  • If there are any instances of cmd.exe (spawned by pressing F8), and wpeinit.exe exits ready for a reboot, the bddrun.exe program will wait until all cmd.exe windows are closed. So be sure to close all windows if you expect the process to continue.
  • If you wish to disable the F8 feature, modify the unattend_pe_x86.xml and unattend_pe_x64.xml in the templates directory of your MDT 2010 installation, and replace “/Bootstrap” with “/BootstrapNoSF8”.

Not sure why someone would want to disable the F8 windows (perhaps the F8 keystroke conflicts with another application. Disabling F8 won’t make things secure. Someone could still come in with a WinPE DVD and bypass the security.

Why is it called “SF8″ not “F8″? I had originally programmed the keystroke to be Shift-F8 (similar to the Shift-F10 used by Windows Setup. However the feedback I got from early builds is that it should mimmic SCCM behaviour which uses just F8. I changed the keystroke from F8 to Shift-F8, but forgot to change the command line string from /BootstrapNoSF8 to /BootstrapNoF8. Sorry about that…

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

How to debug MDT Litetouch/Driver Problems October 28, 2009

Posted by keithga in MDT 2010, Troubleshooting.
Tags: , ,
1 comment so far

Someone posted a question yesterday about some problems they had getting a driver installed via MDT. In a previous job, I worked in Microsoft Developer Support supporting the Windows Device Driver Kit. I even wrote several driver installation KB articles, and samples for the Windows 2000 & XP DDKs. Most recently, I re-wrote the ZTIDrivers.wsf script for MDT 2010.

Here is a quick overview for adding (non-boot) drivers in Windows. (Please note: Windows XP/2003 Boot drivers use a different process. Drivers like Storage Drivers. )

ZTIDrivers.wsf process

ZTIDrivers.wsf does not actually install a driver for each device during an OS installation. Instead during the pre-installation phase it will:

  • Gather a list of all devices on the machine and their corresponding Plug and Play Device ID (PnPID). 
    A PnPID might look something like: PCI\VEN_8086&DEV_27C9&SUBSYS_01C21028
  • It will then search for any matches in the “Out-of-Box Drivers” folder on your Deployment Share ( in the Out-of-Box Drivers folder, and the control\drivers.xml file).
  • For each driver package found, it will copy the driver locally into the c:\drivers folder.
  • For each folder added into c:\drivers. The folder will be added to the registry:
    HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath
  • When the real OS begins installation, and it finds new devices, it will look in these paths for the drivers.

ZTIDriver.wsf assumptions:

Most of the time, it works just fine, however there are some things are assumed:

  • You must be using a driver that contains at least one PnPID match with the device being installed.
  • Windows will only auto-install drivers that have a valid Driver Signature.
    If one file has been modified, or corrupted, even the *.inf file, the Signature is no longer valid.
  • You might be able to install non-signed drivers depending on the OS, but not for new OS’es like Vista 64-bit.
  • It is possible that there may be other drivers on the local machine that the OS feels are a better match to the driver from the Out-of-Box drivers folder.
  • It is also possible that the device just isn’t working, or the driver just doesn’t work.

I typically only use drivers that are WHQL signed (Disclaimer: I used to work for Microsoft, WHQL), and since Windows Vista, Windows Server 2008, and Windows 7, 64-bit modes will only support signed drivers, it’s usually a good idea to get into the habit of using Signed Drivers only.

Shout out: Michael Niehaus was kind enough to add a check for signed drivers in the MDT 2010 Workbench Driver Import routines. (Thanks Mike!)

To see if your driver is signed, go into the MDT 2010 Workbench, Out-of-Box Drivers, and find your Driver. When found, open the “Properties” page, “Details” tab, and verify the checkbox at the bottom of the screen: “This driver is WHQL signed”.

Debugging Steps:

If you are having troubles with device drivers, it’s typically a good idea to start looking at some basic things:

  • Verify that you have the correct drivers imported into the workbench. Including:
    • Go into the MDT Workbench and find your driver. Verify that the drivers are installed.
    • You should also be able to verify the drivers are present in the Deployment Share.
  • Test the deployment on physical hardware with the actual device installed. It may not be possible to test Video Driver X with Video Card Y, unless they have a subset of matching PnPID’s.
  • Look to see if the Drivers were copied by ZTIDrivers.wsf.
    • You should see ZTIDrivers.wsf identify the PnPID for your device.
    • You should also see ZTIDrivers.wsf xcopy the driver from the Deployment Share locally.
  • If the device and corresponding driver were found by ZTIDrivers.wsf and copied locally. Then Windows should find the device and install. Best place to look for more information is the SetupAPI.log file, used by the PnP Subsystem to log all issues with Device Driver Installation.

More information:

Windows Vista setup log file locations
Troubleshooting Device Installation with the SetupAPI Log File
Windows Setup and Device Installation Logging
Troubleshooting Device and Driver Installations

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

When things go wrong during MDT Deployment (Part 3) October 24, 2009

Posted by keithga in MDT 2010, Troubleshooting.
Tags: , , ,
add a comment

Reading the files…

Microsoft Deployment Toolkit 2010 writes log files to the bdd.log file in a standardized format use by the SMS team. This log file format looks like XML.

Example:

<![LOG[Property debug is now = TRUE]LOG]!>
<time="00:19:03.000+000" date="10-15-2009" 
component="ZTIWindowsUpdate" context="" 
type="1" thread="" file="ZTIWindowsUpdate">

As you can see, that’s a lot of text to just write out: “Property debug is now = TRUE”.

To assist in reading these log files, I use the trace32.exe program written by Microsoft. You can download this program for free at Microsoft as part of the: “System Center Configuration Manager 2007 Toolkit” This program displays MDT log files in a easy to read format.

Another cool feature of trace32.exe is that it does a good job of monitoring changes to the log files when being written to. You can see the changes being performed in real time within trace32.exe.

Link: http://www.microsoft.com/downloads/details.aspx?FamilyID=948e477e-fd3b-4a09-9015-141683c7ad5f&DisplayLang=en

(Updated: 10/26/09 to fix formatting)

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

When Things go wrong during MDT Deployment (Part 2) October 23, 2009

Posted by keithga in MDT 2010, Troubleshooting.
Tags: , ,
add a comment

Other Log files…

In a continuation of my last post on debugging Litetouch failures by viewing the bdd.log file. Let me also discuss some of the *other* log files that may appear during a Litetouch Deployment.

  • During WinPE bootup, there may be problems with the WinPE itself, for example the network driver may fail to load. Look in x:\windows\system32\WPEInit.log, for details
  • During Windows Vista and Windows 7 setup, any setup errors should be logged in the panther directory. A good description of these files, and where they are located can be found here: http://support.microsoft.com/kb/927521.
  • When performing a domain join, Windows will write logging information to: c:\windows\debug\netsetup.log.
  • During a State Capture and State Restore (USMT), MDT will write to the standard MDT log file locations to the files: USMTEstimate.log, USMTCapture.log, USMTRestore.log.
  • Finally, in Litetouch scenarios, when processing the tasks defined in the task sequence list, the SCCM Stand Alone Task Sequencer will write to a file called smsts.log. Typically this file is located at %Temp%\smsts.log. However, you can also tell by searching within the bdd.log file. If Litetouch sees where the smsts.log file is located then it will log the path. Just search for smsts.log. Also, when complete, Litetouch will archive the smsts.log file to the c:\windows\temp\deploymentlogs\smsts.log location like bdd.log.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

When things go wrong during MDT Deployment (Part 1) October 23, 2009

Posted by keithga in MDT 2010, Troubleshooting.
Tags: , ,
9 comments

Occasionally, things do go wrong during MDT deployment.

Most of the time the best place to start looking is the Bdd.log file. While on the MDT development team, we tried hard to ensure that the client scripts wrote to the logs frequently, so we could debug problems later with minimal effort.

Typically each script will write out to a corresponding log file *and* to bdd.log. So for example if you were running the ZTIWindowsUpdate.wsf script, that script would write out to ZTIWindowsUpdate.log *and* bdd.log.

MDT Litetouch log files are written to a common location, bdd.log. This log file is located typically in one of the following locations:

  • If you are running from a WinPE boot disk, and the local machine does not yet have any partitions defined, typically the logs are located on the WinPE Disk: x:\MININT\SMSOSD\OSDLOGS\bdd.log.
  • After the main hard disk partition on the client machine has been created, MDT will start logging to the local c: drive at: c:\MININT\SMSOSD\OSDLOGS\bdd.log. Typically, during scenarios when we are not installing an OS from scratch, this is the default location for Log files. For example if we are running a Task Sequence that is installing a set of applications only.
  • When the entire Litetouch process is finished, MDT will archive the contents of the logs to c:\windows\temp\depoymentlogs\bdd.log.
  • Also if you have the variable SLShare defined, when the Litetouch Process is finished, MDT will archive the contents of the log to that share. For example: SLSHARE=%DeployRoot%\BDDLogs.

There is a new property I created for MDT 2010, called SLShareDynamicLogging. For example: SLShareDynamicLogging = \\MyServer\PublicWriteShare\MDTLogs\. This property will write debugging information to the network share defined in addition to c:\MININT\SMSOSD\OSDLOGS. Please be aware that MDT 2010 writes a *lot* of debugging information to the log, and adding another logging destination will slow down MDT. I recommend using it only in advanced debugging scenarios when you can’t access the log files on the client machine.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group