Hi 大家好,今天遇到一个问题,解决后立马就准备和大家分享一下,也正好可以优化一下之前我的一些博客内容。

我在之前的文章和大家介绍了如何集成 SCCM 2016 和 WSUS 来提供客户端操作系统补丁升级。

其中有两篇文章讲如何创建自动部署规则和软件更新组,链接如下:

https://blog.51cto.com/horse87/2073992

https://blog.51cto.com/horse87/2074350

结果今天出现的这个问题和这两个部署不严谨有一定的关系,下面我们就来讲一下这个问题哈!

在我们部署了 SCCM2016 的软件自动更新功能之后,在为客户端更新补丁的时候,自动部署规则报错,提示到达最大更新数目。

image

搜寻了一下洋鬼子的文章,其实这个问题的发生是因为我们的这个部署规则里面包含的更新种类太多,导致SCCM在进行一次软件更新下载审批的时候,发现这个审批数量大于了默认值1000,所以才会有这样的报错。

这个 maximum number 值是 1000,我们在创建自动部署规则(ADR) 的时候,会设置一些条件来进行筛选,一般情况下,满足条件的 updates 的数目是不会超过这个数目的。即使真的超过,我们也可以根据时间,

每个时间段(比如,每三个月)生成一个新的软件更新组(SUG),来减少 SUG 中包含的 updates 的数目。

所以,为了优化我们的SCCM的更新过程,我们其实可以只通过ADR来进行设置,不用像我之前提到的手动创建软件更新组SUG。

最关键的是,大家一定要稍微将企业内的软件更新稍微分的细致一点,这样就相当于把之前的大包拆分成了一个一个的小包,这样保证每个ADR的数量小于1000.

大家今后在创建自动部署规则的时候,请最好勾选下面“创建一个新的软件更新组” 。

image

在配置软件分类的时候,大家可以稍微多分几个类。比如不同的操作系统就分开创建。这样也方便今后管理。

image

在SCCM中 “全部软件更新”中直接筛选是创建 SUG 的一个方法,但是我们更推荐使用 ADR 创建。因为通过ADR的创建不需要每次去筛选。

如果我们不使用 ADR,则需要每次选择。ADR 也是从 SCCM 2012 R2 开始就有的一个新功能,省去了管理员每次通过手工筛选去创建 SUG的麻烦。

比如我就是按照操作系统和软件来进行划分的,这样也很方便。

image

这样在这些ADR成功运行后,就可以在软件更新组中看到他们的运行结果和每一个SUG的更新数量了,确实都是小于1000的,并且都是成功下载和部署的了!

image