none
Running MDT Task Sequences as LocalSystem pre-login RRS feed

  • Question

  • I currently use MDT with about 300 sites worldwide.  It "sucks the least for us" of Microsoft two main choices - OSD and MDT.  I've used OSD, but moved away due to unreliability of Distribution Points and a number of other factors with SCCM itself.

    For the context of this discussion, there is one large difference between the two: OSD runs as LocalSystem (desired) and MDT runs as a logged in user (undesired).

    By default, MDT logs in as Administrator.  That doesn't work for us - we have to change unattend.xml it to run as a Domain User to perform domain functions and access folders outside of the MDT share itself.

    We "hack" it to do it this way, along with a ton of other customizations, but we really don't want to log in as a Domain User either due to security concerns, along with password management.  We'd rather it behave like OSD - replace the Credential Provider and run everything in the LocalSystem context before any user logs in.

    How can I get the best of both worlds?  I've never seen anyone attempt this.  Before we used MDT, we used straight WDS with custom scripting - we'd leverage a temporary startup script to "deploy" applications before the user logged on - as LocalSystem.  So, I re-used that mentality to run LTIBootstrap in the same manner. 

    The problem I've run into - TsmBootstrap.exe, one of the first programs LiteTouch.wsf kicks off, doesn't like to run without a user logged in.  "Unable to create Shared Environment Object".  I know it works as LocalSystem because I can log in to the desktop, run psexec.exe -s -i, and run wscript.exe c:\LTIBootstrap.vbs and everything works fine - but that's exactly what we want to avoid.

    Anyone know what the "Shared Environment Object" is?  It's fairly vague, and part of me thinks I'm wasting my time with this, and that I should just file a DCR (Design Change Request) with Microsoft and move on, but I'm very sure they'll ignore it.

    And yes, I know all of this is "unsupported", but with all of the modifications we've already done, it is already unsupported.  The out-of-box experience in MDT is largely unsatisfactory for us, hence me needing to make many modifications.  Our end users image their own systems via PXE in remote branches with no interaction from our Service Desk, so the level of automation we need is almost absolute.  We even have "zero touch" with standalone MDT - again, custom engineered.

    I've looked at numerous procmon logs, debug logging - nothing really stands out on why this happens.  Regardless if I can make this work, I'm just punting this out there in case anyone has gotten this to work or can steer me in a direction.

    Thanks!

    Tuesday, December 29, 2015 5:30 PM

Answers

  • Looks like this (MDT-integrated OSD) would still depend on Distribution Points, which is exactly what I wanted to avoid.  Here's a reason why: when we update a package in a task sequence, OSD is broken until the package reaches all destinations, by design (Hash value is not correct).  With an operating system image, this can take 3-6 days due to wan circuits, as binary differential replication does not work on multi-part WIMs.  Only workaround was to store multiple copies of the WIM and rotate the images.  This was cumbersome.

    Since we had 300 sites, the easiest way to beat the 250 DP limit was to use PullDP's.  We uncovered several bugs with Pull DP's which had hotfixes written for and had just uncovered a 3rd which I ran out of patience with - it takes a long time to turn around a hotfix.

    So, back to the drawing board!

    Wednesday, January 6, 2016 8:24 PM

All replies

  • When I perform a new deployment the selected applications will be accessed from the account which I used initially to connect to the deployment share.
    Afaik task sequence steps run with the currently logged on account, but you are able to select an account at the bottom of each task sequence step.

    I don't think a DCR would have success either, they probably tell you that it's by design and it's supported in SCCM.

    It weren't that many modifications which were necessary for me in order to run ZTI deployments without any user interaction.

    Are you using the database? I highly recommend it when you are in a complex environment.

    Tuesday, December 29, 2015 8:28 PM
  • OSD does what you want with MDT integrated.

    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.

    Tuesday, December 29, 2015 8:34 PM
    Moderator
  • OSD does what you want with MDT integrated..

    Would it still require the use of distribution points?  When I last looked at MDT integration with OSD, it seemed unnecessarily complex, but above all I'm worried that most of my MDT customizations won't carry over and that I'll have to essentially start over.

    Guess I'll start up my lab again now that it's fairly slow during winter time.  Would give me a chance to see Build 1511 anyways.

    Are you using the database?

    I am not, but my CustomSettings.ini is dead simple since I've taken almost all of the logic out of there and have put it into my scripts with my own database which keeps track of the 300 sites.  I modify LiteTouch.wsf to kick off an "OS Chooser" application in the middle which provides more granularity to task sequence selection - e.g. if it's a server, only present the server OS choices, and hide desktop choices.  By default, server operating systems are hidden from desktops/laptops.  VM's get all choices.  Only IT gets Windows 10.... etc.



    • Edited by agressiv Wednesday, December 30, 2015 3:54 PM
    Wednesday, December 30, 2015 3:49 PM
  • No idea if your customizations would still work.  And OSD with MDT UDI or ZTI would be a learning curve. Not sure what issues you have had with OSD but, if you have things configured correctly it is very reliable.

    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.

    Thursday, December 31, 2015 4:48 AM
    Moderator
  • Looks like this (MDT-integrated OSD) would still depend on Distribution Points, which is exactly what I wanted to avoid.  Here's a reason why: when we update a package in a task sequence, OSD is broken until the package reaches all destinations, by design (Hash value is not correct).  With an operating system image, this can take 3-6 days due to wan circuits, as binary differential replication does not work on multi-part WIMs.  Only workaround was to store multiple copies of the WIM and rotate the images.  This was cumbersome.

    Since we had 300 sites, the easiest way to beat the 250 DP limit was to use PullDP's.  We uncovered several bugs with Pull DP's which had hotfixes written for and had just uncovered a 3rd which I ran out of patience with - it takes a long time to turn around a hotfix.

    So, back to the drawing board!

    Wednesday, January 6, 2016 8:24 PM