Living Table of Contents
- MDT Tutorial: Prologue & Requirements
- MDT Tutorial Part 1: Installation
- MDT Tutorial Part 2: Initial Configuration
- MDT Tutorial Part 3: Imaging
- MDT Tutorial Part 4: CustomSettings.ini
- MDT Tutorial Part 5: Bootstrap.ini
- MDT Tutorial Part 6: Customizing Boot Media
- MDT Tutorial Part 7: Customizing Base MDT Template & ADK WinPE Template WIM
- MDT Tutorial Part 8: Unattend.xml
- MDT Tutorial Part 9: Logging
- MDT Tutorial Part 10: CustomSettings.ini Validation Testing & Troubleshooting Part 1
- MDT Tutorial Part 11: Troubleshooting Part 2: Windows could not parse or process unattend answer file [C:\windows\Panther\unattend.xml] for pass [specialize]. The answer file is invalid.
- MDT Tutorial Part 11: Troubleshooting Part 3: Windows could not parse or process unattend answer file [C:\windows\Panther\unattend.xml] for pass [specialize]. The answer file is invalid.
- MDT Tutorial Part 11: Troubleshooting Part 4: Task Sequence Variable is Being Overwritten
- MDT Tutorial Part 11: Troubleshooting Part 5: Invalid DeploymentType value “” specified. The deployment will not proceed.
- MDT Tutorial Part 11: Troubleshooting Part 6: Unable to mount the WIM, so the update process cannot continue
- MDT Tutorial Part 11: Troubleshooting Part 7: Non-Fatal OSD Errors & Warnings
What These Guides Are:
A guide to help give you some insight into the troubleshooting process in general.
What These Guides Are Not:
A guide to fix all issues you’re going to encounter.
We’re going to role-play a bunch of scenarios and try to work through them. Remember in math where you had to show your work? Well, what follows is like that which is why this post is [more than] a [little] lengthy.
Task Sequence Variable is Being Overwritten – The Case of the Incorrectly Named Log Folder
After [finally] fixing your computer naming issue, you decide to take a look at the live BDD.log just to keep an eye on things. You hop into the TSLogs directory & find 2 directories that have the same time stamp:
According to your CS.INI the “real” log directory should be named after the machine so how did that other one get created? You open the BDD.log in BLD-HPV-22404895 and it’s practically empty, but you do see that the property is being set to the other directory.
There are some clues in the BDD that lead you to above that point to a smoking gun.
You open the BDD.log in the other directory & scroll to the top & see a familiar set of lines: The same ones you see when testing the CustomSettings.ini manually:
While the machine is imaging you press F8 to launch a console, fire up CMTrace, open the smsts.log (in %temp%\smstslog), scroll to the top & search downwards for ‘dyn’:
Ok, you’re piecing it together:
- Initially it’s good, points to the proper location
- Then at some point it changes
- In the first, short, BDD.log you see ‘Task Sequence’ mentioned
- In the second, long, BDD.log you see lines that look like it’s processing the CustomSettings.ini, something that also happens during the Task Sequence,
- The smsts.log shows a step that sets a variable
- SLShareDynamicLogging isn’t a property (or variable) that is ‘last write wins’, so it can’t be a case of a rogue CustomSettings.ini
So maybe it’s the Task Sequence?
Bingo was his name.
Hopefully these examples will help give you an idea of the overall troubleshooting process. Most of the time the problems you’ll encounter will be caused by a typso, order of operations or a ‘known issue’ that requires a specific process to be followed.
As you make changes to your environment, here’s what I recommend:
- Be diligent about keeping a change log so you can easily backtrack
- Backup your CS.INI or Bootstrap.ini before you make any changes
- Backup your ts.xml or unattend.xml (in DeploymentShare\Control\TaskSequenceID) before you make any changes
- Introduce small changes at time with set checkpoints in between and set milestones markers where you backup core files (e.g cs.ini bootstrap.ini ts.xml unattend.xml etc) to help minimize
if when you do run into some turbulence, upload relevant logs (at least smsts.log but be prepared to submit others depending on the issue) to a file sharing service like OneDrive, post on TechNet then give a shout to your resources on Twitter.
Good Providence to you!