您是否在生产IIS服务器上启用了Windows自动更新功能？

如果您在Windows Server 2003（IIS6）上运行24/7网站。您将启用Windows自动更新功能还是将其关闭？

启用后，您始终会自动获得最新的安全补丁和错误修复，这是最安全的选择。但是，计算机有时会自动重新启动以应用更新，从而导致半夜停机几分钟。另外，我见过极少数情况下机器无法正确重新启动，从而导致更长的停机时间。

如果关闭了自动更新，那么什么时候应用补丁？我猜您必须将负载平衡器与多个Web服务器一起使用，并将其旋转到生产站点之外，手动应用补丁，然后将它们放回去。当负载平衡器由托管公司管理时，这在逻辑上会带来不便。您还将在生产中的机器上并不总是具有最新的安全补丁，并且您必须定期花费时间来决定要应用哪些补丁以及何时应用。

简短的回答，不。

在最佳情况下，您至少应该让另外一个盒子/虚拟机/豚鼠来测试该补丁，以确保它不会破坏您的世界。

在最坏的情况下，我会让它下载补丁但不安装，因此我可以查看正在安装的内容。但是我只是那种控制狂。

恐怕我不同意共识。

任何说“需要人为干预”的人都没有足够多地思考。

自动化一切。

也许这意味着打开自动更新（我在低后果环境中执行此操作）。

也许这意味着更严格的要求（在此环境中，您将自动更新登台环境，使其自动验证正确的操作，然后在生产环境中触发自动更新）。应该使用报告或电子邮件通知，以便管理员可以了解过程的状态。

从Powershell脚本到软件更新服务（SUS），有多种方法可以实现这种自动化...特别是由于您是在stackoverflow而不是在serverfault上询问此问题的，因此我建议您开发例程以使大多数尽可能更新过程。

否则，您将面临无法应用更新或应用更新不正确的风险。另外，如果您像我一样，则宁愿在更新失败（并且被更新例程调页）时在蓝月亮中的凌晨3点醒来一次，而不希望每个月凌晨3点醒来安装更新在低后果的时间内。

当然是YMMV。设计一个最适合您的流程，但不要为自己做太多不必要的工作。

对于生产Windows服务器，我不建议将Windows Update设置为自动下载和安装更新。更好的方法是自动下载更新，但手动安装。

这种方法的好处是：

1. 您可以在安装之前查看建议的更新，并在必要时研究安装更新的含义。这似乎需要更多工作-是的！但至少您会控制住。Microsoft还提供了一个 免费的邮件列表，可让您及早通知下一批Windows Update中要发布的更新类型。
2. 您可以决定重新启动时间，该时间对网站访问者的影响最小。您的网站似乎是在一台服务器上运行的，因此在网站上显示一条横幅广告可能会很有用，它可以警告您的访客即将重启。我实施了类似的操作，该操作在重新启动前一小时出现，并显示一条消息：“网站将在x分钟内关闭以进行维护。维护时间不应超过10分钟
3. 由于您已经手动启动了服务器的重新引导，因此可以检查服务器在重新引导后是否已成功重新启动。如果没有，您可以与您的托管服务提供商联系并解决问题。

基本上，所有内容都与控制有关，并且具有自动下载和自动安装的功能，您获得的收益不多！！

我允许自动更新，但可以通过WSUS进行。这使您可以选择要自动应用的更新类别，以免受到无关的琐事的干扰，但可以尽快获得Day 0漏洞的补丁。

我认为这不是“允许更新”和“不允许它们”对与错的问题，顺便说一句，这仅仅是选择准备承担的风险和不便之处。允许更新自动继续存在风险，如果没有，则存在风险。平衡它们并做出明智的选择。

您可以考虑分阶段进行部署-在星期二发布的补丁会立即安装在测试环境中，并计划在星期四在生产服务器上安装，也就是说，您有两天的时间在测试环境中出现问题，这表明存在阻塞或延迟特定补丁。

如果高可用性是一个主要问题，那么无论如何您都应该适当地使用群集或负载平衡，这应该可以弥补由于修补而造成的停机时间。毕竟，为什么补丁导致的停机时间比任何时候在任何一个盒子上发生的硬件故障都要神奇呢？

我们从不在服务器上启用自动更新。它托管在一个数据中心，因此我们要做的是观察Google Analytics（分析）中的统计信息，以查看流量​​何时处于最低水平，然后安排技术人员在该时间现场安装更新。这样，如果需要重新启动，或者发生了严重错误，它不会像Windows在一天中下载更新那样影响很多人。

正如这里的其他所有人一样，已经回答： 不！ 仅在将更新安装在测试服务器上之后，我们才能使用Systems Centers Essentials将更新推送到生产Web服务器。

我们还会收到MS的每月更新电子邮件，以便我们确切知道每次更新的含义以及其用途。如果您确切知道更新的内容和时间，则可以很轻松地进行故障排除。

当然不。被苦苦地教导了太多次，不要让这种废话发生。不幸的是，这确实意味着人们对应用补丁和更新有些懒惰。但到目前为止，我还没有有一台服务器分成，因为我并不适用一些特定的补丁马上，但我已经，或通过重新启动并未能有不方便时引起的服务器重启了大量的头痛安装补丁后启动一些基本服务。

在旁注中，我们刚刚通过我们的服务提供商获得了由五台计算机组成的新集群，这是一个来自世界各地的大型且知名的ISP。当我们获得管理员帐户并可以登录并开始设置我们的软件时，我很高兴地看到，网络系统管理员已经为我完成了通常的首要任务。:)

应用更新==随机重启系统，不受您的控制。这给了SA蜂箱。另外，过去曾发生过破坏补丁的事件，因此，如果您过去没有尝试过，则很少希望应用它们。

我一直在研究的一种方法是迁移到虚拟化托管环境。这样一来，您就可以在非生产实例上试用更新，甚至可以将更新应用到脱机实例上，并在确定运行良好后将其交换到生产中。

绝对不。更新应在非工作时间应用于服务器，并应制定应急计划-意味着有足够的时间在更新失败时回滚更新。

作为系统管理员，您希望在控制下拥有尽可能多的变量。没有早上到达一台死掉的服务器就足够了！;-)

请注意，可以为更新设置特定的时间，并且大多数更新在星期二进行。这样，您可以安排时间来查看即将到来的更新和下载的更新，并知道何时会出现任何潜在问题。

一个好问题要问自己：我的副总裁/首席信息官/ etc对我说了什么吗？自动化它可以使您的生活更轻松，但是如果出现问题，您将被困在煤上，这会使事情变得更加艰难。

我可以自动完成PC上的操作，而您只需要几百个即可。服务器，尽管我安排了它并获得了授权，所以如果出现任何问题，我的@ $$被覆盖。请记住，我们正在使用其他人的数据和公司的资源，因此应始终使他们意识到风险。