Problem: How do I determine the problem more easily when I receive an error during deployment?

Solution:  In short, the answer is basically look in your logs and find out but there are some tricks you can use to make it easier for you.  Personally I’ve spend countless time trying to diagnose a problem and some of these tips should hopefully help you save some of that time in your environments.

I work with many different networks, each network presenting a different problem.  From different switches and wireless infrastructure, different software on images different hardware models to image, the list goes on.  Rather than being onsite and administering just the one network, in my role I have many to look after and it sometimes feels like I am never going to get everything working just as I want it because I simply don’t get enough time to iron out all the niggles.

Firstly, as the title says, know your logs. The MDT documentation is pretty good, I suggest you spend some time reading through it paying particular emphasis on the log files and what they do.  Here is a small snippet for you:

Each MDT script automatically creates log files during its execution. The names of these log files match the name of the script—for example, ZTIGather.wsf creates a log file named ZTIGather.log. Each script also updates a common master log file (BDD.log) that aggregates the contents of the log files that MDT scripts create. MDT log files reside in C:MININTSMSOSDOSDLOGS during the deployment process. Depending on the type of deployment being conducted, the log files are moved at the completion of the deployment to either %WINDIR%SMSOSD or %WINDIR%TEMPSMSOSD. For Lite Touch Installation (LTI) deployments, the logs start in C:MININTSMSOSDOSDLogs. They end up in %WINDIR%TEMPDeploymentLogs when task sequence execution is complete.
MDT creates the following log files:

  • BDD.log. This is the aggregated MDT log file that is copied to a network location at the end of the deployment if you specify the SLShare property in the Customsettings.ini file.
  • LiteTouch.log. This file is created during LTI deployments. It resides in %WINDIR%TEMPDeploymentLogs unless you specify the /debug:true option.
  • Scriptname.log. This file is created by each MDT script. Scriptname represents the name of the script in question.
  • SMSTS.log. This file is created by the Task Sequencer and describes all Task Sequencer transactions. Depending on the deployment scenario, it may reside in %TEMP%, %WINDIR%System32ccmlogs, or C:_SMSTaskSequence, or C:SMSTSLog.
  • Wizard.log. The deployment wizards create and update this file.
  • WPEinit.log. This file is created during the Windows PE initialization process and is useful for troubleshooting errors encountered while starting Windows PE.
  • DeploymentWorkbench_id.log. This log file is created in the %temp% folder when you specify a /debug when starting the Deployment Workbench.

Get to know these logs, especially the BDD log which is the ‘master’ log and takes parts if not all information an places it all in one log.

There are a few scenarios is which your deployment can fail.  Failure can occur before applying the image, sometimes during, after applying the image or during a custom task such as running one of your powershell scripts.  You can get all manner of crazy error codes and return codes some of which you see a lot and become a real thorn in your side.  For me and my team, the 5624 and 5627 return codes are a real pain.   Logs will be stored in different locations depending on what stage the failure occurs so be sure to read up on where to look.  MDT Documentation and google are your friend on this.

Log files are stored in text files with a ‘.log’ extension.  There are a few viewers you can chose from:

Trust me when I say the logs need to be read in one of these and not using notepad, it’ll make your life a whole load easier. 

Both these programs will highlight the warnings in yellow and the errors in red.  Examine them closely and I believe you’ll discover your error.

Another thing that’ll make your life easier is the ‘SLShare’ and ‘SLShareDynamicLogging’ options placed in your customsettings.ini.

  • SLShare=\servershare – Will copy the logs to the network share (supposing permissions are set correctly) after (and only after) you click on ‘Finish’ when the deployment fails.
  • SLShareDynamicLogging=\servershare – Will dynamically create logs on the server share in case of catastrophic failure, power cuts etc etc.  I haven’t really had much use for this in the field yet but I have it in place anyway.  For grins.  As soon as I use it and it helps me I will come back and update this blog post.

One other tip I’ve found.  If your deployment fails applying the image using DISM (like the deployment in the Trace32 image above) you can check the DISM.log which can be found at C:WindowsLogsDISMdism.log.  This log doesn’t seem to transfer to the share but examining it can lead to an answer and has done for me on numerous occasions.

I hope that the advice here can help you diagnose any problems you may have in your production environment.  I would love to hear about anything you feel I have missed and what I could add to this post to make it more comprehensive.



0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *