[Updates] - VMs restarts immediately after applying OS patches - not respecting scheduled restart time

[chr0ustik]

Gateway Version: Windows Admin Center 2211 1.4.2212.08003 Extension Version msft.sme.windows-update 2.21.0

To Reproduce Steps to reproduce the behavior:

1. Go to Server Manager
2. Connect to any VM (tested on WinSrv 2016/2019/2022)
3. Apply System updates
4. Schedule restart at any time in the future

Expected behavior VM should reboot at specified date and time.

Undesirable behavior VM will restart immediately after the updates are applied.

Can anyone provide any advanced steps to troubleshoot this? Specific logs, events I should look at? I have WAC at three sites, clean default install and it's happening everywhere.

Martin

[Bro-Science]

I am having this same problem after upgrading to the latest version of WAC, this did not happen on older versions.

[cmkb3]

Correction: This snippet is from WAC 2306, original bug reported from 2211

---

In Install-WACWUWindowsUpdates:

  If ($NeedsReboot) {
    <#Restart almost immediately, given some seconds for this PSSession to complete.#>
    $waitTime = 5
    if ($restartTime -and $skipRestart) {
      <#Restart at given time#>
      $waitTime = [decimal]::round(((Get-Date $restartTime) - (Get-Date)).TotalSeconds);
      if ($waitTime -lt 5 ) {
        $waitTime = 5
      }
    }
    Shutdown -r -t $waitTime -c "SME installing Windows updates";
  }

So, there are a few possibilities.

Is $restartTime or $skipRestart null/false? If so, it will reboot 5 seconds after finishing installing updates. I would assume this would be caused by an error in the web portion determining the radio button values and setting the parameters on the Install-WACWUWindowsUpdates call.

Alternatively, this could be an issue with time zone standardization, assuming differences between the browser's device's time zone and the target device time zone, such that $restartTime is a valid time stamp, $skipRestart is true, but (Get-Date $restartTime) - (Get-Date) returns a negative value, which is less than 5, causing $waitTime to remain 5 seconds.

Or, more simply, an error in converting the selected timestamp from 'Schedule Later' into a meaningful/correct value for [DateTime].

[chr0ustik]

It's been fixed in a new Update module 2.3.0.