汇报用于SQL Server服务的 Microsoft 更新检测逻辑

适用于：SQL Server 2019、SQL Server 2017、SQL Server 2016

从历史上看，服务基线 (RTM 或 Service Pack) 包括以下服务分支：

• 常规分发版本 (GDR) 分支，仅包含安全性和其他关键修补程序。
• 累积更新 (CU) 分支，其中包含安全性和其他关键修补程序以及基线的所有其他修补程序。

Microsoft 更新 (MU) 检测逻辑已构造，以便从 GDR 分支向服务基线或 GDR 分支上的实例提供更新。

以前，用户必须主动安装至少一个 CU 才能使实例与 CU 分支保持一致，以便通过 MU 提供服务。 但是，完成此操作后，在进行以下任一更改之前，无法返回该实例的 GDR 分支：

• 通过向上移动到下一个 Service Pack 来重置基线。
• 通过卸载所有 OU，实例已还原到 GDR 分支或服务基线。

建立此逻辑是为了在需要安全更新或其他关键更新时尽量减少对实例的更改。 出现所需的安全性或其他关键版本时，CU 分支上的实例必须获取为基线发布的所有更新。 这包括到所需安全更新的所有非安全更改。

但是，此逻辑为尝试使用 WSUS 管理大型实例集的例行服务的用户带来了问题。 这是因为，如果不首先手动更新每个客户端，使其可以参与，则无法使用 MU 逻辑。 为了解决此问题，并且仍然避免在未经用户明确同意的情况下将实例翻转到 CU 训练，对 MU 检测逻辑进行了以下更改，以便针对支持中基线的最新服务版本对常规 CU 服务和安全版本进行了以下更改：

• 累积汇报：MU 检测逻辑现在允许位于基线 (RTM 或 SP 的干净实例，没有服务更新) ，或者已沿 CU 分支更新以接收更新。 无需安装 CU 更新，实例就可以提供更新。 但是，如果实例具有 GDR 更新，则仍必须在 MU 外部手动更新该实例，以便通过 MU (WSUS) 自动化进行管理。
• 安全更新 (GDR) ：安全发布的逻辑现在拆分为以下通道：
  • 自动汇报通道 (Microsoft 更新) 保留旧的历史行为，该行为要求在实例上安装 CU 才能提供安全版本的 CU 分支版本。 这样做是防止实例接收所有更新，而不是仅接收关键更新和安全相关的更新，而无需用户明确选择使用更广泛的服务模式。
  • 一个 WSUS/Catalog 通道，它使用新的检测逻辑，该逻辑允许针对干净基线实例应用安全版本的 CU 分支版本。 这是将呈现给转到 Microsoft 更新目录网站的用户的版本的频道。

此新更新的检测逻辑适用于以下 CU 和 GDR 版本：

• SQL Server 2016 Service Pack 2：CU14 及更高版本的 CU
• SQL Server 2017 RTM：CU19 及更高版本的 CU
• SQL Server 2019 RTM：所有 OU
• GDR 和安全更新：全部从 2021 年开始

注意

对于 2019 SQL Server，RTM 基线可以是 RTM (15.0.2000.5) 版本基线，也可以是 RTM + RTM GDR (15.0.2070.41) 版本基线。 任一版本都适用于此版本。 对于 SQL Server 2014 SP3 (12.3.6024.0) 版本基线，将从 2021 年开始为 CU 分支上的 GDR 安全更新实现新模型。 有关旧的 Microsoft 更新检测模型的信息，请参阅 WSUS、MU 或 ConfMgr 中列出了不适用SQL Server库。