The final part of our Windows 8 Deployment series will walk through the troubleshooting process for MDT and cover two common errors.

You’ve finally done it! Your deployment share is completely configured and your database is populated! You have been rolling out Windows 8 clients and completely moved MDT into production so that the rest of your department can manage it. One day, you go to image a client and get a big nasty error! Or worse, your Task Sequence never even connects! Something has changed and it is up to you to figure it out.

A failed Deployment Summary

A failed Deployment Summary

Lucky for us, MDT logs everything. So let’s put on our Troubleshooting Hats and get down to business.

A connection to the Deployment Share could not be made ^

The number one tool for troubleshooting MDT in Windows PE is the command prompt. Getting to the command prompt it easy; it can be launched by pressing F8.

The command prompt in Windows PE

The command prompt in Windows PE

If you are receiving error messages stating that the deployment share could not be reached or that a connection to the Deployment Share could not be made, launch a command prompt and run IPCONFIG to ensure the network drive installed and that you have an IP address. If you do have an IP address, you will want to check your BootStrap.ini file. To open the file, type notepad (in the command prompt) and open X:\Deploy\Scripts\BootStrap.ini

Windows 8 deployment - Open bootstrap.ini

Notepad also gives you a Windows Explorer like access in case you do not have DaRT installed.

Make a note of your deployroot line and ping the server exactly how you have it specified in the BootStrap.ini. If you specified your deployroot as \\MDT.Test.local\DeploymentShare$, ping MDT.Test.local.

If you are still receiving an error connecting your deployment share, check the share and security permissions on your deployment share to ensure that the user specified in BootStrap.ini has read/execute.

Task Sequence constantly reboots ^

If your Task Sequence reboots before prompting for a name (or other information), something has either gone wrong in your boot image or something is incorrectly specified in your CustomSettings.ini. As a test, roll your CustomSettings.ini back to the default state. If you don’t have a copy of the default file, you can copy this one:

[Settings]
Priority=Default
Properties=MyCustomProperty
[Default]
OSInstall=Y
SkipCapture=NO
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerBackup=NO
SkipBitLocker=NO

Most of the time, the issue is caused by someone specifying TaskSequenceID= with a Task Sequence ID that doesn’t exist. Because the Task Sequence doesn’t exist, the deployment can’t proceed and immediately restarts.

If your problem was not resolved by restoring a default customsettings.ini file, completely regenerate the MDT boot images.

Update Deployment Share Wizard

The boot images are regenerated by updating the Deployment Share.

After the boot images are rebuilt, be sure to import them into WDS or update your physical boot media (if you are using CD/USB drives). This problem is commonly seen when MDT receives an update.

Log file locations ^

MDT can be a bit log excessive. There is literally a log file for every script. For example, the script that joins a machine to the domain is named ZTIDomainJoin. As you can guess, there is a corresponding log file named ZTIDomainJoin.log.

Windows 8 deployment - Log file locations

Notice how each completed script has an individual log file.

Most of the time, you will be looking in the BDD.log. This file is a near aggregate log detailing the steps in the Task Sequence for a particular client.

Finding the log files can be a bit tricky though as they move. Depending on the stage of the Task Sequence, the logs can be found at the following locations:

  1. X:\MININT\SMSOSD\
  2. C:\MININT\SMSOSD
  3. %WINDIR\Temp\DeploymentLogs

Let’s take a look inside a sample BDD.log.

BDD.log

BDD.log opened in Notepad

The log above is not the easiest to read is it. Because the MDT logs and SCCM logs are based off of each other, you can actually use the SCCM Log Reader (SMS Trace) to view the logs. Here is a screenshot of that exact same log within SMS Trace:

BDD.log opened in Trace32

BDD.log opened in Trace32

The log file above is much easier to read! As a bonus, errors and warnings automatically color code themselves. If you do not have SMS Trace installed, it can be downloaded here.

Remote logging in MDT ^

If you are like me, physically having to visit a machine is not fun. To help with your troubleshooting, MDT can automatically write BDD.log to your deployment share. To enable this feature, add this line to the [Default] section in your CustomSettings.ini

SLShareDynamicLogging=\\SERVER\deploymentshare$\logs\%OSDComputerName%

The logs folder centralizes MDT Loggings

The logs folder centralizes MDT Loggings

Wrapping It up

This brings our Deploying Windows 8 series to a close! In this post, we walked through two common MDT errors and worked with logging in MDT. In this series, we completely setup a MDT Deployment Share, imported our OS and applications, and completely automated our imaging process. When setting this up in your environment, let us know if you run into any trouble and how your Windows 8 deployment goes!

7 Comments
  1. MDT2013 setup on local PC. Reference boot from .iso but persistent could not connect to deployment share, spent hours on forums, could see share from net use etc, edited boot.ini and all options in between. Nothing. On .iso startup got the static ip address bar but nothing else, no input panel. Ignored as glitch. The reference machine already had W8 installed but booted from .iso okay. As a last resort I did a diskpart drive clean and hey presto I got the static ip address panel, configged to my local PC (w8) with crossover cable and got the deployment wizard to run as it could now see my deployment share.

  2. Author

    Hi Richard! Great tip! I haven't seen too many problems that needed diskpart lately but this is a good one to watch out for.

  3. Author

    For anyone else having this issue, here are is the exact steps that you will need to do:

    https://4sysops.com/forums/topic/no-mdt-menu-run-diskpart-in-mdt-2013/

  4. Eric 6 years ago

    Great article but I have a question. I've previously used WDS and captured my images which as worked great and it allows me to get all the Windows Updates in advance. I don't see anything in your series that addresses deploying machines that are current with Windows Updates. Can you address how you deal with this?

  5. Author

    Thank you Eric!

    See this guide that I wrote on slipstreaming updates: https://4sysops.com/archives/use-dism-to-slipstream-updates/

  6. JS2010 6 years ago

    I'm trying out MDT for the first time, and I was getting this error: "Litetouch deployment failed, Return Code = -2147467259 0x80004005". I couldn't find a reference to it in any logs. It turns out the bios update task didn't apply to the model of computer I was using. Once I disabled it everything was fine. One would think this would be a simple thing for MDT to clue me in on.

  7. John Daniels 2 years ago

    Great article!

    How would you setup a prompt that checks to see if there is network connection and if there is not then prompt the user to plug in the network cable?

     

    Could this be done in the bootstrap.ini? Or would this be done in the UDI Wizard?

    The UDI Wizard does have a spot to verify user name and password but that does not work, you can put in the wrong user name and password and the UDI Wizard will let you continue and then will fail later because it could not join the domain because of bad user name/password.

     

    I have looked and looked but have not found anything.

Leave a reply

Please enclose code in pre tags

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

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account