如何安裝修補程式 - 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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

  2. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

  3. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

  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，此工作流程的同等 yum 命令為：

      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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

    套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

  2. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

  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 Server and Raspberry Pi OS

在 Debian Server 和 Raspberry Pi OS (之前為 Raspbian) 執行個體上，修補程式安裝工作流程如下：

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

  2. 若有可用於 python3-apt (libapt 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 Include nonsecurity updates (包含非安全性更新) 選項)。

    重要

    僅限於 Debian Server 8 上：由於某些 Debian Server 8.* 受管節點會參考已淘汰的套件庫 (jessie-backports)，因此 Patch Manager 會執行下列額外的步驟以確保修補操作成功︰

    1. 在您的受管節點上，對 jessie-backports 儲存庫的參考從來源位置清單 (/etc/apt/sources.list.d/jessie-backports) 會變更為註解。因此，不會嘗試從該位置下載修補程式，

    2. 並會匯入延展安全性更新簽署金鑰。此金鑰提供了 Debian Server 8.* 發行版本的更新和安裝操作所需的許可。

    3. 系統此時會執行 apt-get 操作以確保在修補程式開始之前已安裝最新版本的 python3-apt。

    4. 安裝程序完成後，會還原對 jessie-backports 儲存庫的參考，並從 apt 來源金鑰環中移除簽署金鑰。這麼做是為了讓系統組態保持在修補操作之前的狀態。

    Patch Manager 下次更新系統時，會重複執行相同的程序。

  3. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

  4. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    注意

    因為無法可靠地判斷 Debian Server 更新套件的發行日期，此作業系統不支援自動核准選項。

    然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

    注意

    對於 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 詳細資訊，但 Patch Manager 僅使用 package name 和 version。

    對於 softwareupdate，對 CLI 命令的回應會包含套件名稱 (display name)、version 和 date，但 Patch Manager 只會使用套件名稱和版本。

    對於 Brew 和 Brew Cask，Homebrew 不支援其在根使用者下執行的命令。因此，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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

  2. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

  3. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

  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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

  2. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

  3. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

  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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

  2. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

  3. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

  4. 套用修補程式基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准，仍將會核准用於更新。

  5. 套用修補程式基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。

  6. 如果核准修補程式的多個版本，將會套用最新版本。

  7. Zypper 更新 API 將套用至核准的修補程式。

  8. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

Ubuntu Server

在 Ubuntu Server 受管節點上，修補程式安裝工作流程如下：

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

  2. 若有可用於 python3-apt (libapt 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 Include nonsecurity updates (包含非安全性更新) 選項)。

  3. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

  4. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

    注意

    因為無法可靠地判斷 Ubuntu Server 更新套件的發行日期，此作業系統不支援自動核准選項。

    然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

    如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

    然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

    注意

    對於每個 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 Update 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 Update 網站，否則修補將會失敗。或者，您可以設定 WSUS 伺服器作為 KB 儲存庫，並設定您的受管節點以 WSUS 伺服器為目標使用群組政策。