- SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
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
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
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
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.
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.
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:
Let’s take a look inside a sample 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
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
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!
Want to write for 4sysops? We are looking for new authors.
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.
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.
For anyone else having this issue, here are is the exact steps that you will need to do:
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?
Thank you Eric!
See this guide that I wrote on slipstreaming updates: https://4sysops.com/archives/use-dism-to-slipstream-updates/
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.
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.