为了将其放入更多生产环境中，我正在测试 Windows 2016 更新行为。我已sconfig在“Windows 更新设置”中选择“仅下载”，并将“活动时间”配置为 07:00 至 19:00。
据我了解，此设置应按如下方式工作：
- 更新会自动下载；
- 更新内容不是自动安装；相反，系统管理员必须手动确认更新安装；
- 如果必须重新启动服务器，则应自动配置活动时间以外的计划重新启动；
- 在非工作时间（即 19:00 - 07:00 之后）服务器应该重新启动。
主要问题：上述理解正确吗？
我之所以询问，是因为在 Windows 2016 域控制器上测试并手动安装更新时，即使通知显示“您的设备计划在活动时间之外重新启动（活动时间为 07:00 至 19:00）”，但重新启动永远不会发生。
我注意到在任务管理器\库\Windows\Windows更新中，创建了一个重新启动任务，musnotification.exe RebootDialog于 19:20 运行，并且每 30/60 分钟运行一次。
第二个问题：当有远程桌面用户登录时，Windows 2016 默认如何表现？它会通知吗？它会重新启动吗？如果会话处于断开连接状态怎么办？
笔记：我知道这项政策No auto-restart with logged on users for scheduled automatic updates installations，但是：
- 它未处于活动状态/未配置；
- 由于我没有自动安装更新，因此它应该没有任何影响：
仅当配置自动更新策略配置为执行更新的计划安装时，此策略才适用。
当然，我完全理解应该只在适当的时间修补和重新启动服务器。但是，我真的很想了解当前（Win2016）更新行为背后的逻辑。我强烈地感觉到我错过了一些东西，因为这应该是一项基本的维护任务。
我读了这些信息，但我真的很想听听一些第一手的 Windows 系统管理员经验。
答案1
好吧，经过一年多的时间和一些 Windows 2016 的安装，我可以回答我自己的问题了。下面的答案在某些方面可能不正确，因为微软不太热衷于有关活动时间的细节；不过，这是我对其工作原理的最佳理解。与众所周知的 Win7/Win2008R2 更新方法的比较是根据需要进行的。
简短回答：使用 启用自动更新后sconfig，启用 GPO“始终在计划时间自动重启”以忽略“活动时间”并恢复到经典（阅读：Win7/Win2008R2）更新和重启行为。将其他相关 GPO（如“ScheduledInstallTime”）保留为默认设置。
很长的故事：Win7 和 Win2008R2 有一个简单的升级计划：默认情况下，更新在 03:00 安装，如果需要，机器会重新启动。如果机器在预定的安装时间关闭，则会尽快安装更新，但重新启动会推迟并根据用户的方便而取消。
这种延迟重启的方法被认为不适合 Windows 10 的 Windows 即服务模型，不幸的是，这也影响了 Windows 2016。为了避免单一且容易错过的重启时间表 (03:00)，Win10 和 Win2016 有“活动时间”的概念 - 服务器活跃使用且不应重启的时间。不在此范围内的时间（我们称之为“非活动时间”）被视为“空闲”。这意味着在“活动时间”之外可以重启服务器。
但是，“活动时间”最多可以配置为 12 小时（注意：最新版本的 Win10 改变了这一点），并且为了防止意外重启，微软添加了一些通用的启发式方法，以避免在使用时重启服务器外部“活跃时间”。例如，它似乎启发式方法检测用户是否已登录、用户是否有未保存的工作、是否正在访问共享等。这意味着正在使用的服务器（即：域控制器、已登录终端服务用户的服务器等）将不会重新启动。
但还有更多：因为即使是活跃的服务器也迟早必须重新启动，额外的计时器可确保机器在 7 天后重新启动（在“活动时间之外”）即使服务器很忙（注意：7 天期限可通过 GPO 配置）。这可能是您在 Google 上发现大量“我的 Win2016 意外重启”帖子的原因。
加上 Windows 2016 更新过程极其缓慢，以及上述与“活动时间”的混淆，我的拙见是，微软真的搞乱了 Windows 更新过程。Windows 2019 在这方面似乎更好，但考虑到在任何服务器级 Linux 发行版上更新是多么容易（和快速），我真的很怀疑如何微软能做出这种乱七八糟的事情吗？
为了结束这种疯狂的行为，可以使用 GPO“始终在计划的时间自动重启”：它将基本上禁用新的“活动时间”行为，返回到更明显（且更易于管理）的“在需要更新后重新启动服务器”行为。