/build/static/layout/Breadcrumb_cap_w.png

K2000 - Built in 'Restore UAC' Task Failing - W10 1803

Hi Everyone,

Does anyone know why this happens? My unattend.xml set UAC to disabled.

Note, this is the built in K2000 'Restore UAC' task that runs at the end of the task sequence. See error below.


GMxt5e.png


Only an issue on W10 1803. Currently imaging using 1709 as 1803 is still in testing, and 1709 is fine.

Using the 'Continue on Errors'  option but still requires input to reboot. It does not occur if there are no tasks applied so I guess it only activates this task if a task sequence is applied? I have tested recapturing, using a new unattend file and same issue.

Has anybody seen this?

Thanks.


0 Comments   [ + ] Show comments

Answers (2)

Posted by: Channeler 5 years ago
Red Belt
3
The enable_UAC.vbs is a built in task for the SDA appliance, it really isn't enabling the UAC but restoring it to the state before starting the post install tasks.

Do you have any anti-virus installed on your image or as post install task?

See:
https://support.quest.com/kace-systems-deployment-appliance/kb/121713/explanation-of-the-disable-enable-uac-tasks-in-3-6

Something could be preventing the KBE from reaching that Registry Value.

Now, you said your answer file is set to Disable UAC, right?

What is the UAC status on the Image itself?

If it's OFF, try to turn it ON, the answer file will shut it down anyways.




Comments:
  • Thanks for your help and suggestions. So I went back and enabled UAC on the golden image, then had it disabled by the unattend file. Added my series of tasks and seemed to be fixed. However, as soon as I added my PowerShell domain join task and tested again, the Restore UAC task failed. Removed it again to confirm and it ran through the Restore UAC task without error. I have Symantec running as a post task, however once I remove the domain join task everything runs smoothly thereafter.
    Given it occurs post joining the domain, does it sound like a permissions thing accessing the registry? - maherfed 5 years ago
    • I bet as soon as the Machine is Joined to a domain, the Deployment is getting hit with your domain's GPO policies, disrupting the Deployment's Engine.

      Remember that GPO's might be set to install certain software and such...

      read:
      https://support.quest.com/kace-systems-deployment-appliance/kb/131472/what-order-should-i-place-my-post-install-tasks-

      That error you are seeing, happens when the Deployment Engine is unable to read the Registry properly, that normally happens when security software is doing it's job, preventing the KACE engine from accessing\changing the Windows Registry - Channeler 5 years ago
      • All that makes sense. Definitely the Domain Join task or policy thereafter. Set that in isolation by removing Kace and Symantec to rule them out, and still got the error. The UAC is actually set how I want it after I click OK, just a bit of a nuisance that it needs user intervention to complete the image. I've tried some delayed forced reboots and taskkill commands for wscript.exe but yet to find the right combo.
        My task sequence is pretty much the same as previous images, 1703 and 1709 but something with 1803 in combination with the domain join task or policy isn't in agreement. I've gone back and built from scratch and recaptured 1803 to test, and same issue.
        Trying now with a base ISO scripted installation and just added the domain join task. I guess if this works, it's possible sysyprep is breaking something. - maherfed 5 years ago
Posted by: maherfed 5 years ago
Yellow Belt
0
Eventually got 'fixed' with this. Figured out a workaround rather. The error wasn't really causing any issues with the machine more just frustrating on my part that the image wouldn't run smoothly. 1703 &1709 the exact same domain join task and task sequence was fine, but 1803 would not work (This actually makes sense as there are domain policies that make it difficult to access the registry once on the domain, but my curiosity was why did 1703 & 1709 work just fine?) Tried using a different unattend file, rebuilt image from scratch, tried enabling UAC then disabling using the unattend file, force-closing the wscript error with task kill - all to no avail.
However, discussed with a colleague and got an idea.. Removed the Domain Join task from the task sequence. Instead, copied the PS1 script locally as a post task. As part of this post task, I exported/imported a registry key pointing the locally copied script with the command to launch the PS1 script using the RunOnce Reg Key. This meant the 'Restore UAC.vbs' no longer failed, and the machine joined the domain on the next boot. So far it has been working great.
If it you can't fix it, workaround it :) 

For anyone who wants it: 
Content of Reg Key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce]
"JoinDomain"="powershell -noprofile -command \"&{ start-process powershell -ArgumentList '-ExecutionPolicy Unrestricted -noprofile -file C:\\Users\\Administrator\\Documents\\JoinDomain.ps1' -verb RunAs}\""

New Post task was a zip with bat file, ps1 file and above reg key
COPY /Y "JoinDomain.ps1" C:\Users\Administrator\Documents
REGEDIT /S DomainRunOnce.reg

First boot after Kace finishes, the unit joins the domain and reboots. My first time figuring out and using the RunOnce key so this should be helpful in the future.

Comments:
  • You mentioned a bat file in the New Post task. What bat file is that? - RBoust 4 years ago
    • the bat file he used is these 2 lines

      COPY /Y "JoinDomain.ps1" C:\Users\Administrator\Documents
      REGEDIT /S DomainRunOnce.reg - SMal.tmcc 4 years ago
      • Thank you. - RBoust 4 years ago
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ