I once knew a guy named Ted who didn’t like it when the “Check Engine” light came on in his car. He fixed the problem by covering up the Check Engine light with some black electrical tape. “There, now I won’t be bothered by the light anymore.” “But that’s not how to fix that.” I said… <sigh>
One of the really cool things about MDT LiteTouch is the fact that +90% of the product is included with source, VBScript and PowerShell. Even the Console and the PowerShell Providers written in C# can be decompiled and checked if there is a serious error. That means that if there are any problems, most of them can be fixed with some code changes on site.
ZTI (most of SCCM) and UDI are also closed boxes, written in C/C++, if you have a problem with them, then you need to file a bug with Microsoft Product Support <ouch>.
About the only thing that is a black box in MDT LiteTouch is the Stand Alone Task Sequencing Engine. It’s written in C/C++, but as long as I have worked on MDT, it’s been rock solid, only failing in a few obscure scenarios.
I had some weird errors in my task sequences for a couple of Windows 10 deployments, the “Deployment Summary” screen showed success, but the install failed somehow, what happened?
I tried creating a task sequence with an extra step to reproduce the problem:
The step is simple, it runs cmd.exe, and promptly fails. If we define “Continue on Error” as “False”, any failure returned in this step means that the *entire* Task Sequence should fail.
The result is that you get the Red (Or salmon) screen at the end of deployment. That means that if I were to run this Task Sequence, I should see an error in MDT Litetouch.
However, what I see in my deployment is “Success”, not “Failure”
What’s frustrating, is that the smsts.log is no help, it doesn’t show that the cmd.exe /c exit 42 command ran, it also doesn’t show what the error returned is in smsts.log.
... Reading logging settings from TS environment to set TS logging Process completed with exit code 0 Exiting with return code 0x00000000 Used smsts.ini to set logging settings. ...
I can reproduce this problem quite easily in my Hydration/Buildout System, and I even provided a repro VHDX file to the MDT Product group team, but so far this bug has been marked as “Low Priority” and postponed till the next release.
Generally, I can work around most of the bugs in MDT, I just fix the script and move on, but if the error in a black box, with no work around there is not much I can do. <sigh>
That combined with MDT UberBug03 creates a dangerous scenario. Now we have task sequences that are failing, randomly, but returning success, and no logging to tell when and where it happened. This is a clear bug, and a regression from MDT 2013.
These two bugs alone (not to mention the other UberBugs I will be filing in the next few days), lead me to believe that MDT has some serious problems that could lead to problems in production.
Please let me know if you see this in your deployments. And upvote my Connect bug.