none
TS won't resume after first reboot - disable UAC the only workaround? RRS feed

  • Question

  • Hi everyone, this is kind of a weird problem so I'll back track a bit and explain the situation.

    A few weeks ago I ran into an issue when deploying a custom sequence in a standard task sequence.  Say, for instance, install Chrome, reboot, then install firefox. The problem that I was having was the TS wouldn't continue after reboot even though the .ink file was in programdata\microsoft\windows\start menu\programs\startup.  My solution was to disable UAC BEFORE any of the custom sequences start.  I detailed this problem here:

    https://social.technet.microsoft.com/Forums/en-US/3a941ca6-630a-49f8-9062-4bbd077d413a/task-sequence-fails-to-resume-after-first-reboot-post-installation-task-sequence?forum=mdt

    Can somebody tell me if this is a real limitation or if I just did something wrong?  I can continue to use this workaround but it creates a lot of headaches whenever I try to customize a task sequence.  Mainly, I can't exactly re-enable UAC during the task sequence because if it reboots (needs reboot to take effect), it won't give me a summary screen at the end because it can't continue and finish the task sequence.

    FWIW, this is only a problem for Windows 8/8.1 because UAC blocks access to programs\startup.

    Any help is appreciated.  Thanks!

    Wednesday, December 10, 2014 9:46 PM

Answers

  • Ok, this is an excerpt directly from the MDT 2013 documentation (listed under limitations):

    "For LTI deployments, ensure that User Account Control (UAC) is disabled for the built-in local Administrator account on the target computers until the task sequence finishes. Running task sequences on computers with UAC enabled for the local Administrator account causes task sequences to fail.

    Note   UAC should be disabled only for the built-in local Administrator account and enabled for all other accounts. By default, the built-in local Administrator account is excluded from UAC because of the User Account Control: Admin Approval Mode for the built-in Administrator account (disabled) policy setting."

    It's true that by default, admin approval mode is disabled for the built-in administrator account.  This is the registry key "FilterAdmininstratorToken."  

    Digging deeper, there's a few lines of code in LTICleanup.wsf that read as follows:

    		'//  Enable UAC for Administrator account
    		'//  This is added for Win8 only to enable Windows 8 Modern Applications.
    		'//----------------------------------------------------------------------------
    		If sOSVersion >= "6.2" then
    			oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken", 1, "REG_DWORD"
    		End if	

    Now, if I'm on windows 8, my OS version is 6.2.  If I'm on windows 8.1, my OS version is 6.3.  Therefore, if I am on either of those OS versions, it will always write that registry key in LTIcleanup.wsf.  If that reg key gets changed then any subsequent attempts at a post OS application deployment are going to fail.  I think that's where I am having an issue.  

    I'm going to comment out these lines in LTICleanup, but I'm not sure why they are in there in the first place. From what I can tell, all it does is enable metro apps for the built-in admin acct.  Since regular users would not be impacted, I don't see a reason to ever have this enabled.  In that regard, this might even be considered a bug.

    I would imagine I'm not the only one that's had this problem, and it is a frustrating one (especially for people testing in a lab).  Really hope this helps somebody down the road.

    • Marked as answer by resident1155 Monday, December 15, 2014 6:36 PM
    • Edited by resident1155 Monday, December 15, 2014 7:06 PM
    Monday, December 15, 2014 6:34 PM

All replies

  • What if you kill the Task Sequence and enable UAC in the same step?

    Or what if instead of enabling UAC in your TS you add an entry into your RunOnce to Disable UAC, and then add a FinishAction=REBOOT, so the system reboots immediately AFTER displaying the Summary screen?


    -BrianG (http://supportishere.com)

    Thursday, December 11, 2014 4:50 AM
  • Hey Brian, thanks for the reply.  I'm not sure how you could kill the task sequence and enable UAC in the same step.  Can you elaborate?

    I think you made a typo in your second suggestion *enable UAC.  In any event, rebooting immediately after the summary screen kind of defeats the purpose.  There's plenty of times where I'm not running a deployment and look at the Summary Screen a few hours later.  If it reboots, yes I can review the logs instead, but that's counter-intuitive.  Then there's the problem of how you would implement RunOnce.  I can't wrap my head around how that would work.

    What I've been doing is just creating a batch to disable UAC with a reboot, install my programs, then run a batch to enable UAC w/o a reboot.  It's frustrating because you have to manually reboot to complete the process, but this approach has the least headaches.

    Let me give you another example of why this is frustrating.  Let's say I deploy a clean OS to a reference VM and perform Windows Updates via the task sequence.  I ran into an issue yesterday where there was a pending reboot after the windows updates but for whatever reason MDT decided it was done with Windows Updates and finished the TS.  This is a problem because if I go to run a sysprep and capture TS on the VM and there's a pending reboot, it won't sysprep until rebooted.  If it reboots then I'll run into this UAC problem.  Fine, so I need to throw a reboot step in after the Windows Update sequence of the deployment.  Except if I put a reboot step in then I'll run into the UAC problem again. 

    I can get around this by implementing my workaround.  Maybe I'm selfish, but IMHO, MDT should really bypass UAC for custom sequences, but it looks like they have no way to implement that at this time.  Maybe this should be an enhancement request?

    Thursday, December 11, 2014 3:57 PM
  • UAC and Windows Defender should be disabled during image creation for best results.  While it would be nice for MDT to bypass UAC, it would also leave a possible gaping security hole. 

    Also - you can add that step to your unattend.xml of your capture sequence.  I wouldn't run it as part of your TS. 


    • Edited by MrBrooks Thursday, December 11, 2014 4:41 PM
    Thursday, December 11, 2014 4:28 PM
  • Thanks MrBrooks, that mostly answers my question.  I agree that bypassing UAC would leave a security hole, how they workaround a problem like that I don't know.  

    I would just like to point out that while I can modify the unattend.xml to bypass UAC during a deployment or sysprep/capture TS, I don't think there's a way to do that in a Post Installation TS since there's no unattend.xml.  In that case, you have to revert to batch files to turn UAC off/on in the TS, which is tedious and time consuming. I feel like MDT would be an almost complete product if it wasn't for this limitation.

    Sorry for the rant guys.  I really like MDT and what it has to offer.  Just wish the app deployment side of things was more intuitive.



    • Edited by resident1155 Thursday, December 11, 2014 5:19 PM
    Thursday, December 11, 2014 4:49 PM
  • WHen MDT installs applications during the normal OS Deployment Task Sequence, it installs these applications under the context of the local Administrator account.

    However, what I suspect is that you are running these installation actions under the context of a different account. Perhaps you are running under a domain user, and perhaps your domain administrator has set a GPO to disable startup applications?

    First thing to try is to run your MDT task sequence under the context of the local administrator to see if it works. If it does, then best to look at your user accounts.

    Additionally, MDT has a *second* method for programmatically restarting the Litetouch.wsf task, go ahead and try setting HideShell=Yes, that will use the registry instead of the startup group.

    https://social.technet.microsoft.com/Forums/en-US/66ced707-ac73-4565-86a1-82284be715af/mdt-2013-stalls-during-first-boot-into-os?forum=mdt


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Thursday, December 11, 2014 7:01 PM
    Moderator
  • Hi Keith, I am a Domain Administrator.  I always install using the Administrator account and always deploy in the WORKGROUP context (no domain join, so no GPO). 

    I confirmed (again) that the TS does not continue after reboot when run under the local administrator acct with UAC enabled.  I am testing this on a Windows 8.0 VM.

    The programmatic method seems to work fine (HideShell=YES), even with UAC on.  Thanks for that suggestion - that really brightens the landscape.  

    Following the breadcrumbs in your link, I wonder if drivers are an issue here.  I am using a VMware VM, while I'd imagine you guys are testing on HyperV?  I'm also using VMXNET drivers (mouse, video, NIC).  

    I still don't understand why this doesn't work with UAC enabled, but I guess hideshell will have to do.  If it's supposed to work w/UAC enabled then maybe there's just something different about my environment.

    Anyway, I appreciate the help Keith.  Thanks again.

    Thursday, December 11, 2014 10:08 PM
  • FWIW, I was testing this again today and at some point in my task sequence HideShell decided to stop working (after the 4th reboot) - that was with UAC disabled.  CPU, memory, and disk were getting a workout, but at no point did it continue the TS.  If this is a driver issue, I'd be curious to know which drivers are  found to be problematic in a situation like this.  Thanks.
    Friday, December 12, 2014 8:04 PM
  • Ok, this is an excerpt directly from the MDT 2013 documentation (listed under limitations):

    "For LTI deployments, ensure that User Account Control (UAC) is disabled for the built-in local Administrator account on the target computers until the task sequence finishes. Running task sequences on computers with UAC enabled for the local Administrator account causes task sequences to fail.

    Note   UAC should be disabled only for the built-in local Administrator account and enabled for all other accounts. By default, the built-in local Administrator account is excluded from UAC because of the User Account Control: Admin Approval Mode for the built-in Administrator account (disabled) policy setting."

    It's true that by default, admin approval mode is disabled for the built-in administrator account.  This is the registry key "FilterAdmininstratorToken."  

    Digging deeper, there's a few lines of code in LTICleanup.wsf that read as follows:

    		'//  Enable UAC for Administrator account
    		'//  This is added for Win8 only to enable Windows 8 Modern Applications.
    		'//----------------------------------------------------------------------------
    		If sOSVersion >= "6.2" then
    			oShell.RegWrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken", 1, "REG_DWORD"
    		End if	

    Now, if I'm on windows 8, my OS version is 6.2.  If I'm on windows 8.1, my OS version is 6.3.  Therefore, if I am on either of those OS versions, it will always write that registry key in LTIcleanup.wsf.  If that reg key gets changed then any subsequent attempts at a post OS application deployment are going to fail.  I think that's where I am having an issue.  

    I'm going to comment out these lines in LTICleanup, but I'm not sure why they are in there in the first place. From what I can tell, all it does is enable metro apps for the built-in admin acct.  Since regular users would not be impacted, I don't see a reason to ever have this enabled.  In that regard, this might even be considered a bug.

    I would imagine I'm not the only one that's had this problem, and it is a frustrating one (especially for people testing in a lab).  Really hope this helps somebody down the road.

    • Marked as answer by resident1155 Monday, December 15, 2014 6:36 PM
    • Edited by resident1155 Monday, December 15, 2014 7:06 PM
    Monday, December 15, 2014 6:34 PM