Off-topic: To check the group policies, you should use rsop.msc. I think what you're showing is the output of gpedit.msc.
Firstly, let's dive into the 2 points mentioned in the question:
AlwaysAutoRebootAtScheduledTime:
When this registry value is set to 1, you are still notified of the
upcoming automatic restart on the sign-in screen. However, at the end
of the two-day period, the 15-minute counter begins even if the
computer is locked. The restart also occurs even if the computer is
locked.
NoAutoRebootWithLoggedOnUsers:
To prevent Automatic Updates from restarting a computer while users
are logged on, the administrator can create a
NoAutoRebootWithLoggedOnUsers registry value.
This setting is complicated to explain in few words and so I'd suggest you to better go through the shared link. A sample comparison taken from MSDN is shared below:
Now, Coming to the main questions:
- Does AlwaysAutoRebootAtScheduledTime only work if no administrator sessions are active?
In the settings of AU shared by you, the AlwaysAutoRebootAtScheduledTime is enabled (set to 1). When this registry value is set to 1, you (any user) are still notified of the upcoming automatic restart on the sign-in screen. However, at the end of the two-day period, the 15-minute counter begins even if the computer is locked. The restart also occurs even if the computer is locked.
- There were some disconnected administrator sessions at the time of the update. Could this be the cause?
Here, NoAutoRebootWithLoggedOnUsers is disabled OR not configured in your server. So, please go through the shared cases of this setting not enabled as per the image shared above in the answer.
But, when you'll check the always auto reboot setting to be enabled, and then the NoAutoRebootWithLoggedOnUsers setting disabled (or not configured), both settings imply that anyway, at the maximum, after 2 days notification expiry, the system could have been expected to restart automatically even when the administrator session was disconnected (locked or signed out).
I suspect this is what might have happened*. After the administrator session disconnected (and / or other users not logged on), the system restarted automatically. At max, the setting would have restarted the server at the 2nd day of disconnect of session.
* NOTE: For exact event schedule, you need to confirm it with the event viewer logs. I hope this answers your question and solves the query.
Popping this in an answer, as our workaround at least: we found the EC2 Server 2019 image had automatic update options set in the registry under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU.
You can probably just clear these out if you want to set them in the UI, but we overwrote them to force updates into automatic installation, with values:
- AUOptions = 4
- NoAutoUpdate = 0
- ScheduledInstallTime =
- ScheduledInstallDay = 0
- ScheduledInstallEveryWeek = 1
Best Answer
These are set in the Registry under
HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AUas mentioned by @GregAskew. The two keys you mention seem to be the default for the public Server 2019 Datacentre VM image (certainly is for the 10 or so I've deployed in Azure so far) leaving the Server OS free to download and install updates at whim out of the box.In the initial 'un-configured' state Group Policy will show all these settings as 'Not Configured', despite the fact there are at least two matching Registry Keys configuring parts of it as you've identified. As far as I can tell any settings that are not configured in the Registry or Group Policy are able to be manipulated by the user from the Control Panel interface. This is support by the Help text for 'Configure Automatic Updates' option in Group Policy editor
Conversely as you would expect, only those that are specified in either Registry or Group Policy are locked out from the Control Panel.
As soon as you start to edit the settings via Group Policy, the registry keys are modified and/or added to (relative to the specific Group Policy settings you manipulate in GPEdit).
Windows Update will still function despite apparent lack of configuration of some of these settings in either Registry or Group Policy. For example to address your question in comments about whether the AUOption is even functioning, again looking carefully at the Help for 'Configure Automatic Updates' option in Group Policy editor it states:
In my own Azure Tenancy I've set 'Configure Automatic Updates' 3 via Group Policy, set 'Install updates for other Microsoft Products' to TRUE and left everything unconfigured. I'm then using Azure Update Management to handle maintenance windows for install/restart and monitoring of update state, while I'm still testing it seems to be working well for me so far.