如何安裝修補程式

Patch Manager是的功能 AWS Systems Manager，針對作業系統類型使用適當的內建機制，在受管節點上安裝更新。例如，在上 Windows Server，API會使用 Windows Update，並在 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 受管節點上，修補程式安裝工作流程如下所示：

如果使用 https URL或 Amazon Simple Storage Service （Amazon S3）路徑樣式URL，使用 AWS-RunPatchBaseline或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數指定修補程式清單，則會安裝列出的修補程式，並略過步驟 2-7。
套用 GlobalFilters 如修補程式基準中指定，僅保留合格的套件以進行進一步處理。
套用 ApprovalRules 如修補程式基準中所指定。每個核准規則皆可將套件定義為已核准。

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

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

如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
套用 ApprovedPatches 如修補程式基準中所指定。核准的修補程式會核准更新，即使其被捨棄 GlobalFilters 或中未指定核准規則 ApprovalRules 會授予其核准。
套用 RejectedPatches 如修補程式基準中所指定。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
如果核准修補程式的多個版本，將會套用最新版本。
YUM 更新 API（Amazon Linux 1、Amazon Linux 2）或DNF更新 API（Amazon Linux 2022、Amazon Linux 2023）會套用至核准的修補程式，如下所示：
- 對於由 AWS提供的預先定義預設修補基準，僅會套用 updateinfo.xml 中指定的修補程式 (僅限安全性更新)。這是因為未選取包含非安全性更新核取方塊。預先定義的基準等同於具有下列項目的自訂基準：
  - 未選取包含非安全性更新核取方塊
  - 的SEVERITY清單 [Critical, Important]
  - 的CLASSIFICATION清單 [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，如果選取包含非安全性更新的基準，則具有 SEVERITY清單[Critical, Important]和 CLASSIFICATION清單[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套件管理員識別。
如有安裝任何更新，受管節點將會重新啟動。（例外：如果NoRebootAWS-RunPatchBaseline文件中的 RebootOption 參數設定為，則受管節點在 Patch Manager 執行。如需詳細資訊，請參閱參數名稱：RebootOption)。

CentOS and CentOS Stream

在 CentOS 和上 CentOS Stream 受管節點的修補程式安裝工作流程如下所示：

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

套用 GlobalFilters 如修補程式基準中指定，僅保留合格的套件以進行進一步處理。
套用 ApprovalRules 如修補程式基準中所指定。每個核准規則皆可將套件定義為已核准。

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

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

如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
套用 ApprovedPatches 如修補程式基準中所指定。核准的修補程式會核准更新，即使其被捨棄 GlobalFilters 或中未指定核准規則 ApprovalRules 會授予其核准。
套用 RejectedPatches 如修補程式基準中所指定。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
如果核准修補程式的多個版本，將會套用最新版本。
YUM 更新 API（在 CentOS 6.x 和 7.x 版本上）或DNF更新（在 CentOS 8 和 CentOS Stream）會套用至核准的修補程式。
如有安裝任何更新，受管節點將會重新啟動。（例外：如果NoRebootAWS-RunPatchBaseline文件中的 RebootOption 參數設定為，則受管節點在 Patch Manager 執行。如需詳細資訊，請參閱參數名稱：RebootOption)。

Debian Server and Raspberry Pi OS

開啟 Debian Server 以及 Raspberry Pi OS （先前為 Raspbian）執行個體，修補程式安裝工作流程如下所示：

如果使用 https URL或 Amazon Simple Storage Service （Amazon S3）路徑樣式URL，使用 AWS-RunPatchBaseline或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數指定修補程式清單，則會安裝列出的修補程式，並略過步驟 2-7。
若有可用於 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 會更新系統，重複相同的程序。
套用 GlobalFilters 如修補程式基準中指定，僅保留合格的套件以進行進一步處理。
套用 ApprovalRules 如修補程式基準中所指定。每個核准規則皆可將套件定義為已核准。

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

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

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

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

注意
用於 Debian Server 以及 Raspberry Pi OS，修補候選版本僅限於中包含的修補程式debian-security。
套用 ApprovedPatches 如修補程式基準中所指定。核准的修補程式會核准更新，即使其被捨棄 GlobalFilters 或中未指定核准規則 ApprovalRules 會授予其核准。
套用 RejectedPatches 如修補程式基準中所指定。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
APT 程式庫用於升級套件。

注意
Patch Manager 不支援使用 APTPin-Priority選項將優先順序指派給套件。Patch Manager 從所有已啟用的儲存庫彙總可用的更新，並選取符合每個已安裝套件基準的最新更新。
如有安裝任何更新，受管節點將會重新啟動。（例外：如果NoRebootAWS-RunPatchBaseline文件中的 RebootOption 參數設定為，則受管節點在 Patch Manager 執行。如需詳細資訊，請參閱參數名稱：RebootOption)。

macOS

開啟 macOS 受管節點的修補程式安裝工作流程如下所示：

/Library/Receipts/InstallHistory.plist 屬性清單是使用 softwareupdate 和 installer 套件管理工具的已安裝和已升級軟體記錄。使用pkgutil命令列工具（適用於 installer）和softwareupdate套件管理員，執行CLI命令來剖析此清單。

對於 installer，對CLI命令的回應包含 package name、version、location、 volume和 install-time詳細資訊，但只有 package name和 version 會由使用 Patch Manager.

對於 softwareupdate，對CLI命令的回應包含套件名稱（display name）version、和 date，但修補程式管理員只會使用套件名稱和版本。

對於 Brew 和 Brew Cask，Homebrew 不支援其在根使用者下執行的命令。因此 Patch Manager 查詢並以 Homebrew 目錄的擁有者身分，或以屬於 Homebrew 目錄擁有者群組的有效使用者身分執行 Homebrew 命令。這些命令類似於 softwareupdate 和 installer 並透過 Python 子程序執行命令，以收集套件資料，並解析輸出以識別套件名稱和版本。
套用 GlobalFilters 如修補程式基準中指定，僅保留合格的套件以進行進一步處理。
套用 ApprovalRules 如修補程式基準中所指定。每個核准規則皆可將套件定義為已核准。
套用 ApprovedPatches 如修補程式基準中所指定。核准的修補程式會核准更新，即使其被捨棄 GlobalFilters 或中未指定核准規則 ApprovalRules 會授予其核准。
套用 RejectedPatches 如修補程式基準中所指定。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
如果核准修補程式的多個版本，將會套用最新版本。
在受管節點CLI上調用適當的套件，以處理核准的修補程式，如下所示：

注意
installer 缺乏檢查和安裝更新的功能。因此，對於 installer，Patch Manager 僅報告要安裝哪些套件。因此，installer 套件永遠不會報告為 Missing。
- 針對 AWS提供的預先定義預設修補基準，以及未選取包含非安全性更新核取方塊的自訂修補基準，則只會套用安全性更新。
- 針對已選取包含非安全性更新核取方塊的自訂修補基準，會套用安全性和非安全性更新。
如有安裝任何更新，受管節點將會重新啟動。（例外：如果NoRebootAWS-RunPatchBaseline文件中的 RebootOption 參數設定為，則受管節點在 Patch Manager 執行。如需詳細資訊，請參閱參數名稱：RebootOption)。

Oracle Linux

開啟 Oracle Linux 受管節點的修補程式安裝工作流程如下所示：

如果使用 https URL或 Amazon Simple Storage Service （Amazon S3）路徑樣式URL，使用 AWS-RunPatchBaseline或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數指定修補程式清單，則會安裝列出的修補程式，並略過步驟 2-7。
套用 GlobalFilters 如修補程式基準中指定，僅保留合格的套件以進行進一步處理。
套用 ApprovalRules 如修補程式基準中所指定。每個核准規則皆可將套件定義為已核准。

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

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

如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
套用 ApprovedPatches 如修補程式基準中所指定。核准的修補程式會核准更新，即使其被捨棄 GlobalFilters 或未於中指定核准規則 ApprovalRules 會授予其核准。
套用 RejectedPatches 如修補程式基準中所指定。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
如果核准修補程式的多個版本，將會套用最新版本。
在版本 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
如有安裝任何更新，受管節點將會重新啟動。（例外：如果NoRebootAWS-RunPatchBaseline文件中的 RebootOption 參數設定為，則受管節點在 Patch Manager 執行。如需詳細資訊，請參閱參數名稱：RebootOption)。

AlmaLinux, RHEL, and Rocky Linux

在上 AlmaLinux，Red Hat Enterprise Linux 和 Rocky Linux 受管節點的修補程式安裝工作流程如下所示：

如果使用 https URL或 Amazon Simple Storage Service （Amazon S3）路徑樣式URL，使用 AWS-RunPatchBaseline或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數指定修補程式清單，則會安裝列出的修補程式，並略過步驟 2-7。
套用 GlobalFilters 如修補程式基準中指定，僅保留合格的套件以進行進一步處理。
套用 ApprovalRules 如修補程式基準中所指定。每個核准規則皆可將套件定義為已核准。

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

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

如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
套用 ApprovedPatches 如修補程式基準中所指定。核准的修補程式會核准更新，即使其被捨棄 GlobalFilters 或未於中指定核准規則 ApprovalRules 會授予其核准。
套用 RejectedPatches 如修補程式基準中所指定。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
如果核准修補程式的多個版本，將會套用最新版本。
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
```
如有安裝任何更新，受管節點將會重新啟動。（例外：如果NoRebootAWS-RunPatchBaseline文件中的 RebootOption 參數設定為，則受管節點在 Patch Manager 執行。如需詳細資訊，請參閱參數名稱：RebootOption)。

SLES

開啟 SUSE Linux Enterprise Server (SLES）受管節點，修補程式安裝工作流程如下所示：

如果使用 https URL或 Amazon Simple Storage Service （Amazon S3）路徑樣式URL，使用 AWS-RunPatchBaseline或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數指定修補程式清單，則會安裝列出的修補程式，並略過步驟 2-7。
套用 GlobalFilters 如修補程式基準中指定，僅保留合格的套件以進行進一步處理。
套用 ApprovalRules 如修補程式基準中所指定。每個核准規則皆可將套件定義為已核准。

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

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

如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
套用 ApprovedPatches 如修補程式基準中所指定。核准的修補程式會核准更新，即使其被捨棄 GlobalFilters 或未於中指定核准規則 ApprovalRules 會授予其核准。
套用 RejectedPatches 如修補程式基準中所指定。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
如果核准修補程式的多個版本，將會套用最新版本。
Zypper 更新API會套用至核准的修補程式。
如有安裝任何更新，受管節點將會重新啟動。（例外：如果NoRebootAWS-RunPatchBaseline文件中的 RebootOption 參數設定為，則受管節點在 Patch Manager 執行。如需詳細資訊，請參閱參數名稱：RebootOption)。

Ubuntu Server

開啟 Ubuntu Server 受管節點的修補程式安裝工作流程如下所示：

如果使用 https URL或 Amazon Simple Storage Service （Amazon S3）路徑樣式URL，使用 AWS-RunPatchBaseline或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數指定修補程式清單，則會安裝列出的修補程式，並略過步驟 2-7。
若有可用於 python3-apt (libapt 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 Include nonsecurity updates (包含非安全性更新) 選項)。
套用 GlobalFilters 如修補程式基準中指定，僅保留合格的套件以進行進一步處理。
套用 ApprovalRules 如修補程式基準中所指定。每個核准規則皆可將套件定義為已核准。

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

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

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

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

然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。
注意
針對每個版本的 Ubuntu Server，修補候選版本僅限於作為該版本關聯儲存庫一部分的修補程式，如下所示：
- Ubuntu Server 14.04LTS： 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
套用 ApprovedPatches 如修補程式基準中所指定。核准的修補程式會核准更新，即使其被捨棄 GlobalFilters 或未於中指定核准規則 ApprovalRules 會授予其核准。
套用 RejectedPatches 如修補程式基準中所指定。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。
APT 程式庫用於升級套件。

注意
Patch Manager 不支援使用 APTPin-Priority選項將優先順序指派給套件。Patch Manager 從所有已啟用的儲存庫彙總可用的更新，並選取符合每個已安裝套件基準的最新更新。
如有安裝任何更新，受管節點將會重新啟動。（例外：如果NoRebootAWS-RunPatchBaseline文件中的 RebootOption 參數設定為，則受管節點在 Patch Manager 執行。如需詳細資訊，請參閱參數名稱：RebootOption)。

Windows Server

在上執行修補操作時 Windows Server 受管節點，節點會向 Systems Manager 請求適當修補程式基準的快照。此快照包含已核准部署之修補基準中所有可用更新的清單。此更新清單會傳送至 Windows Update API，此版本決定哪些更新適用於受管節點，並視需要安裝這些更新。Windows 僅允許安裝最新版本的 KB。Patch Manager 當 KB 或任何先前版本的 KB 符合套用的修補程式基準時，會安裝最新版本的 KB。如有安裝任何更新，受管節點將會重新啟動，重新啟動的次數依據完成所有必要修補的需要而定。（例外：如果NoRebootAWS-RunPatchBaseline文件中的 RebootOption 參數設定為，則受管節點在 Patch Manager 執行。如需詳細資訊，請參閱參數名稱：RebootOption)。修補操作的摘要可在的輸出中找到 Run Command 請求。在 %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs 資料夾的受管節點上，可以找到額外的日誌。

由於 Windows Update API 用於下載和安裝 KBs，因此會尊重 Windows Update 的所有群組政策設定。不需要群組政策設定即可使用 Patch Manager，但您定義的任何設定都會套用，例如將受管節點導向 Windows Server Update Services （WSUS）伺服器。

注意

根據預設，Windows KBs 會從 Microsoft 的 Windows Update 網站下載所有，因為 Patch Manager 使用 Windows Update API來驅動的下載和安裝KBs。因此，受管節點必須能夠連接至 Microsoft Windows Update 網站，否則修補將會失敗。或者，您可以設定WSUS伺服器做為 KB 儲存庫，並使用群組政策設定受管節點以該WSUS伺服器為目標。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

如何指定替代修補程式來源儲存庫 (Linux)

修補基準規則在 Linux 系統上的運作方式

如何安裝修補程式

注意

重要

注意

注意

注意

注意

注意

注意

注意

注意