如何安装补丁 - AWS Systems Manager

如何安装补丁

Patch Manager（AWS Systems Manager 中的一项工具）使用适合操作系统类型的相应内置机制在托管式节点上安装更新。例如，在 Windows Server 上，使用 Windows Update API；在 Amazon Linux 2 上，则使用 yum 软件包管理器。

请从以下选项卡中进行选择，了解 Patch Manager 如何在操作系统上安装补丁。

Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023

在 Amazon Linux 1、Amazon Linux 2、Amazon Linux 2022 和 Amazon Linux 2023 托管式节点上，补丁安装工作流如下：

  1. 如果使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文档的 InstallOverrideList 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。

  2. 依照补丁基准中的规定应用 GlobalFilters，只保留符合资格的软件包做进一步处理。

  3. 依照补丁基准中的规定应用 ApprovalRules。每条批准规则可以将一个软件包定义为已批准。

    但是，批准规则也取决于在创建或上次更新补丁基准时是否选中包括非安全更新复选框。

    如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

    如果包含非安全更新，也会考虑来自其他存储库的补丁。

  4. 依照补丁基准中的规定应用 ApprovedPatches。已批准的补丁即使被 GlobalFilters 丢弃，也会批准更新；如果 ApprovalRules 中未指定任何批准规则，则给予批准。

  5. 依照补丁基准中的规定应用 RejectedPatches。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

  6. 如果批准了补丁的多个版本，则应用最新版本。

  7. YUM 更新 API（Amazon Linux 1、Amazon Linux 2）或 DNF 更新 API（Amazon Linux 2022、Amazon Linux 2023）用于已批准的补丁，如下所示：

    • 对于 AWS 提供的预定义默认补丁基准，仅应用 updateinfo.xml 中指定的补丁（仅安全性更新）。这是因为未选中包括非安全性更新复选框。预定义的基准等同于具有以下内容的自定义基准：

      • 未选中包括非安全性更新复选框

      • 严重性列表为 [Critical, Important]

      • 分类列表为 [Security, Bugfix]

      对于 Amazon Linux 1 和 Amazon Linux 2，此工作流的等效 yum 命令为：

      sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

      对于 Amazon Linux 2022 和 Amazon Linux 2023，此工作流程的等效 DNF 命令为：

      sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y

      如果选中了包括非安全性更新复选框，则 updateinfo.xml 中的补丁和未在 updateinfo.xml 中的补丁都会应用（安全更新和非安全性更新）。

      对于 Amazon Linux 1 和 Amazon Linux 2，如果选择的基准选中了包括非安全性更新，并且严重性列表为 [Critical, Important]，分类列表为 [Security, Bugfix]，则等效的 yum 命令为：

      sudo yum update --security --sec-severity=Critical,Important --bugfix -y

      对于 Amazon Linux 2022 和 Amazon Linux 2023，等效的 dnf 命令为：

      sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
      注意

      对于 Amazon Linux 2022 和 Amazon Linux 2023，Medium 补丁严重性级别相当于可能在某些外部存储库中定义的 Moderate 严重性。如果您在补丁基准中包含 Medium 严重性补丁，则外部补丁中的 Moderate 严重性补丁也会安装在实例上。

      使用 API 操作 DescribeInstancePatches 查询合规性数据时，筛选严重性级别 Medium 会报告严重性级别为 Medium 和 Moderate 的补丁。

      Amazon Linux 2022 和 Amazon Linux 2023 还支持补丁严重性级别 None，DNF 程序包管理器可识别该严重性级别。

  8. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 AWS-RunPatchBaseline 文档中的 RebootOption 参数设置为 NoReboot，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 参数名称: RebootOption。）

CentOS and CentOS Stream

在 CentOS 和 CentOS Stream 托管式节点上，补丁安装工作流如下：

  1. 如果使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文档的 InstallOverrideList 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。

    依照补丁基准中的规定应用 GlobalFilters，只保留符合资格的软件包做进一步处理。

  2. 依照补丁基准中的规定应用 ApprovalRules。每条批准规则可以将一个软件包定义为已批准。

    但是，批准规则也取决于在创建或上次更新补丁基准时是否选中包括非安全更新复选框。

    如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

    如果包含非安全更新，也会考虑来自其他存储库的补丁。

  3. 依照补丁基准中的规定应用 ApprovedPatches。已批准的补丁即使被 GlobalFilters 丢弃，也会批准更新；如果 ApprovalRules 中未指定任何批准规则，则给予批准。

  4. 依照补丁基准中的规定应用 RejectedPatches。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

  5. 如果批准了补丁的多个版本，则应用最新版本。

  6. YUM 更新 API（在 CentOS 6.x 和 7.x 版本上）或 DNF 更新（在 CentOS 8 和 CentOS Stream 上）应用于批准的补丁。

  7. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 AWS-RunPatchBaseline 文档中的 RebootOption 参数设置为 NoReboot，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 参数名称: RebootOption。）

Debian 服务器 and Raspberry Pi OS

在 Debian Server 和 Raspberry Pi OS（原 Raspbian）实例上，补丁安装工作流程如下：

  1. 如果使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文档的 InstallOverrideList 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。

  2. 如果某个更新可用于 python3-apt （一个 libapt 的 Python 库接口），则将升级到最新版本。（即使您没有选择包括非安全更新选项，该非安全软件包也会更新。）

    重要

    仅在 Debian Server 8 上：由于某些 Debian Server 8.* 托管式节点引用的软件包存储库 (jessie-backports) 已被淘汰，Patch Manager 会执行以下其他步骤来确保修补操作成功：

    1. 在托管式节点上，将从源位置列表 (jessie-backports) 中注释掉对 /etc/apt/sources.list.d/jessie-backports 存储库的引用。因此，不会尝试从该位置下载补丁。

    2. 将导入 Stretch 安全更新签名密钥。此密钥为 Debian Server 8.* 发行版上的更新和安装操作提供必要的权限。

    3. 在这一点运行 apt-get 操作，以确保在修补过程开始之前已安装 python3-apt 的最新版本。

    4. 安装过程完成后，将恢复对 jessie-backports 存储库的引用，并从 apt 源密钥环中删除签名密钥。这样做是为了使系统配置保持修补操作之前的状态。

    下次 Patch Manager 更新系统时，将重复执行同一过程。

  3. 依照补丁基准中的规定应用 GlobalFilters，只保留符合资格的软件包做进一步处理。

  4. 依照补丁基准中的规定应用 ApprovalRules。每条批准规则可以将一个软件包定义为已批准。

    注意

    由于无法可靠地确定 Debian Server 更新程序包的发布日期，因此该操作系统不支持自动审批选项。

    但是，批准规则也取决于在创建或上次更新补丁基准时是否选中包括非安全更新复选框。

    如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

    如果包含非安全更新，也会考虑来自其他存储库的补丁。

    注意

    对于 Debian Server 和 Raspberry Pi OS，补丁候选版本仅限于 debian-security 中包含的补丁。

  5. 依照补丁基准中的规定应用 ApprovedPatches。已批准的补丁即使被 GlobalFilters 丢弃，也会批准更新；如果 ApprovalRules 中未指定任何批准规则，则给予批准。

  6. 依照补丁基准中的规定应用 RejectedPatches。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

  7. 使用 APT 库升级软件包。

    注意

    Patch Manager 不支持使用 APT Pin-Priority 选项为软件包分配优先级。Patch Manager 汇总所有已启用存储库的可用更新，并选择匹配每个已安装软件包基准的最新更新。

  8. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 AWS-RunPatchBaseline 文档中的 RebootOption 参数设置为 NoReboot，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 参数名称: RebootOption。）

macOS

在 macOS 托管式节点上，补丁安装工作流如下：

  1. /Library/Receipts/InstallHistory.plist 属性列表是软件的记录，已使用 softwareupdate 和 installer 软件包管理器安装和更新了这些软件。使用 pkgutil 命令行工具（适用于 installer）和 softwareupdate 软件包管理器，运行 CLI 命令来解析此列表。

    对于 installer，对 CLI 命令的响应包括 package name、version、volume、location 和 install-time 详细信息，但只有 package name 和 version 被 Patch Manager 使用。

    适用于 softwareupdate，对 CLI 命令的响应包括软件包名称 (display name)、version 和 date，但 Patch Manager 只使用软件包名称和版本。

    对于 Brew 和 Brew 桶，自制软件不支持在根用户下运行的命令。因此, Patch Manager 以 Homebrew 目录的所有者或属于 Homebrew 目录的所有者组的有效用户身份查询并运行 Homebrew 命令。这些命令类似于 softwareupdate 和 installer 并通过 Python 子进程运行以收集软件包数据，并对输出进行解析以识别软件包名称和版本。

  2. 依照补丁基准中的规定应用 GlobalFilters，只保留符合资格的软件包做进一步处理。

  3. 依照补丁基准中的规定应用 ApprovalRules。每条批准规则可以将一个软件包定义为已批准。

  4. 依照补丁基准中的规定应用 ApprovedPatches。已批准的补丁即使被 GlobalFilters 丢弃，也会批准更新；如果 ApprovalRules 中未指定任何批准规则，则给予批准。

  5. 依照补丁基准中的规定应用 RejectedPatches。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

  6. 如果批准了补丁的多个版本，则应用最新版本。

  7. 在托管式节点上调用相应的软件包 CLI 以处理批准的补丁，如下所示：

    注意

    installer 缺乏检查和安装更新的功能。因此，对于 installer、Patch Manager 仅报告安装了哪些软件包。因此, installer 软件包从未作为 Missing 来报告。

    • 对于 AWS 提供的预定义默认补丁基准，以及未选中包括非安全性更新复选框的自定义补丁基准，则将仅应用安全性更新。

    • 对于已选中包括非安全性更新复选框的自定义补丁基准，安全性和非安全性更新都将应用。

  8. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 AWS-RunPatchBaseline 文档中的 RebootOption 参数设置为 NoReboot，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 参数名称: RebootOption。）

Oracle Linux

在 Oracle Linux 托管式节点上，补丁安装工作流如下：

  1. 如果使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文档的 InstallOverrideList 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。

  2. 依照补丁基准中的规定应用 GlobalFilters，只保留符合资格的软件包做进一步处理。

  3. 依照补丁基准中的规定应用 ApprovalRules。每条批准规则可以将一个软件包定义为已批准。

    但是，批准规则也取决于在创建或上次更新补丁基准时是否选中包括非安全更新复选框。

    如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

    如果包含非安全更新，也会考虑来自其他存储库的补丁。

  4. 依照补丁基准中的规定应用 ApprovedPatches。已批准的补丁即使被 GlobalFilters 丢弃，也会批准更新；如果 ApprovalRules 中未指定任何批准规则，则给予批准。

  5. 依照补丁基准中的规定应用 RejectedPatches。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

  6. 如果批准了补丁的多个版本，则应用最新版本。

  7. 在版本 7 托管式节点上，对已批准的补丁应用 YUM 更新 API，如下所示：

    • 对于 AWS 提供的预定义默认补丁基准，以及未选中包括非安全性更新复选框的自定义补丁基准，则将仅应用 updateinfo.xml 中指定的补丁（仅安全性更新）。

      此工作流程的等效 yum 命令为：

      sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y

    • 对于已选中包括非安全性更新复选框的自定义补丁基准，updateinfo.xml 中的补丁和未在 updateinfo.xml 中的补丁都将应用（安全性和非安全性更新）。

      此工作流程的等效 yum 命令为：

      sudo yum update --security --bugfix -y

      在版本 8 和 9 托管式节点上，对已批准的补丁应用 DNF 更新 API，如下所示：

      • 对于 AWS 提供的预定义默认补丁基准，以及未选中包括非安全性更新复选框的自定义补丁基准，则将仅应用 updateinfo.xml 中指定的补丁（仅安全性更新）。

        此工作流程的等效 yum 命令为：

        sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important

      • 对于已选中包括非安全性更新复选框的自定义补丁基准，updateinfo.xml 中的补丁和未在 updateinfo.xml 中的补丁都将应用（安全性和非安全性更新）。

        此工作流程的等效 yum 命令为：

        sudo dnf upgrade --security --bugfix

  8. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 AWS-RunPatchBaseline 文档中的 RebootOption 参数设置为 NoReboot，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 参数名称: RebootOption。）

AlmaLinux, RHEL, and Rocky Linux

在 AlmaLinux、Red Hat Enterprise Linux 和 Rocky Linux 托管式节点上，补丁安装工作流如下：

  1. 如果使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文档的 InstallOverrideList 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。

  2. 依照补丁基准中的规定应用 GlobalFilters，只保留符合资格的软件包做进一步处理。

  3. 依照补丁基准中的规定应用 ApprovalRules。每条批准规则可以将一个软件包定义为已批准。

    但是，批准规则也取决于在创建或上次更新补丁基准时是否选中包括非安全更新复选框。

    如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

    如果包含非安全更新，也会考虑来自其他存储库的补丁。

  4. 依照补丁基准中的规定应用 ApprovedPatches。已批准的补丁即使被 GlobalFilters 丢弃，也会批准更新；如果 ApprovalRules 中未指定任何批准规则，则给予批准。

  5. 依照补丁基准中的规定应用 RejectedPatches。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

  6. 如果批准了补丁的多个版本，则应用最新版本。

  7. YUM 更新 API（在 RHEL 7 上）或 DNF 更新 API（在 AlmaLinux 8 和 9、RHEL 8 和 9 以及 Rocky Linux 8 和 9 上）用于已批准的补丁，如下所示：

    • 对于 AWS 提供的预定义默认补丁基准，以及未选中包括非安全性更新复选框的自定义补丁基准，则将仅应用 updateinfo.xml 中指定的补丁（仅安全性更新）。

      对于 RHEL 7，此工作流程的等效 Yum 命令为：

      sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

      对于 AlmaLinux、RHEL 8 和 Rocky Linux，此工作流程的等效 DNF 命令为：

      sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y

    • 对于已选中包括非安全性更新复选框的自定义补丁基准，updateinfo.xml 中的补丁和未在 updateinfo.xml 中的补丁都将应用（安全性和非安全性更新）。

      对于 RHEL 7，此工作流程的等效 Yum 命令为：

      sudo yum update --security --bugfix -y

      对于 AlmaLinux 8 和 9、RHEL 8 和 9 以及 Rocky Linux 8 和 9，此工作流程的等效 DNF 命令为：

      sudo dnf update --security --bugfix -y

  8. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 AWS-RunPatchBaseline 文档中的 RebootOption 参数设置为 NoReboot，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 参数名称: RebootOption。）

SLES

在 SUSE Linux Enterprise Server (SLES) 托管式节点上，补丁安装工作流如下：

  1. 如果使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文档的 InstallOverrideList 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。

  2. 依照补丁基准中的规定应用 GlobalFilters，只保留符合资格的软件包做进一步处理。

  3. 依照补丁基准中的规定应用 ApprovalRules。每条批准规则可以将一个软件包定义为已批准。

    但是，批准规则也取决于在创建或上次更新补丁基准时是否选中包括非安全更新复选框。

    如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

    如果包含非安全更新，也会考虑来自其他存储库的补丁。

  4. 依照补丁基准中的规定应用 ApprovedPatches。已批准的补丁即使被 GlobalFilters 丢弃，也会批准更新；如果 ApprovalRules 中未指定任何批准规则，则给予批准。

  5. 依照补丁基准中的规定应用 RejectedPatches。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

  6. 如果批准了补丁的多个版本，则应用最新版本。

  7. 对已批准的补丁应用 Zypper 更新 API。

  8. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 AWS-RunPatchBaseline 文档中的 RebootOption 参数设置为 NoReboot，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 参数名称: RebootOption。）

Ubuntu Server

在 Ubuntu Server 托管式节点上，补丁安装工作流如下：

  1. 如果使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文档的 InstallOverrideList 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。

  2. 如果某个更新可用于 python3-apt （一个 libapt 的 Python 库接口），则将升级到最新版本。（即使您没有选择包括非安全更新选项，该非安全软件包也会更新。）

  3. 依照补丁基准中的规定应用 GlobalFilters，只保留符合资格的软件包做进一步处理。

  4. 依照补丁基准中的规定应用 ApprovalRules。每条批准规则可以将一个软件包定义为已批准。

    注意

    由于无法可靠地确定 Ubuntu Server 的更新程序包的发布日期，因此此操作系统不支持自动批准选项。

    但是，批准规则也取决于在创建或上次更新补丁基准时是否选中包括非安全更新复选框。

    如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

    如果包含非安全更新，也会考虑来自其他存储库的补丁。

    但是，批准规则也取决于在创建或上次更新补丁基准时是否选中包括非安全更新复选框。

    注意

    对于 Ubuntu Server 的每个版本，补丁候选版本仅限于作为该版本关联存储库一部分的补丁，如下所示：

    • Ubuntu Server 14.04 LTS：trusty-security

    • Ubuntu Server 16.04 LTS：xenial-security

    • Ubuntu Server 18.04 LTS：bionic-security

    • Ubuntu Server 20.04 LTS：focal-security

    • Ubuntu Server 20.10 STR：groovy-security

    • Ubuntu Server 22.04 LTS：jammy-security

    • Ubuntu Server 23.04：lunar-lobster

  5. 依照补丁基准中的规定应用 ApprovedPatches。已批准的补丁即使被 GlobalFilters 丢弃，也会批准更新；如果 ApprovalRules 中未指定任何批准规则，则给予批准。

  6. 依照补丁基准中的规定应用 RejectedPatches。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

  7. 使用 APT 库升级软件包。

    注意

    Patch Manager 不支持使用 APT Pin-Priority 选项为软件包分配优先级。Patch Manager 汇总所有已启用存储库的可用更新，并选择匹配每个已安装软件包基准的最新更新。

  8. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 AWS-RunPatchBaseline 文档中的 RebootOption 参数设置为 NoReboot，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 参数名称: RebootOption。）

Windows Server

在 Windows Server 托管式节点上执行修补操作时，节点从 Systems Manager 请求相应补丁基准快照。此快照包含已批准部署的补丁基准中可用的所有更新的列表。系统会将更新列表发送到 Windows 更新 API，Windows 更新 API 确定哪些更新适用于托管式节点并根据需要安装更新。Windows 仅允许安装最新可用版本的 KB。当 KB 或 KB 的任何先前版本与应用的补丁基准匹配时，Patch Manager 会安装 KB 的最新版本。如果安装了任何更新，则系统会根据完成所有必要修补所需的次数重启托管式节点。（例外：如果将 AWS-RunPatchBaseline 文档中的 RebootOption 参数设置为 NoReboot，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 参数名称: RebootOption。） 可在 Run Command 请求输出中找到修补操作摘要。其他日志可在托管式节点上的 %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs 文件夹中找到。

因为使用 Windows Update API 下载和安装 KB，所以操作遵循 Windows Update 的所有组策略设置。使用 Patch Manager 时不需要任何组策略设置，但会应用已定义的所有设置，以便（例如）将托管式节点定向到 Windows Server Update Services (WSUS) 服务器。

注意

默认情况下，Windows 从 Microsoft 的 Windows Update 站点下载所有 KB，这是因为 Patch Manager 使用 Windows Update API 驱动 KB 的下载和安装。因此，托管式节点必须能够访问 Microsoft Windows 更新站点，否则修补将失败。或者，您也可以将 WSUS 服务器配置为 KB 存储库，然后使用组策略将托管式节点配置为将该 WSUS 服务器设为目标。

Patch Manager可能会在为 Windows Server 创建自定义补丁基准时引用 KB ID，例如基准配置中包含已批准的补丁列表或已拒绝的补丁列表时。只有在 Microsoft Windows Update 或 WSUS 服务器中分配了 KB ID 的更新才由Patch Manager安装。修补操作中不会包含缺少 KB ID 的更新。

有关创建自定义补丁基准的信息，请参阅以下主题：