jump to navigation

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

Posted by keithga in MDT 2010, Troubleshooting.
Tags: , ,
trackback

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
Advertisements

Comments

1. Kai - January 31, 2012

I too am am having that same issue with the SLShareDynamicLogging=\\servername\logs$ issue (that’s not the actual path). Same thing, I ensure it is fully shared in NTFS, etc… would be interested in knowing what the issue might be, if you figured it out for the above entry.

2. ts - November 16, 2009

Tried that 😉 No luck! The only logging related to this I can see is the entry in BDD.log where the value of SLSHAREDynamicLogging is passed.

3. ts - November 14, 2009

Keith, I get no logging when I add SLShareDynamicLogging to my CustomSettings.ini. The build account has share and NTFS perms for the logs share. If I add in the SLShare property to customsettings I get the SMSOSD log folder dumped to the share at the end of a build, however it only contains the TS log let at the end of a build and not the full BDD.log…any ideas?

tmintner - November 16, 2009

Hello,

What value do you have the SLSHAREDynamicLogging set in the customsettings.ini?

ts - November 16, 2009

Hi Tim; its set to
\\myserver\logs$\%OSDComputerName%

tmintner - November 16, 2009

Out of curiousity does it work if you take off the %OSDCOMPUTERNAME% just set it to \\myserver\logs$

ts - November 16, 2009

Tried that No luck! The only logging related to this I can see is the entry in BDD.log where the value of SLSHAREDynamicLogging is passed.

tmintner - November 16, 2009

Interesting can you email me your bdd.log file tim AT xtremeconsulting dot com

4. When things go wrong during MDT Deployment (Part 1) « Xtreme Deployment - Rod Trent at myITforum.com - October 23, 2009

[…] When things go wrong during MDT Deployment (Part 1) « Xtreme Deployment Filed under: Microsoft Deployment […]


Sorry comments are closed for this entry