ConfigMgr 2012 – 如何在不强制安装的情况下自动将更新提供给计算机？

我知道这个问题有点老了，但是这里有一些不真实的东西。 SCCM 2012的function并没有错，问题在于它如何部署软件和更新的误解。 引用微软的说法是“按照devise”行事是不公平的，除非在未来设定一个最后期限，否则不能做任何事情。 这实际上是由devise，但基于您的devise。 你没有设置维护窗口，所以当然更新将在截止date之后立即生效。 这就是默认情况下。 在这种types的devise中，您必须将截止date设置在将来，以避免安装开始。 但是，这不是唯一的方法来做你想做的，也不是最简单的。

你知不知道你可以扭转SCCM的默认行为“除非另有说明，什么都行”？

要做到这一点，创build一个新的集合（命名为任何有意义的东西，如“手动部署”），并在其成员中包含“所有系统”集合。 然后获取它的属性，并使用过去的任何生效date设置维护窗口，如01/01/2013从上午12:00到上午12:05，并将重复计划设置为无。 您将收到关于没有设置重复的警告，但仍然单击确定。 从这一点开始，SCCM环境中的每个设备都会自动设置一个过期的维护窗口，并且无需再安装新的维护窗口，或者在进行部署时检查覆盖维护窗口框，就不能再安装任何设备。 这与之前的行为是相反的，因为直到明确告诉之前，它现在不会运行安装或更新。

这是非常强大的，但是需要注意的是，现在您可以完全手动控制安装的运行时间和重新启动时间，就像您想要的那样。 现在这些checkbox有意义。 例如，如果您有自动部署规则（如端点保护定义），则需要确保可以在维护时段之外进行安装，除非您每天都喜欢login到服务器以应用它们。 即使允许安装在维护时段外运行，也可以select禁止重新启动。 一个好处是，您可以轻松地部署任何内容，只需在“手动安装”中select分配和截止date时简单地使用“尽快”，并且如果您对维护时段设置很熟悉，则可以一次性部署修补程序，但会计划实际安装通过使用具有新维护时段的其他集合来重启。 请记住，所有集合中的维护时段都是累积的，因此请相应地devise您的环境

你有没有试图设定最后期限？

这就是我在SCCM 2008中处理广告到我的服务器的方式。我把广告投放到服务器之后的最后期限为1年。 好的和方便的，因为当修补窗口滚动时，所有的更新都在那里，等待安装，但不会没有人工干预启动。 同样，在我尝试按照预期工作的那些环境中，也不需要太多努力。

为什么不把部署“可用”而不是“需要”？ 这样的更新将显示在软件中心，但不会自动安装。

此外，维护窗口适用于客户端，而不适用于收集。

“另外一个问题是，如果一台机器是多个集合中的一员，并且其中一个集合没有定义维护窗口，则其他集合的维护窗口将被有效忽略。”

其实客户端的维护窗口将是任何维护窗口的总和。 因此，如果您通过一个集合中的成员身份申请了一小时的维护时段，而客户端也是没有定义维护时段的集合的成员，那么您的有效维护时间为一个小时。

假设SCCM 2012的行为类似于SCCM 2007，则缺less维护窗口意味着该集合中的计算机将在您觉得（在截止date之前或之后）安装更新，就像您发现的那样。

我个人所做的就是拥有基于AD安全组成员的集合。 例如，作为Tuesday Maintenance组成员的服务器成为Tuesday Maintenance集合的成员，并且在星期二晚上更新（惊喜）。

无法每周重新启动的服务器将保存在没有针对此更新部署的集合中，因此，除了“定义更新”外，他们绝不会下载或应用任何更新。

在我能够更新这些关键服务器的时候，我只是暂时将它们添加到具有适当维护时段的集合所针对的AD安全组中 – 或者只是预先创build一个新的集合。

不知道这种方法是否会成为你正在寻找的，但也许可能会给你一些想法。

你似乎select了错误的答案。 清楚地显示在graphics中的checkbox仅适用于定义了维护窗口的机器。 它清楚地说在checkbox上方的文本行中。 在SCCM中，如果没有分配维护窗口，则认为可以保留旧的服务器。 这是非常有意义的。 如果您希望这些checkbox应用于您的部署，则需要设置维护窗口。 如果您在过去设置了一个，并且指定了不重复，那么维护窗口已经过期，并且永远不会有另一个维护窗口。 在这种情况下，他们现在可以安装的唯一方法就是手动完成。

警告：只有在这些机器不在任何其他具有定期维护窗口的集合中时，才是如此。 在这种情况下，这个维护窗口会被忽略，因为它已经过期，而另一个将被观察，因为它们是累积的。

看起来很直截了当。 是的，行为是由devise..你只是devise错误的部署。 🙂

你的错误是假定由于没有定义维护窗口，所以安装这些补丁是完全没有问题的，反之亦然。 原因是人们需要能够安装补丁和软件，并且对系统进行更改，而不pipe是否定义了维护窗口。 （考虑像工作站这样高度容错的机器）。对于这些系统，定义维护时段的额外步骤是麻烦的，并且由于策略重叠等原因可能导致软件分发等问题。这种方式可以让您保持数量的维护时间降至最低，因此易于pipe理和预测您的部署将会发生什么行为。

正如你在图像中设置的那样。如果你在过去设置了一个维护窗口，而没有再次发生，那么你就会有你想要的行为。 🙂

所有这一切都被说出来..现在，如果你把控制自动更新的各种组策略设置混合在一起，可能会非常混乱。 微软可以简化软件更新界面，或者添加一些解释到现有的设置。 这也适用于SCCM 2007。

它变得更糟。 根据我的经验，持续部署补丁程序以尝试执行合规性，这可能是一个真正的问题。 这是为什么。 通常，策略通过其所在的集合分配给客户。集合定期更新，但不是全部同时更新。 现在想象一下在服务器上安装客户端的场景，知道客户端安装不需要重新启动。

服务器最终将驻留在具有维护窗口的集合中，并且正在持续部署关键的修补程序。 但恰恰恰巧，发生的时间线是这样的，具有部署的集合首先被更新，然后客户端碰巧到达其“策略检索评估周期”间隔，然后更新分配有维护窗口的集合被更新。 结果可能是服务器应用修补程序并在不适当的时间重新启动。

不幸的是，我们无法为“所有系统”集合分配一个维护窗口来创build一个默认的维护窗口。 到目前为止，我对这个问题的解决scheme的一部分是将集合作为一个包含集合镜像集合“Collection”，对集合进行超频设置，并为其分配一个维护窗口。 尽pipe我们可能希望继续持续部署桌面计算机的关键补丁程序，但是我们可能希望将它们过期到服务器，或者至less在我们的主要维护推进之后将其从“必需”更改为“可用”。

我也喜欢过去应用非定期维护窗口的想法。

看来这可能是SCCM中的一个已知的错误。 但是，我不能find任何MS文档，但是@至lessOP知道问题不在于他的设置。

我实际上是在第一次使用SCCM更新服务器的过程中。

假设SCCM 2012的行为类似于SCCM 2007，则缺less维护窗口意味着该集合中的计算机将在您觉得（在截止date之前或之后）安装更新，就像您发现的那样。

我也发现这是事实。 您必须分配维护窗口，否则只要他们感觉喜欢，更新就会生效。

至于服务器更新，我一直在做的是将更新部署到服务器，然后login并手动应用它们（在机器的快照，如果它是一个VM之后）。

然而，如果在下一个维护窗口中安装所有更新，必要时重新启动“button，以便我可以在白天启动此过程，然后早起并确保不必将快照回滚。

很多令人困惑的半真相答案在这里。 您所圈选的这些设置仅适用于机器应用了维护窗口的情况。 如果你希望你的系统不会重新启动，除非你启动它，那么你应该在将来或者过去的一个维护窗口。

没有维护窗口，SCCM将允许系统在安装更新后重新启动。 阻止该行为的方法是在pipe理 – >客户端设置下find的SCCM客户端设置。