我在使用旧版 Windows Server 2003 Std SP2 机器时遇到了一些问题。
行为：Windows 更新正在自动应用，但由于一个或多个更新未及时完成，导致系统无法自行重启，从而无法完成。
我可以在 WindowsUpdate.log 中看到：
[Update] took too long (more than 16 hours) and was stopped
然后是一系列的：
WARNING: SUS Client is rebooting system.
AU invoking RebootSystem (OnRebootRetry)
每 10 秒一次，直至人工干预。
这是一个问题，因为系统部分关闭（监控系统关闭，TS 有时会死机）所以机器会蹒跚而行，直到有人手动将其踢翻。
有没有办法防止/缓解这种行为？我发现这种情况发生在 Windows 恶意软件工具的 5 月和 7 月更新中。这是一个已知问题吗？我是否最好手动更新机器以删除 WMST 的更新，以确保正确重启和继续运行？
此外，是否可以更改16 小时窗口改为更容易管理的时间？比如 1 小时？
答案1
我在使用旧版 Windows Server 2003 Std SP2 机器时遇到了一些问题。
行为：Windows 更新正在自动应用，但由于一个或多个更新未及时完成，导致系统无法自行重启，从而无法完成。
...
有没有办法可以防止或减轻这种行为？
是的，更新发布后不会立即自动应用。手动安装是一种选择，设置 WSUS 服务器并仅推送您测试并批准的更新是另一种选择。您甚至可以设置客户端下载但不安装，并在几周后手动安装更新，以便让 MS 有时间发现并纠正其补丁中的任何问题。
额外的努力是否值得取决于具体环境。
通常情况下（至少在管理层允许的情况下），我会设置一个 WSUS 服务器，在每月更新发布一周后，我会在网上查看是否有人抱怨最新一批更新会破坏他们的系统。如果没有，我会将更新部署到测试环境（通常是一组旧服务器和工作站，运行所有操作系统和应用程序，我可以将这些操作系统和应用程序安装到我们闲置的任何备用硬件上）。进行一些基本检查，以确保我们所有“重要”的软件在之后仍能正常工作，没有任何东西处于重启循环中，并且似乎没有任何影响。然后我会再等一周再检查一次，确保一切仍然正常。最后在线检查是否存在任何已知问题或投诉，在 WSUS 中为我的测试组批准更新，并将更新推送到该测试组（通常是 IT/MIS）。如果更新没有造成任何问题，一周后，我会推送给所有人。显然，如果有任何有问题的更新，它们会被搁置，直到问题得到解决。
每月冲洗并重复。
在我从事这项工作的近十年中，我每年都会看到大约六个更新被我忽略或等待，尽管自 NT 和 W2k 时代以来，微软在这方面已经做得更好了，而现在我忽略的大多数更新都是因为一个 POS 遗留系统或另一个系统从一开始就没有正确编码，而不是微软本身搞砸了更新。（虽然我在 5 月份确实发现了 Vista/7 x64 的拙劣更新，所以这种情况仍然时有发生。）
此外，是否可以将 16 小时窗口更改为更易于管理的时间？例如 1 小时？
这可能不是您想听到的答案，但这就是为什么您应该在修补或更新服务器时监视它们，而不是让它自动发生，或者按下按钮然后回家。至少，一旦更新完成并重新启动，您就可以等到它们恢复正常后再回家。
更改该窗口不会解决根本问题（我也没有听说过任何改变它的方法），而且下次 .NET 服务包、OS 服务包或其他“大”更新发布时，会对您造成很大伤害，因为这些更新需要 80 分钟才能在您的旧硬件上完成。（是的，这种情况确实会发生）。
答案2
和其他人一样，微软也会定期发布不良更新。不幸的是，只有当用户遇到问题时才会知道。因此，最好禁用自动更新并手动执行，这样如果出现问题，就会有人在机器旁。