locked
MDT Missing SMSTS.LOG (in all locations) after ZTIError - Non-Zero return code by ZTIUserState, rc = 1 RRS feed

  • Question

  • Ok, so I’ve read tons of posts about the several locations where the SMSTS.log can be depending on which part of the process the machine fails in.  This TS is failing after everything I care about is complete – and during the Restore User State step – with Windows fully installed on the client.   So, the SMSTS.log should be in the %WINDIR%\TEMP\DeploymentLogs.  It’s not, but a ton of other logs are.

    I’m not sure why that step (Restore User State) runs at all for a new computer deployment (Client.xml Task Sequence Template) – but it does – and I’ll come back to that.  I don’t do any user state migrations, everything in MDT pushes out a new image from a PXE boot.  I like things clean.   I don’t care about my users’ profiles, they should be clean too and I take my own medicine with a new machine...  ;)

    So about 1/3<sup>rd</sup> of the time recently, I’ve been getting this same ZTIUserState, rc = 1 error.  This is after about 10 months of successful deployments and never seeing this error.  I haven’t changed anything in the TaskSequence once I got it optimized – I just update the apps and OSes as needed.

    I check the BDD.log in CMTrace and it tells me to look for “…\SMSTS.LOG” – which exists nowhere.  That’s Issue #1.  What’s happening to it?  Is it being purged by MDT?  Crapping out before it can write it in that final location?  C:\MININT still exists at that time…

    Issue #2 is, can I disable either/both of the following steps without blowing unforeseen things up – if I’m NEVER going to capture a user state in this process?

    • State Capture -> Capture User State
    • State Restore -> Restore User State

    I’ve read articles that say there should be some default conditions under the Options tab for Restore User State to keep it from running during a new deployment – and possibly adding a setting like “Deployment Type = NEWCOMPUTER”.  Mine is blank.  I’m assuming it always has been.  I’ve also read that adding that hasn’t resolved the issue for someone also experiencing this issue – but I haven’t tried before reaching out to you experts to know the ramifications – if any – of disabling this step since I’ll never be capturing/restoring user states (at least with this TS, should I change my posture in the years to come).

    From what I can see, even with the errors it generates because of the ZTIUserState error (excerpt below), everything previous gets installed and seems to work fine.  There’s no user state or groups to restore, which are some of the last steps, so I’ve deployed a few of these failed machines anyways (partly as a test) and I’ve heard no complaints.  Most of the time, if I have time, if I try the deployment again on the same machine – no error.  That said, I’d like to know why this error occasionally happens. 

    NOTE:  ztiRunCommandHidden.wsf is in fact in the Scripts folder for the deployment share and the BDD.log shows at the end the Z:\ drive is mapped to that deployment share – before disconnecting it after the failure

    Tuesday, March 1, 2016 10:43 PM

All replies

  • I should have noted this is MDT 2013 (6.2.5019.0) and that the Symantec Error happens every time because the installer expects a restart or input (I believe).  That's never been an issue and doesn't affect the above questions/issues.
    Tuesday, March 1, 2016 11:07 PM
  • Ultimately it will require fixing your Symantec install command. You need to figure out how to make it not reboot.

    Logs are very important. https://keithga.wordpress.com/2014/10/24/video-mdt-2013-log-files-basics-bdd-log-and-smsts-log/ Mention any customizations you have made.

    Wednesday, March 2, 2016 3:46 AM
  • Thank you for taking the time to read this long post.  However, I've already tested plenty and this has nothing to do with the Symantec Install which runs and completes successfully, along with 15 applications after it - at which time I inject a restart into the TS.   If I remove or disable the SEP install - this issue still persists just as often as with it enabled.


    Issue #1 and #2 above are not related to the Symantec 'error'.   Any idea where the log that I would use to troubleshoot has gone (Issue #1)?!  Or if I can disable 'Restore User State' or why it even runs on a new install to begin with?

    Wednesday, March 2, 2016 1:32 PM