Before you can troubleshoot BDD 2007 you need to clearly understand the many logs used during an OS deployment.
If you understand what log to refer to and at what time you will find things that where once mysterious become understandable.
With this in mind I thought I would provide this quick guide to BDD logs.
BDD scripts automatically create log files. Each script creates a log file that matches the name of the script, for example ZTIGather.wsf creates a log file named ZTIGather.log. Each script also updates a common log file (BDD.log) that aggregates the contents of logs created by the BDD scripts. BDD logs are located in the C:\MININT\SMSOSD\OSDLOGS folder during the deployment process. They are then moved at the completion of a deployment, their destination is dependent on the deployment type:
The BDD.log file is also copied to a network location at the end of the deployment if the SLShare value is specified in the Customsettings.ini.
The BDD log format is designed to be read by TRACE32, part of the SMS 2003 Toolkit 2 - download here. I would strongly recommend that you use this tool whenever possible to read the logs as it makes finding errors much easier.
The rest of this blog details the log files that are created during the deployment and examples of when they can be used when troubleshooting.
Bdd.log - The aggreated BDD log file.
<Scriptname>.log - A log file created by each BDD script.
Wizard.log - Updated by BDD wizards.
DeployUpdates_platform.log - Created when deployment points are updated. Also used when updating Windows PE. Useful when troubleshooting Windows PE driver integration issues. This log is located in the %temp% folder.
SMSTS.log - Logs all of the transactions for the Task Sequencer. This will be located in %TEMP%, C:\Windows\System32\ccm\logs, or C:\SMSTSLog, depending on the situation.
WPEinit.log - Logs the Windows PE intialisation process - Useful for troubleshooting error starting windows PE
BDD 2007 automatically adds the logging switches to save the USMT logs to the BDD log file location
USMTEstimate.log - Log created when estimating the USMT requirements
USMTCapture.log - Log created when capturing data
USMTRestore.log - Log created when restoring data
This is a subset of the log files that are most useful for troubleshooting deployment issues, for more detailed information about Vista setup log files refer to this KB - http://support.microsoft.com/kb/927521.
setupapi.dev.log - Windows setup log, located in C:\Windows\inf - Useful for investigating failed Driver installations.
setupact.log - Windows setup log, located in C:\Windows\panther - Useful for investigating failed installations.
setuperr.log - Windows setup log, located in C:\Windows\panther - contains a list of errors that occurred during installation.
netsetup.log - Windows setup log, located in C:\Windows\Debug - useful for troubleshooting domain join issues.
setupapi.log - Windows setup log, located in C:\Windows - record inf installation actions - useful for investigating failed driver installations.
setupact.log - Windows setup log, located in C:\Windows - Lists installation actions.
setuperr.log - Windows setup log, located in C:\Windows - Details installation errors.
netsetup.log - Windows setup log, located in C:\Windows\Debug, useful for troubleshooting domain join issues.
The following logs are created during the deployment phases, these logs are located in the C:\MININT\SMSOSD\OSDLOGS folder:
OSDAgent.log - This is the primary log and should be the first place you look to determine what step failed
OSDEnv.log - Indicates which OSD environment variables are set
OSDInstallWIM.log - Logs image installation options
IDUser.log - User notification log
IDUserNotification.log - User notification log
MachineState.log - Logs computer state migration information (computer name, IP Address, Registered Owner/Org
WinPEInstall.log - WinPE installation information
Exec.log - Logs ‘Run SWD Program’ actions
scanstate.log - USMT scanstate log
OSDLaunch.log - OSD Bootstrap - May contain errors if the Advanced Client Network Access account is not configured correctly.
SMSCMT.log - Logs SMS Client migration information (site code, client GUIID)
WinPEInstall.log -Windows PE installation information.
OSDInstallWizard.log - Logs start-up operations.
OSDShell.log - Launches the OSD Install Wizard.
OSDSWDProgramExec.log – Logs Run SWD Program Actions.
OSDUsmtScanstate.log – Logs Capture User State operations
OSDUsmtLoadstate.log - Logs Restore User State operations
OSDBootstrap.log - May contain errors if the Advanced Client Network Access account is not configured correctly.
Note: The C:\minint folder is lost during the disk partitioning process. If you need to trobleshoot issues that occur before this point then disable the disk partitioning task in the task sequencer.
Hello, nice tutorial would you please explain how to use bdd/winpe 2.0 with drivers.
how to integrate sata drivers in offline wim-image.
the most annoying this is that intel sata drivers are not incluede in winpe 2.0 by default. When we apply wim image through bdd the computer reboots without warning. no accesible boot device found.
no support for realtek ac97 sound and maaannnyyy others....
many thanks in advance.
You simply import the drivers into the deployment workbench. Then when you update the deployment point BDD will automatically integrate them into Windows PE 2.0.
Are you sure that Windows PE 2.0 does not include the Intel sata drivers? I have had no issues.
I've had loads of issues re SATA drivers on HP laptops. They're a complete nightmare.
Hi Simon, Contact me via email on ben.hunter at microsoft.com and I can forward you some information on this issue.
Q. What log files can be evaluated to troubleshoot deployment issues with Windows Vista? A. The primary
I am finding that after my deployments complete, the log files are being copied to SLSHARE with the original name of the PE host which is randomly generated. So basically I have a series of log files saved as MININT-xxxxxx.log which don't really bind back to the original host name. For new computers I am not generating computer names automatically from the database but entering them in manually in the litetouch wizard.
Do you know of any way to fix this? There appears to be a "figure out the computer name" section in the CopyLog() function in ZTIUtility.vbs but I can't seem to make head nor tail of it.
This is caused by the way that BDD decides on the name for the log file.
You will need to update the copylog function replacing the "HostName" variable with "COMPUTERNAME". Please note that I generally don't recommand updating any of the core BDD files but if you are really keen then here is the updated section of the copylog function:
If oEnvironment.Item("OSDCOMPUTERNAME") <> "" and Instr(oEnvironment.Item("OSDCOMPUTERNAME"), ":") = 0 then
sComputer = oEnvironment.Item("OSDCOMPUTERNAME")
ElseIf oEnvironment.Item("OSDNEWMACHINENAME") <> "" then
sComputer = oEnvironment.Item("OSDNEWMACHINENAME")
ElseIf oEnvironment.Item("OSVersion") = "WinPE" then
re.Pattern = ":"
sComputer = re.Replace(sComputer, "")
sComputer = oEnvironment.Item("COMPUTERNAME")
Is there any tricks to incorporating the Intel Storage Matrix driver install with BDD? I work for a PC Vendor (you are probably working off of our product at work), and a customer is not finding success in getting the system to boot other than in compatibility mode after imaging with BDD.
you mighthave a look at the following two blogs I have posted previously, they detail how to integrate the intel storage drivers.
Great site, When I update drivers on my BDD , then update the deployment point, it completes without any errors, but when I push the image to the test machine it runs the script , restarts then hangs. What could be the issue here,
This is most likely caused by one of two issues:
1. The image HAl does not match the hardware you are applying it to.
2. The image does not contain the correct storage drivers.
Is the HAL type correct?
When developing a build it is often useful to have it in debug mode. Debug mode is when log content is
I am very happy with the progress of the deployment guys blog so far. Hopefully you all agree that we
thanks for your feedback, but I'm not sure where to check to see if the HAL type is correct.
I have 2 images. I have a deployment point and a task sequence for each. Both images use the same DB for my make and models.
One of my models, a Panasonic CF51R, when imaged with the first image, everything installs properly. When imaged with the second image, the modem will not install (an application added under the application tab in that make/modem in the DB)and gives a return code: -1073741818. The application for the modem simply runs the install file "HXFSetup.exe". This is a silent install and when run manually from the resource$ folder, it installs fine. It just won't install during the image process. Any thoughts/suggestions?