POLL: POWERSHELL VS. GUI - DO YOU WANT TO BE A DEVOP OR AN ADMIN?
Windows 8 deployment – Part 9: Troubleshooting
The final part of our Windows 8 Deployment series will walk through the troubleshooting process for MDT and cover two common errors.
By Joseph Moody - Tue, December 18, 2012 - 0 comments Joseph Moody is a desktop administrator for a public school and help manage about 5,500 computers. I specialize in Active Directory, Group Policy, and software deployment.
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:
- X:\MININT\SMSOSD\
- C:\MININT\SMSOSD
- %WINDIR\Temp\DeploymentLogs
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
SLShareDynamicLogging=\\SERVER\deploymentshare$\logs\%OSDComputerName%
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!