• 2026 年 4 月 30 日之後將不再提供 AWS Systems Manager CloudWatch Dashboard。客戶可以繼續使用 Amazon CloudWatch 主控台來檢視、建立和管理其 Amazon CloudWatch 儀表板，就像現在一樣。如需詳細資訊，請參閱 [Amazon CloudWatch Dashboard 文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 用於修補的 SSM 命令文件：`AWS-RunPatchBaselineWithHooks`
AWS Systems Manager 支援 `AWS-RunPatchBaselineWithHooks`、適用於 的 Systems Manager 文件 (SSM 文件）Patch Manager、 中的工具 AWS Systems Manager。此 SSM 文件在受管節點上執行與安全相關和其他更新類型的修補操作。
`AWS-RunPatchBaselineWithHooks` 在以下方面不同於 `AWS-RunPatchBaseline`：
+ **包裝文件**–`AWS-RunPatchBaselineWithHooks` 是 `AWS-RunPatchBaseline` 的包裝，並依賴 `AWS-RunPatchBaseline` 進行其操作。
+ **`Install` 操作** – `AWS-RunPatchBaselineWithHooks` 支援在受管節點修補期間在指定點執行的生命週期掛鉤。由於修補程式安裝有時需要受管節點重新啟動，因此修補操作會分為兩個事件，總共有三個支援自訂功能的掛鉤。第一個掛鉤是在 `Install with NoReboot` 操作之前。第二個掛鉤是在 `Install with NoReboot` 操作之後。受管節點重新啟動後，第三個掛鉤可用。
+ **不支援自訂修補程式清單** – `AWS-RunPatchBaselineWithHooks` 不支援 `InstallOverrideList` 參數。
+ **SSM Agent 支援** – `AWS-RunPatchBaselineWithHooks` 需要 SSM Agent 3.0.502 或更新版本安裝在要修補的受管節點上。
執行文件時，如果未指定修補程式群組，則會使用當前指定為作業系統類型之「預設」的修補基準。否則，它會使用與修補程式群組相關聯的修補基準。如需有關修補程式群組的資訊，請參閱 [修補程式群組](patch-manager-patch-groups.md)。
您可以使用 `AWS-RunPatchBaselineWithHooks` 文件以套用適用於作業系統和應用程式的修補程式。(在 Windows Server 上，應用程式支援僅限於由 Microsoft 發行的應用程式更新。)
本文件支援 Linux 以及 Windows Server 受管節點。此文件會為各個平台執行適當的動作。
**注意**
macOS 不支援 `AWS-RunPatchBaselineWithHooks`。
------
#### [ Linux ]
在 Linux 受管節點上，`AWS-RunPatchBaselineWithHooks` 文件會叫用 Python 模組，進而下載套用至受管節點的修補基準快照。此修補基準快照使用已定義的規則，以及已核准與已封鎖的修補程式清單，為各個節點類型推動適當的套件管理員：
+ Amazon Linux 2、Oracle Linux 和 RHEL 7 受管節點使用 YUM。針對 YUM 操作，Patch Manager 需要 `Python 2.6` 或更新版本的支援版本 (2.6 - 3.12)。Amazon Linux 2023 使用 DNF。針對 DNF 操作，Patch Manager 需要 `Python 2` 或 `Python 3` 的支援版本 (2.6 - 3.12)。
+ RHEL 8 受管節點使用 DNF。針對 DNF 操作，Patch Manager 需要 `Python 2` 或 `Python 3` 的支援版本 (2.6 - 3.12)。(預設不會在 RHEL 8 上安裝兩個版本。您必須手動安裝其中一個。)
+ Debian Server 和 Ubuntu Server 執行個體使用 APT。針對 APT 操作，Patch Manager 需要 `Python 3` 的支援版本 (3.0 - 3.12)。
------
#### [ Windows Server ]
在 Windows Server 受管節點上，`AWS-RunPatchBaselineWithHooks` 文件會下載並叫用 PowerShell 模組，進而下載套用至受管節點的修補基準快照。此修補基準快照集包含已核准修補程式清單，這些修補程式是藉由查詢修補基準針對 Windows Server 更新服務 (WSUS) 伺服器進行編譯。此清單會傳遞至 Windows Update API，視需要控制下載和安裝核准的修補程式。
------
每個快照都專屬於 AWS 帳戶、修補程式群組、作業系統和快照 ID。快照是透過預先簽署的 Amazon Simple Storage Service (Amazon S3) URL 交付，快照會在建立後 24 小時過期。不過，URL 過期後，如果想要將相同的快照內容套用到其他受管節點，則您可以在建立快照後最多三天內產生新的預先簽署 Amazon Simple Storage Service (Amazon S3) URL。若要這麼做，請使用 [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html) 命令。
在安裝所有已核准且適用的更新，並視需要重新啟動之後，會在受管節點上產生修補程式合規資訊，並回報 Patch Manager。
如果在 `AWS-RunPatchBaselineWithHooks` 文件中將 `RebootOption` 參數設定為 `NoReboot`，則在執行 Patch Manager 後不會重新啟動受管節點。如需詳細資訊，請參閱[參數名稱：`RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。
**重要**
雖然 `NoReboot` 選項可防止作業系統重新啟動，但無法防止更新特定套件時可能發生的服務層級重新啟動。例如，即使 `NoReboot` 已指定，更新 Docker 之類的套件也可能會觸發相依服務 (例如容器協同運作服務) 的自動重新啟動。
如需有關檢視修補程式合規資料的詳細資訊，請參閱[關於修補程式合規](compliance-about.md#compliance-monitor-patch)。
## `AWS-RunPatchBaselineWithHooks` 操作步驟
當 `AWS-RunPatchBaselineWithHooks` 執行時，會進行下列步驟：
1. **掃描** – 在受管節點上執行使用 `AWS-RunPatchBaseline` 的 `Scan` 操作，並產生並上傳合規報告。
1. **確認本機修補程式狀態** – 執行指令碼，以確定將根據所選的操作和步驟 1 的 `Scan` 結果執行什麼步驟。
1. 如果選取的操作為 `Scan`，則操作會標示為完成。操作結束。
1. 如果選取的操作為 `Install`，則 Patch Manager 會評估步驟 1 的 `Scan` 結果，以確定接下來要執行的內容：
1. 如果未偵測到遺漏的修補程式，且不需要擱置中的重新開機，則操作會直接進行到最後一個步驟 (步驟 8)，其中包括您提供的掛鉤。兩者之間的任何步驟都會略過。
1. 如果未偵測到遺漏的修補程式，但有所需的擱置中重新開機，且所選重新開啟選項為 `NoReboot`，則操作會直接進行到最後一個步驟 (步驟 8)，其中包括您提供的掛鉤。兩者之間的任何步驟都會略過。
1. 否則，操作會繼續至下一個步驟。
1. **修補程式前掛鉤操作** - 您為第一個lifecycle hook `PreInstallHookDocName` 提供的 SSM 文件在受管節點上執行。
1. **使用 NoReboot 安裝** – 使用 `AWS-RunPatchBaseline` 且具有 `NoReboot` 重啟啟動選項的 `Install` 操作在受管節點上執行，還會產生並上傳合規報告。
1. **安裝後掛鉤操作** - 您為第二個lifecycle hook `PostInstallHookDocName` 提供的 SSM 文件在受管節點上執行。
1. **確認重新啟動** – 執行指令碼以判斷受管節點是否需要重新開機，以及需要執行哪些步驟：
1. 如果選取的重新開機選項為 `NoReboot`，則操作會直接進行到最後一個步驟 (步驟 8)，其中包含您提供的掛鉤。兩者之間的任何步驟都會略過。
1. 如果選取的重新開機選項為 `RebootIfNeeded`，則 Patch Manager 會檢查步驟 4 中所收集的庫存是否有所需之任何擱置中的重新開機。這意味著在下列任一情況下，作業會繼續執行步驟 7，且受管節點會重新啟動：
1. Patch Manager 已安裝一個或多個修補程式。(Patch Manager 不評估修補程式是否需要重新啟動。即使修補程式不需要重新啟動，系統也會重新啟動。)
1. Patch Manager 偵測到一或多個修補程式在安裝操作期間狀態為 `INSTALLED_PENDING_REBOOT`。`INSTALLED_PENDING_REBOOT` 狀態可能表示上次 Install 操作時已選取 `NoReboot` 選項，或者自上次重新啟動受管節點後，已在 Patch Manager 外部安裝修補程式。
如果找不到需要符合這些條件的修補程式，則受管節點修補操作即完成，且操作會直接進行到最後一個步驟 (步驟 8)，其中包括您提供的掛鉤。兩者之間的任何步驟都會略過。
1. **重新啟動和報告** – 具有 `RebootIfNeeded` 重啟啟動選項的安裝操作在使用 `AWS-RunPatchBaseline` 的受管節點上執行，還會產生並上傳合規報告。
1. **重新啟動後掛鉤操作** – 您為第三個lifecycle hook `OnExitHookDocName` 提供的 SSM 文件在受管節點上執行。
對於 `Scan` 操作，如果步驟 1 失敗，則執行文件的程序會停止並報告為失敗，儘管後續步驟會報告為成功。
對於 `Install` 操作，如果有任何 `aws:runDocument` 步驟在操作期間失敗，則這些步驟會報告為失敗，而且操作會直接進行到最後一個步驟 (步驟 8)，其中包含您提供的掛鉤。兩者之間的任何步驟都會略過。此步驟會報告為失敗，最後一個步驟會報告其操作結果的狀態，而兩者之間的所有步驟都會報告為成功。
## `AWS-RunPatchBaselineWithHooks` 參數
`AWS-RunPatchBaselineWithHooks` 支援六個參數。
`Operation` 參數是必要參數。
`RebootOption`、`PreInstallHookDocName`、`PostInstallHookDocName` 和 `OnExitHookDocName` 是選用參數。
`Snapshot-ID` 在技術上是選用的，但建議您在維護時段以外執行 `AWS-RunPatchBaselineWithHooks` 時，為其提供自訂值。當文件以維護時段操作的一部分執行時，讓 Patch Manager 自動提供值。
**Topics**
+ [參數名稱：`Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [參數名稱：`Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [參數名稱：`PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [參數名稱：`PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [參數名稱：`OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### 參數名稱：`Operation`
**用量**：必要。
**選項**：`Scan` \$1 `Install`。
Scan
當您選擇 `Scan` 選項時，系統會使用 `AWS-RunPatchBaseline` 文件判斷受管節點的修補程式合規狀態，並將此資訊回報至 Patch Manager。`Scan` 不會提示要安裝的更新或需要重新啟動的受管節點。反之，此操作會識別遺漏了哪些已核准且適用於節點的更新。
安裝
當您選擇 `Install` 選項，`AWS-RunPatchBaselineWithHooks` 會嘗試安裝受管節點上遺漏的已核准且適用的更新。在 `Install` 操作中產生的修補程式合規資訊不會列出任何遺失的更新，但如果因為任何原因導致未成功安裝更新，則可能會報告狀態為失敗的更新。每當更新安裝於受管節點時，節點將重新啟動，以確保安裝並啟動更新。(例外：如果 `AWS-RunPatchBaselineWithHooks` 文件中的 `RebootOption` 參數設為 `NoReboot`，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 [參數名稱：`RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)。)
如果在 Patch Manager 更新受管節點*之前*已安裝基準規則指定的修補程式，系統可能無法如預期重新啟動。當使用者手動安裝修補程式，或由其他程式自動安裝 (例如 Ubuntu Server 上的 `unattended-upgrades` 套件) 時，就會發生這種情況。
### 參數名稱：`Snapshot ID`
**用量**：選用。
`Snapshot ID` 是 Patch Manager 使用的唯一 ID (GUID)，確保在單一操作中修補的一組受管節點皆有一組完全相同的核准修補程式。雖然此參數定義為選用，但我們的最佳實務建議取決於您是否會在維護時段中執行 `AWS-RunPatchBaselineWithHooks`，如下表所述。
**`AWS-RunPatchBaselineWithHooks` 最佳實務**
| Mode | 最佳實務 | 詳細資訊 |
| --- | --- | --- |
| 在維護時段內執行 AWS-RunPatchBaselineWithHooks | 請勿提供快照 ID。Patch Manager 將會為您提供。 | 若您使用維護時段執行 `AWS-RunPatchBaselineWithHooks`，您不應提供自己產生的快照 ID。在此案例中，Systems Manager 會根據維護時段執行 ID 提供 GUID 值。這可確保維護時段中所有 `AWS-RunPatchBaselineWithHooks` 呼叫皆使用正確的 ID。 如果您在此情況下指定值，則請注意修補基準的快照可能不會保留超過 3 天。之後，即使您在快照過期後指定相同的 ID，仍將會產生新的快照。 |
| 在維護時段外執行 AWS-RunPatchBaselineWithHooks | 為快照 ID¹ 產生及指定自訂 GUID 值。 | 如果您不是使用維護時段執行 `AWS-RunPatchBaselineWithHooks`，我們建議您為每個修補基準產生並指定唯一的快照 ID，特別是如果您在相同的操作中，在多個受管節點上執行 `AWS-RunPatchBaselineWithHooks` 文件時。如果您在此情況下沒有指定 ID，Systems Manager 將為命令傳送至的每個受管節點產生不同的快照 ID。這可能會導致在節點間指定不同的修補程式集合。 例如，假設您正在直接透過 Run Command (AWS Systems Manager中的工具) 執行 `AWS-RunPatchBaselineWithHooks` 文件，並以包含 50 個受管節點的群組為目標。指定自訂快照 ID 會產生單一基準快照，用於評估和修補所有受管節點，以確保它們最終處於一致的狀態。 |
| ¹您可以使用任何能產生 GUID 的工具來為快照 ID 參數產生一個值。例如，在 PowerShell，您可以使用 `New-Guid` cmdlet 產生 `12345699-9405-4f69-bc5e-9315aEXAMPLE` 格式的 GUID。 |
### 參數名稱：`RebootOption`
**用量**：選用。
**選項**: `RebootIfNeeded` \$1 `NoReboot`
**預設**：`RebootIfNeeded`
**警告**
預設選項為 `RebootIfNeeded`。請務必選取適用於您使用案例的正確選項。例如，如果您的受管節點必須立即重新啟動才能完成組態程序，則請選擇 `RebootIfNeeded`。或者，如果您需要維持受管節點的可用性，直到排定的重新啟動時間，則請選擇 `NoReboot`。
**重要**
我們不建議使用 Patch Manager 修補 Amazon EMR (以前稱為 Amazon Elastic MapReduce) 中的叢集執行個體。特別是，請勿為 `RebootOption` 參數選取 `RebootIfNeeded` 選項。(此選項在用於修補 `AWS-RunPatchBaseline`、`AWS-RunPatchBaselineAssociation` 和 `AWS-RunPatchBaselineWithHooks` 的 SSM 命令文件中可用。)
使用 Patch Manager 進行修補時所使用的基礎命令使用 `yum` 和 `dnf` 命令。因此，相關操作會因套件的安裝方式而導致不相容。如需有關在 Amazon EMR 叢集上更新軟體的慣用方法的詳細資訊，請參閱《Amazon EMR 管理指南》**中的[使用 Amazon EMR 的預設 AMI](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) 一節。
RebootIfNeeded
當您選擇 `RebootIfNeeded` 選項時，受管節點在下列情況下會重新啟動：
+ Patch Manager 已安裝一或多個修補程式。
Patch Manager 不會評估修補程式是否*需要*重新開機。即使修補程式不需要重新開機，系統也會重新開機。
+ Patch Manager 偵測到一或多個修補程式在 `Install` 操作期間狀態為 `INSTALLED_PENDING_REBOOT`。
`INSTALLED_PENDING_REBOOT` 狀態可能表示上次執行 `Install` 操作時已選取 `NoReboot` 選項，或者自上次重新啟動受管節點後，已在 Patch Manager 外部安裝修補程式。
在這兩種情況下重新啟動受管節點，可確保更新的套件會從記憶體中清除，並在所有作業系統中保持修補和重新啟動行為一致。
NoReboot
當您選擇 `NoReboot` 選項時，即使受管節點在 `Install` 作業期間安裝了修補程式，Patch Manager 也不會重新啟動受管節點。如果您知道您的受管節點在套用修補程式之後不需要重新啟動，或是您在節點上執行的應用程式或程序不應因於修補操作重新啟動而中斷，則此選項非常有用。當您想要進一步控制受管節點重新啟動的時間時 (例如使用維護時段)，此選項也很有用。
如果您選擇 `NoReboot` 選項並安裝修補程式，則會為修補程式指派 `InstalledPendingReboot` 的狀態。但是，受管節點本身會標示為 `Non-Compliant`。重新啟動並執行 `Scan` 操作之後，節點狀態會更新為 `Compliant`。
**修補程式安裝追蹤檔案**：若要追蹤修補程式安裝，特別是自上次系統重新啟動後已安裝的修補程式，Systems Manager 會在受管節點上維護檔案。
**重要**
請勿刪除或修改追蹤檔案。如果此檔案已刪除或損毀，則受管節點的修補程式合規報告會不正確。如果發生此情況，請重新啟動節點並執行修補程式掃描作業以還原檔案。
此追蹤檔案存放於受管節點的下列位置：
+ Linux 作業系統：
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server 作業系統：
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### 參數名稱：`PreInstallHookDocName`
**用量**：選用。
**預設**︰`AWS-Noop`。
提供給 `PreInstallHookDocName` 參數的值是您所選 SSM 文件的名稱或 Amazon Resource Name (ARN)。您可以提供 AWS 受管文件的名稱，或已建立或已與您共用的自訂 SSM 文件的名稱或 ARN。（對於從不同 與您共用的 SSM 文件 AWS 帳戶，您必須指定完整的資源 ARN，例如 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`。)
您指定的 SSM 文件會在 `Install` 操作之前執行，並執行 SSM Agent 支援的任何動作，例如用於在受管節點上執行修補之前進行應用程式運作狀態檢查的 shell 指令碼。(如需動作清單，請參閱 [命令文件外掛程式參考](documents-command-ssm-plugin-reference.md))。預設 SSM 文件名稱為 `AWS-Noop`，它不會對受管節點執行任何操作。
如需建立自訂 SSM 文件的詳細資訊，請參閱 [建立 SSM 文件內容](documents-creating-content.md)。
### 參數名稱：`PostInstallHookDocName`
**用量**：選用。
**預設**︰`AWS-Noop`。
提供給 `PostInstallHookDocName` 參數的值是您所選 SSM 文件的名稱或 Amazon Resource Name (ARN)。您可以提供 AWS 受管文件的名稱，或已建立或已與您共用的自訂 SSM 文件的名稱或 ARN。（對於從不同 與您共用的 SSM 文件 AWS 帳戶，您必須指定完整的資源 ARN，例如 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`。)
在 `Install with NoReboot` 操作之後執行您指定的 SSM 文件，還會執行 SSM Agent 支援的任何操作，例如重新開機前安裝第三方更新的 shell 指令碼。(如需動作清單，請參閱 [命令文件外掛程式參考](documents-command-ssm-plugin-reference.md))。預設 SSM 文件名稱為 `AWS-Noop`，它不會對受管節點執行任何操作。
如需建立自訂 SSM 文件的詳細資訊，請參閱 [建立 SSM 文件內容](documents-creating-content.md)。
### 參數名稱：`OnExitHookDocName`
**用量**：選用。
**預設**︰`AWS-Noop`。
提供給 `OnExitHookDocName` 參數的值是您所選 SSM 文件的名稱或 Amazon Resource Name (ARN)。您可以提供 AWS 受管文件的名稱，或已建立或已與您共用的自訂 SSM 文件的名稱或 ARN。(若是來自不同 AWS 帳戶且已與您共用的 SSM 文件，您必須指定完整資源 ARN，例如 `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`。)
您指定的 SSM 文件會在受管節點重新啟動操作之後執行，並執行 SSM Agent 支援的任何動作，例如用於在修補操作完成之後確認節點運作狀態的 shell 指令碼。(如需動作清單，請參閱 [命令文件外掛程式參考](documents-command-ssm-plugin-reference.md))。預設 SSM 文件名稱為 `AWS-Noop`，它不會對受管節點執行任何操作。
如需建立自訂 SSM 文件的詳細資訊，請參閱 [建立 SSM 文件內容](documents-creating-content.md)。