A way to stop Windows 10 Updates from Rebooting

[scottgus1]

EDIT - for the solution that seems to work on my Windows 10 professional PC, see the sixth post "Solved! How to Stop Windows Updates Reboots on 10".

Windows Updates used to be turn-off-able, so the host wouldn't reboot while running guests. My method was to allow updates to announce themselves but to use a script to actually run the updates after the batch file shuts down the guests.

Windows 10's pushy update scheme has turned this plan on its ear. Windows 10 will update and reboot when it feels it wants to, and we can't say No, although it may be possible to defer the reboot part to certain hour ranges during the day (not the week, mind, we can't plan on having the updates happen at Saturday 3AM and have the guests shut down ahead of time).

Well, I googled around and found a poster "NJC2" on Windows 10 Forums who thinks he has a solution. I'm trying it now and I figured to put it here so others could test too.

Here's the link:
http://www.tenforums.com/windows-update ... dates.html

The idea, reproduced here, is to disable the Update system's reboot flag every four minutes when the computer is idle. (Apparently Windows waits 5-10 minutes after the computer goes idle to order a reboot, according to NJC2.) The disabling process gets fired with a Scheduled Task.

If it is not beyond allowance to copy NJC2's task import file, saved as an XML and imported into the Task Scheduler, here it is:

Code: Select all

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2016-10-13T14:08:07.2288437</Date>
    <Author>NJC2 on TenForums.com</Author>
    <URI>\Disable Windows Update Reboot Task</URI>
  </RegistrationInfo>
  <Triggers>
    <IdleTrigger>
      <Enabled>true</Enabled>
    </IdleTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-18</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <Duration>PT4M</Duration>
      <WaitTimeout>PT0S</WaitTimeout>
      <StopOnIdleEnd>false</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>true</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>C:\Windows\System32\schtasks.exe</Command>
      <Arguments>/change /tn \Microsoft\Windows\UpdateOrchestrator\Reboot /disable</Arguments>
    </Exec>
  </Actions>
</Task>

I have it installed but have not yet been through an update cycle to see how it goes. I will report back what happens.

Another user in the linked thread, "dalchina", also recommended a utility called DontSleep. I have downloaded it but have not tried it yet.

[scottgus1]

Well, the ol' PC rebooted by itself. NJC2's XML task was in place and active.

Updates were prepared on 10/28/2016 and "reboot required" flags popped up every morning for the next week. On 11/6/2016 I remoted in via UltraVNC to find a clean desktop, and Event Viewer showed a reboot on 11/5 at 6:33 PM, just outside my preset active hours of 6AM-6PM.

The task held off updates for a week, but somehow Windows got round it. Maybe a three-minute timer, or just let the task run even when not idle? I will try running the task at startup, every three minutes, indefinitely, and report back.

[scottgus1]

Got another auto reboot this weekend. After modifying the above task to a three-minute-run-all-the-time setting, it held off the update reboot for two weeks, but still was unable to stop the reboot permanently.

NJC2's task disables a Reboot task in the Microsoft\Windows\UpdateOrchestrator branch of the Task Scheduler. The version of the Windows-generated Reboot task that successfully rebooted the host PC was set to run the same time as the source file mentioned below was modified, so no time was given to allow NJC2's task to disable the Reboot task.

In the TenForums link above, another user Dalchina posted a link from a blog called Winaero, where in addition to disabling the above Reboot task, modifications are made in the "C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator" folder. Winaero suggests to rename the "Reboot" task source XML file in this folder, and to make a new folder also called Reboot, so new attempts to make the "Reboot" task source file should fail.

Will report back what happens...

[scottgus1]

WinAero's renamed-Reboot-Task-Folder method has held off my latest round of updates from 12/14/2016 until today when I had to do a manual reboot on my Windows 10 Pro PC. My never-turned-off Win10 Home media laptop is still waiting to do the same round of updates.

The updates did still run when I rebooted, though, even with a "shutdown.exe -s -t 2" command (shutdown's help says -t implies -f for forced shutdown).

So it is impossible so far to avoid the updates altogether. But the WinAero method does seem to be able to hold off the automatic reboot.

Until Microsoft gets wise and adds a little command to delete anything named "Reboot" in the UpdateOrchestrator folder, that is.....

[scottgus1]

There is a possible other solution which I will try next: https://answers.microsoft.com/en-us/win ... 3bd?page=1 Max Green's answer, uses GPedit (only on Pro or later)

1. run GPedit.msc
2. navigate to Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update
3. enable "No auto restart with logged on users for scheduled automatic updates installations"
4. reboot the PC.

There may also be interesting settings in "Configure Automatic Updates", but keep in mind configuring this key to anything but "Not Configured" disables the "No auto restart" key in #3 above.

Edit - the "No auto restart with logged on users" setting does not work. But the "Configure Automatic Updates" does, with a script-defeatable side effect, see next post.

[scottgus1]

Got something that works! Using the Group Policy Editor, but a different setting than Max Green's in the Microsoft.com link above.

So far the setting has blocked Jan 24's KB3211320 some three weeks with no signs of letting it through as of today Feb 16. And the PC can be rebooted without installing the pending update. There is a side-effect, though, see later.

The GPedit path is:
Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update

In the above GPedit path enable "Configure Automatic Updates" and set it to #3, "Auto download and notify for install". #2 "Notify for download and notify for install" may work, too, haven't tested it yet. My PC has not auto-restarted yet.

The side effect is that Windows will remind you that your PC needs updates. The reminder is a gray-out screencover like UAC, with a message box asking to install updates, and an "Get Updates" button and nothing else. No "No thanks", no "Cancel", and you can't do anything on the screen unless you respond to that box. However, the gray-out screencover is just a running program, and a VBscript can kill that program, if you can get the script to run. The VBscript I use is below, modified from a sample script from Adersoft's "VBSedit", set to run in a one-second loop and looking for and killing the offending screencover program "MusNotificationUX.exe", keeping a text log of when it does the kill so you can see if it is working. A Task Scheduler task can start the kill script:

Code: Select all

' Terminate a Process, from Adersoft "VBSedit"
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Set shell = WScript.CreateObject("WScript.Shell")
Set fso = CreateObject("Scripting.FileSystemObject")
scriptpath = fso.getparentfoldername(wscript.scriptfullname) & "\"

'this confirms the script is running in the log file:
set logfile = fso.opentextfile(scriptpath & "WinUpdateNotifyOverlay-Terminate.log",forappending,true)
logfile.writeline "Starting " & now
logfile.close
wscript.sleep 60000
set logfile = fso.opentextfile(scriptpath & "WinUpdateNotifyOverlay-Terminate.log",forappending,true)
logfile.writeline "Confirming running" & now
logfile.close

do
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colProcessList = objWMIService.ExecQuery _
    ("Select * from Win32_Process Where Name = 'MusNotificationUX.exe'")

For Each objProcess in colProcessList
	set logfile = fso.opentextfile(scriptpath & "WinUpdateNotifyOverlay-Terminate.log",forappending,true)
	logfile.writeline "Terminating MusNotificationUX.exe " & now
	logfile.close
    objProcess.Terminate()
Next
wscript.sleep 1000
loop

As of yet I have not figured out what Registry keys are modified by GPedit so Windows Home users can benefit.