• The AWS Systems Manager CloudWatch Dashboard will no longer be available after April 30, 2026. Customers can continue to use Amazon CloudWatch console to view, create, and manage their Amazon CloudWatch dashboards, just as they do today. For more information, see [Amazon CloudWatch Dashboard documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). # Patch baselines The topics in this section provide information about how patch baselines work in Patch Manager, a tool in AWS Systems Manager, when you run a `Scan` or `Install` operation on your managed nodes. **Topics** + [ # Predefined and custom patch baselines ](patch-manager-predefined-and-custom-patch-baselines.md) + [ # Package name formats for approved and rejected patch lists ](patch-manager-approved-rejected-package-name-formats.md) + [ # Patch groups ](patch-manager-patch-groups.md) + [ # Patching applications released by Microsoft on Windows Server ](patch-manager-patching-windows-applications.md) # Predefined and custom patch baselines Patch Manager, a tool in AWS Systems Manager, provides predefined patch baselines for each of the operating systems supported by Patch Manager. You can use these baselines as they are currently configured (you can't customize them) or you can create your own custom patch baselines. Custom patch baselines allows you greater control over which patches are approved or rejected for your environment. Also, the predefined baselines assign a compliance level of `Unspecified` to all patches installed using those baselines. For compliance values to be assigned, you can create a copy of a predefined baseline and specify the compliance values you want to assign to patches. For more information, see [Custom baselines](#patch-manager-baselines-custom) and [Working with custom patch baselines](patch-manager-manage-patch-baselines.md). **Note** The information in this topic applies no matter which method or type of configuration you are using for your patching operations: A patch policy configured in Quick Setup A Host Management option configured in Quick Setup A maintenance window to run a patch `Scan` or `Install` task An on-demand **Patch now** operation **Topics** + [ ## Predefined baselines ](#patch-manager-baselines-pre-defined) + [ ## Custom baselines ](#patch-manager-baselines-custom) ## Predefined baselines The following table describes the predefined patch baselines provided with Patch Manager. For information about which versions of each operating system Patch Manager supports, see [Patch Manager prerequisites](patch-manager-prerequisites.md). **** | Name | Supported operating system | Details | | --- | --- | --- | | `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | Approves all operating system patches that are classified as "Security" and that have a severity level of "Critical" or "Important". Also approves all patches that are classified as "Bugfix". Patches are auto-approved 7 days after they are released or updated.¹ | | AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | Approves all operating system patches that are classified as "Security" and that have a severity level of "Critical" or "Important". Also approves all patches with a classification of "Bugfix". Patches are auto-approved 7 days after release.¹ | | AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | Approves all operating system patches that are classified as "Security" and that have a severity level of "Critical" or "Important". Patches are auto-approved seven days after release. Also approves all patches with a classification of "Bugfix" seven days after release. | | AWS-CentOSDefaultPatchBaseline | CentOS Stream | Approves all updates 7 days after they become available, including nonsecurity updates. | | AWS-DebianDefaultPatchBaseline | Debian Server | Immediately approves all operating system security-related patches that have a priority of "Required", "Important", "Standard," "Optional," or "Extra." There is no wait before approval because reliable release dates aren't available in the repositories. | | AWS-MacOSDefaultPatchBaseline | macOS | Approves all operating system patches that are classified as "Security". Also approves all packages with a current update. | | AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | Approves all operating system patches that are classified as "Security" and that have a severity level of "Important" or "Moderate". Also approves all patches that are classified as "Bugfix" 7 days after release. Patches are auto-approved 7 days after they are released or updated.¹ | | `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | Approves all operating system patches that are classified as "Security" and that have a severity level of "Critical" or "Important". Also approves all patches that are classified as "Bugfix". Patches are auto-approved 7 days after they are released or updated.¹ | | `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | Approves all operating system patches that are classified as "Security" and that have a severity level of "Critical" or "Important". Also approves all patches that are classified as "Bugfix". Patches are auto-approved 7 days after they are released or updated.¹ | | AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | Approves all operating system patches that are classified as "Security" and with a severity of "Critical" or "Important". Patches are auto-approved 7 days after they are released or updated.¹ | | `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | Immediately approves all operating system security-related patches that have a priority of "Required", "Important", "Standard," "Optional," or "Extra." There is no wait before approval because reliable release dates aren't available in the repositories. | | AWS-DefaultPatchBaseline | Windows Server | Approves all Windows Server operating system patches that are classified as "CriticalUpdates" or "SecurityUpdates" and that have an MSRC severity of "Critical" or "Important". Patches are auto-approved 7 days after they are released or updated.² | | AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | Approves all Windows Server operating system patches that are classified as "CriticalUpdates" or "SecurityUpdates" and that have an MSRC severity of "Critical" or "Important". Patches are auto-approved 7 days after they are released or updated.² | | AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | For the Windows Server operating system, approves all patches that are classified as "CriticalUpdates" or "SecurityUpdates" and that have an MSRC severity of "Critical" or "Important". For applications released by Microsoft, approves all patches. Patches for both OS and applications are auto-approved 7 days after they are released or updated.² | ¹ For Amazon Linux 2, the 7-day wait before patches are auto-approved is calculated from an `Updated Date` value in `updateinfo.xml`, not a `Release Date` value. Various factors can affect the `Updated Date` value. Other operating systems handle release and update dates differently. For information to help you avoid unexpected results with auto-approval delays, see [How package release dates and update dates are calculated](patch-manager-release-dates.md). ² For Windows Server, default baselines include a 7-day auto-approval delay. To install a patch within 7 days after release, you must create a custom baseline. ## Custom baselines Use the following information to help you create custom patch baselines to meet your patching goals. **Topics** + [ ### Using auto-approvals in custom baselines ](#baselines-auto-approvals) + [ ### Additional information for creating patch baselines ](#baseline-additional-info) ### Using auto-approvals in custom baselines If you create your own patch baseline, you can choose which patches to auto-approve by using the following categories. + **Operating system**: Supported versions of Windows Server, Amazon Linux, Ubuntu Server, and so on. + **Product name **(for operating systems): For example, RHEL 7.5, Amazon Linux 2023 2023.8.20250808, Windows Server 2012, Windows Server 2012 R2, and so on. + **Product name **(for applications released by Microsoft on Windows Server only): For example, Word 2016, BizTalk Server, and so on. + **Classification**: For example, Critical updates, Security updates, and so on. + **Severity**: For example, Critical, Important, and so on. For each approval rule that you create, you can choose to specify an auto-approval delay or specify a patch approval cutoff date. **Note** Because it's not possible to reliably determine the release dates of update packages for Ubuntu Server, the auto-approval options aren't supported for this operating system. An auto-approval delay is the number of days to wait after the patch was released or last updated, before the patch is automatically approved for patching. For example, if you create a rule using the `CriticalUpdates` classification and configure it for 7 days auto-approval delay, then a new critical patch released on July 7 is automatically approved on July 14. If a Linux repository does not provide release date information for packages, Patch Manager uses the build time of the package as the date for auto-approval date specifications for Amazon Linux 2, Amazon Linux 2023, and Red Hat Enterprise Linux (RHEL). If the build time of the package can't be determined, Patch Manager uses a default date of January 1st, 1970. This results in Patch Manager bypassing any auto-approval date specifications in patch baselines that are configured to approve patches for any date after January 1st, 1970. When you specify an auto-approval cutoff date, Patch Manager automatically applies all patches released or last updated on or before that date. For example, if you specify July 7, 2023 as the cutoff date, no patches released or last updated on or after July 8, 2023 are installed automatically. When you create a custom patch baseline, you can specify a compliance severity level for patches approved by that patch baseline, such as `Critical` or `High`. If the patch state of any approved patch is reported as `Missing`, then the patch baseline's overall reported compliance severity is the severity level you specified. ### Additional information for creating patch baselines Keep the following in mind when you create a patch baseline: + Patch Manager provides one predefined patch baseline for each supported operating system. These predefined patch baselines are used as the default patch baselines for each operating system type unless you create your own patch baseline and designate it as the default for the corresponding operating system type. **Note** For Windows Server, three predefined patch baselines are provided. The patch baselines `AWS-DefaultPatchBaseline` and `AWS-WindowsPredefinedPatchBaseline-OS` support only operating system updates on the Windows operating system itself. `AWS-DefaultPatchBaseline` is used as the default patch baseline for Windows Server managed nodes unless you specify a different patch baseline. The configuration settings in these two patch baselines are the same. The newer of the two, `AWS-WindowsPredefinedPatchBaseline-OS`, was created to distinguish it from the third predefined patch baseline for Windows Server. That patch baseline, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, can be used to apply patches to both the Windows Server operating system and supported applications released by Microsoft. + By default, Windows Server 2019 and Windows Server 2022 remove updates that are replaced by later updates. As a result, if you use the `ApproveUntilDate` parameter in a Windows Server patch baseline, but the date selected in the `ApproveUntilDate` parameter is before the date of the latest patch, then the new patch isn't installed when the patching operation runs. For more information about Windows Server patching rules, see the Windows Server tab in [How security patches are selected](patch-manager-selecting-patches.md). This means that the managed node is compliant in terms of Systems Manager operations, even though a critical patch from the previous month might not be installed. This same scenario can occur when using the `ApproveAfterDays` parameter. Because of the Microsoft superseded patch behavior, it is possible to set a number (generally greater than 30 days) so that patches for Windows Server are never installed if the latest available patch from Microsoft is released before the number of days in `ApproveAfterDays` has elapsed. + For Windows Server only, an available security update patch that is not approved by the patch baseline can have a compliance value of `Compliant` or `Non-Compliant`, as defined in a custom patch baseline. When you create or update a patch baseline, you choose the status you want to assign to security patches that are available but not approved because they don't meet the installation criteria specified in the patch baseline. For example, security patches that you might want installed can be skipped if you have specified a long period to wait after a patch is released before installation. If an update to the patch is released during your specified waiting period, the waiting period for installing the patch starts over. If the waiting period is too long, multiple versions of the patch could be released but never installed. Using the console to create or update a patch baseline, you specify this option in the **Available security updates compliance status** field. Using the AWS CLI to run the [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) or [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html) command, you specify this option in the `available-security-updates-compliance-status` parameter. + For on-premises servers and virtual machines (VMs), Patch Manager attempts to use your custom default patch baseline. If no custom default patch baseline exists, the system uses the predefined patch baseline for the corresponding operating system. + If a patch is listed as both approved and rejected in the same patch baseline, the patch is rejected. + A managed node can have only one patch baseline defined for it. + The formats of package names you can add to lists of approved patches and rejected patches for a patch baseline depend on the type of operating system you're patching. For information about accepted formats for lists of approved patches and rejected patches, see [Package name formats for approved and rejected patch lists](patch-manager-approved-rejected-package-name-formats.md). + If you are using a [patch policy configuration](patch-manager-policies.md) in Quick Setup, updates you make to custom patch baselines are synchronized with Quick Setup once an hour. If a custom patch baseline that was referenced in a patch policy is deleted, a banner displays on the Quick Setup **Configuration details** page for your patch policy. The banner informs you that the patch policy references a patch baseline that no longer exists, and that subsequent patching operations will fail. In this case, return to the Quick Setup **Configurations** page, select the Patch Manager configuration , and choose **Actions**, **Edit configuration**. The deleted patch baseline name is highlighted, and you must select a new patch baseline for the affected operating system. + When you create an approval rule with multiple `Classification` and `Severity` values, patches are approved based on their available attributes. Packages with both `Classification` and `Severity` attributes will match the selected baseline values for both fields. Packages with only `Classification` attributes are matched only against the selected baseline `Classification` values. Severity requirements in the same rule are ignored for packages that don't have `Severity` attributes. For information about creating a patch baseline, see [Working with custom patch baselines](patch-manager-manage-patch-baselines.md) and [Tutorial: Patch a server environment using the AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). # Package name formats for approved and rejected patch lists The formats of package names you can add to lists of approved patches and rejected patches depend on the type of operating system you're patching. ## Package name formats for Linux operating systems The formats you can specify for approved and rejected patches in your patch baseline vary by Linux type. More specifically, the formats that are supported depend on the package manager used by the type of Linux operating system. **Topics** + [ ### Amazon Linux 2, Amazon Linux 2023, Oracle Linux, and Red Hat Enterprise Linux (RHEL) ](#patch-manager-approved-rejected-package-name-formats-standard) + [ ### Debian Server and Ubuntu Server ](#patch-manager-approved-rejected-package-name-formats-ubuntu) + [ ### SUSE Linux Enterprise Server (SLES) ](#patch-manager-approved-rejected-package-name-formats-sles) ### Amazon Linux 2, Amazon Linux 2023, Oracle Linux, and Red Hat Enterprise Linux (RHEL) **Package manager**: YUM, except for Amazon Linux 2023, and RHEL 8, which use DNF as the package manager. **Approved patches**: For approved patches, you can specify any of the following: + Bugzilla IDs, in the format `1234567` (The system processes numbers-only strings as Bugzilla IDs.) + CVE IDs, in the format `CVE-2018-1234567` + Advisory IDs, in formats such as `RHSA-2017:0864`, `ALAS-2018-123`, `ALAS2023-2025-123`, and `ELSA-2025-123` + Package names that are constructed using one or more of the available components for package naming. To illustrate, for the package named `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, the components are as follows: + `name`: `dbus` + `architecture`: `x86_64` + `epoch`: `1` + `version`: `1.12.28` + `release`: `1.amzn2023.0.1` Package names with the following constructions are supported: + `name` + `name.arch` + `name-version` + `name-version-release` + `name-version-release.arch` + `version` + `version-release` + `epoch:version-release` + `name-epoch:version-release` + `name-epoch:version-release.arch` + `epoch:name-version-release.arch` + `name.arch:epoch:version-release` Some examples: + `dbus.x86_64` + `dbus-1.12.28` + `dbus-1.12.28-1.amzn2023.0.1` + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64` + We also support package name components with a single wild card in the above formats, such as the following: + `dbus*` + `dbus-1.12.2*` + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64` **Rejected patches**: For rejected patches, you can specify any of the following: + Package names that are constructed using one or more of the available components for package naming. To illustrate, for the package named `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, the components are as follows: + `name`: `dbus` + `architecture`; `x86_64` + `epoch`: `1` + `version`: `1.12.28` + `release`: `1.amzn2023.0.1` Package names with the following constructions are supported: + `name` + `name.arch` + `name-version` + `name-version-release` + `name-version-release.arch` + `version` + `version-release` + `epoch:version-release` + `name-epoch:version-release` + `name-epoch:version-release.arch` + `epoch:name-version-release.arch` + `name.arch:epoch:version-release` Some examples: + `dbus.x86_64` + `dbus-1.12.28` + `dbus-1.12.28-1.amzn2023.0.1` + `dbus-1:1.12.28-1.amzn2023.0.1.x86_64` + We also support package name components with a single wild card in the above formats, such as the following: + `dbus*` + `dbus-1.12.2*` + `dbus-*:1.12.28-1.amzn2023.0.1.x86_64` ### Debian Server and Ubuntu Server **Package manager**: APT **Approved patches** and **rejected patches**: For both approved and rejected patches, specify the following: + Package names, in the format `ExamplePkg33` **Note** For Debian Server lists, and Ubuntu Server lists, don't include elements such as architecture or versions. For example, you specify the package name `ExamplePkg33` to include all the following in a patch list: `ExamplePkg33.x86.1` `ExamplePkg33.x86.2` `ExamplePkg33.x64.1` `ExamplePkg33.3.2.5-364.noarch` ### SUSE Linux Enterprise Server (SLES) **Package manager**: Zypper **Approved patches** and **rejected patches**: For both approved and rejected patch lists, you can specify any of the following: + Full package names, in formats such as: + `SUSE-SLE-Example-Package-15-2023-123` + `example-pkg-2023.15.4-46.17.1.x86_64.rpm` + Package names with a single wildcard, such as: + `SUSE-SLE-Example-Package-15-2023-*` + `example-pkg-2023.15.4-46.17.1.*.rpm` ## Package name formats for macOS **Supported package managers**: softwareupdate, installer, Brew, Brew Cask **Approved patches** and **rejected patches**: For both approved and rejected patch lists, you specify full package names, in formats such as: + `XProtectPlistConfigData` + `MRTConfigData` Wildcards aren't supported in approved and rejected patch lists for macOS. ## Package name formats for Windows operating systems For Windows operating systems, specify patches using Microsoft Knowledge Base IDs and Microsoft Security Bulletin IDs; for example: ``` KB2032276,KB2124261,MS10-048 ``` # Patch groups **Note** Patch groups are not used in patching operations that are based on *patch policies*. For information about working with patch policies, see [Patch policy configurations in Quick Setup](patch-manager-policies.md). Patch group functionality is not supported in the console for account-Region pairs that did not already use patch groups before patch policy support was released on December 22, 2022. Patch group functionality is still available in account-Region pairs that began using patch groups before this date. You can use a *patch group* to associate managed nodes with a specific patch baseline in Patch Manager, a tool in AWS Systems Manager. Patch groups help ensure that you're deploying the appropriate patches, based on the associated patch baseline rules, to the correct set of nodes. Patch groups can also help you avoid deploying patches before they have been adequately tested. For example, you can create patch groups for different environments (such as Development, Test, and Production) and register each patch group to an appropriate patch baseline. When you run `AWS-RunPatchBaseline` or other SSM Command documents for patching, you can target managed nodes using their ID or tags. SSM Agent and Patch Manager then evaluate which patch baseline to use based on the patch group value that you added to the managed node. ## Using tags to define patch groups You create a patch group by using tags applied to your Amazon Elastic Compute Cloud (Amazon EC2) instances and non-EC2 nodes in a [hybrid and multicloud](operating-systems-and-machine-types.md#supported-machine-types) environment. Note the following details about using tags for patch groups: + A patch group must be defined using either the tag key `Patch Group` or `PatchGroup` applied to your managed nodes. When registering a patch group for a patch baseline, any identical *values* specified for these two keys are interpreted to be part of the same group. For instance, say that you have tagged five nodes with the first of the following key-value pairs, and five with the second: + `key=PatchGroup,value=DEV` + `key=Patch Group,value=DEV` The Patch Manager command to create a baseline combines these 10 managed nodes into a single group based on the value `DEV`. The AWS CLI equivalent for the command to create a patch baseline for patch groups is as follows: ``` aws ssm register-patch-baseline-for-patch-group \ --baseline-id pb-0c10e65780EXAMPLE \ --patch-group DEV ``` Combining values from different keys into a single target is unique to this Patch Manager command for creating a new patch group and not supported by other API actions. For example, if you run [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) actions using `PatchGroup` and `Patch Group` keys with the same values, you are targeting two completely different sets of nodes: ``` aws ssm send-command \ --document-name AWS-RunPatchBaseline \ --targets "Key=tag:PatchGroup,Values=DEV" ``` ``` aws ssm send-command \ --document-name AWS-RunPatchBaseline \ --targets "Key=tag:Patch Group,Values=DEV" ``` + There are limits on tag-based targeting. Each array of targets for `SendCommand` can contain a maximum of five key-value pairs. + We recommend that you choose only one of these tag key conventions, either `PatchGroup` (without a space) or `Patch Group` (with a space). However, if you have [allowed tags in EC2 instance metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS) on an instance, you must use `PatchGroup`. + The key is case-sensitive. You can specify any *value* to help you identify and target the resources in that group, for example "web servers" or "US-EAST-PROD", but the key must be `Patch Group` or `PatchGroup`. After you create a patch group and tag managed nodes, you can register the patch group with a patch baseline. Registering the patch group with a patch baseline ensures that the nodes within the patch group use the rules defined in the associated patch baseline. For more information about how to create a patch group and associate the patch group to a patch baseline, see [Creating and managing patch groups](patch-manager-tag-a-patch-group.md) and [Add a patch group to a patch baseline](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline). To view an example of creating a patch baseline and patch groups by using the AWS Command Line Interface (AWS CLI), see [Tutorial: Patch a server environment using the AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). For more information about Amazon EC2 tags, see [Tag your Amazon EC2 resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) in the *Amazon EC2 User Guide*. ## How it works When the system runs the task to apply a patch baseline to a managed node, SSM Agent verifies that a patch group value is defined for the node. If the node is assigned to a patch group, Patch Manager then verifies which patch baseline is registered to that group. If a patch baseline is found for that group, Patch Manager notifies SSM Agent to use the associated patch baseline. If a node isn't configured for a patch group, Patch Manager automatically notifies SSM Agent to use the currently configured default patch baseline. **Important** A managed node can only be in one patch group. A patch group can be registered with only one patch baseline for each operating system type. You can't apply the `Patch Group` tag (with a space) to an Amazon EC2 instance if the **Allow tags in instance metadata** option is enabled on the instance. Allowing tags in instance metadata prevents tag key names from containing spaces. If you have [allowed tags in EC2 instance metadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), you must use the tag key `PatchGroup` (without a space). **Diagram 1: General example of patching operations process flow** The following illustration shows a general example of the processes that Systems Manager performs when sending a Run Command task to your fleet of servers to patch using Patch Manager. These processes determine which patch baselines to use in patching operations. (A similar process is used when a maintenance window is configured to send a command to patch using Patch Manager.) The full process is explained below the illustration. ![\[Patch Manager workflow for determining which patch baselines to use when performing patching operations.\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/images/patch-groups-how-it-works.png) In this example, we have three groups of EC2 instances for Windows Server with the following tags applied: **** | EC2 instances group | Tags | | --- | --- | | Group 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` | | Group 2 | `key=OS,value=Windows` | | Group 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` | For this example, we also have these two Windows Server patch baselines: **** | Patch baseline ID | Default | Associated patch group | | --- | --- | --- | | `pb-0123456789abcdef0` | Yes | `Default` | | `pb-9876543210abcdef0` | No | `DEV` | The general process to scan or install patches using Run Command, a tool in AWS Systems Manager, and Patch Manager is as follows: 1. **Send a command to patch**: Use the Systems Manager console, SDK, AWS Command Line Interface (AWS CLI), or AWS Tools for Windows PowerShell to send a Run Command task using the document `AWS-RunPatchBaseline`. The diagram shows a Run Command task to patch managed instances by targeting the tag `key=OS,value=Windows`. 1. **Patch baseline determination**: SSM Agent verifies the patch group tags applied to the EC2 instance and queries Patch Manager for the corresponding patch baseline. + **Matching patch group value associated with patch baseline:** 1. SSM Agent, which is installed on EC2 instances in group one, receives the command issued in Step 1 to begin a patching operation. SSM Agent validates that the EC2 instances have the patch group tag-value `DEV` applied and queries Patch Manager for an associated patch baseline. 1. Patch Manager verifies that patch baseline `pb-9876543210abcdef0` has the patch group `DEV` associated and notifies SSM Agent. 1. SSM Agent retrieves a patch baseline snapshot from Patch Manager based on the approval rules and exceptions configured in `pb-9876543210abcdef0` and proceeds to the next step. + **No patch group tag added to instance:** 1. SSM Agent, which is installed on EC2 instances in group two, receives the command issued in Step 1 to begin a patching operation. SSM Agent validates that the EC2 instances don't have a `Patch Group` or `PatchGroup` tag applied and as a result, SSM Agent queries Patch Manager for the default Windows patch baseline. 1. Patch Manager verifies that the default Windows Server patch baseline is `pb-0123456789abcdef0` and notifies SSM Agent. 1. SSM Agent retrieves a patch baseline snapshot from Patch Manager based on the approval rules and exceptions configured in the default patch baseline `pb-0123456789abcdef0` and proceeds to the next step. + **No matching patch group value associated with a patch baseline:** 1. SSM Agent, which is installed on EC2 instances in group three, receives the command issued in Step 1 to begin a patching operation. SSM Agent validates that the EC2 instances have the patch group tag-value `QA` applied and queries Patch Manager for an associated patch baseline. 1. Patch Manager doesn't find a patch baseline that has the patch group `QA` associated. 1. Patch Manager notifies SSM Agent to use the default Windows patch baseline `pb-0123456789abcdef0`. 1. SSM Agent retrieves a patch baseline snapshot from Patch Manager based on the approval rules and exceptions configured in the default patch baseline `pb-0123456789abcdef0` and proceeds to the next step. 1. **Patch scan or install**: After determining the appropriate patch baseline to use, SSM Agent begins either scanning for or installing patches based on the operation value specified in Step 1. The patches that are scanned for or installed are determined by the approval rules and patch exceptions defined in the patch baseline snapshot provided by Patch Manager. **More info** + [Patch compliance state values](patch-manager-compliance-states.md) # Patching applications released by Microsoft on Windows Server Use the information in this topic to help you prepare to patch applications on Windows Server using Patch Manager, a tool in AWS Systems Manager. **Microsoft application patching** Patching support for applications on Windows Server managed nodes is limited to applications released by Microsoft. **Note** In some cases, Microsoft releases patches for applications that don't specify an updated date and time. In these cases, an updated date and time of `01/01/1970` is supplied by default. **Patch baselines to patch applications released by Microsoft** For Windows Server, three predefined patch baselines are provided. The patch baselines `AWS-DefaultPatchBaseline` and `AWS-WindowsPredefinedPatchBaseline-OS` support only operating system updates on the Windows operating system itself. `AWS-DefaultPatchBaseline` is used as the default patch baseline for Windows Server managed nodes unless you specify a different patch baseline. The configuration settings in these two patch baselines are the same. The newer of the two, `AWS-WindowsPredefinedPatchBaseline-OS`, was created to distinguish it from the third predefined patch baseline for Windows Server. That patch baseline, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, can be used to apply patches to both the Windows Server operating system and supported applications released by Microsoft. You can also create a custom patch baseline to update applications released by Microsoft on Windows Server machines. **Support for patching applications released by Microsoft on on-premises servers, edge devices, VMs, and other non-EC2 nodes** To patch applications released by Microsoft on virtual machines (VMs) and other non-EC2 managed nodes, you must turn on the advanced-instances tier. There is a charge to use the advanced-instances tier. **However, there is no additional charge to patch applications released by Microsoft on Amazon Elastic Compute Cloud (Amazon EC2) instances.** For more information, see [Configuring instance tiers](fleet-manager-configure-instance-tiers.md). **Windows update option for "other Microsoft products"** In order for Patch Manager to be able to patch applications released by Microsoft on your Windows Server managed nodes, the Windows Update option **Give me updates for other Microsoft products when I update Windows** must be activated on the managed node. For information about allowing this option on a single managed node, see [Update Office with Microsoft Update](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) on the Microsoft Support website. For a fleet of managed nodes running Windows Server 2016 and later, you can use a Group Policy Object (GPO) to turn on the setting. In the Group Policy Management Editor, go to **Computer Configuration**, **Administrative Templates**, **Windows Components**, **Windows Updates**, and choose **Install updates for other Microsoft products**. We also recommend configuring the GPO with additional parameters that prevent unplanned automatic updates and reboots outside of Patch Manager. For more information, see [Configuring Automatic Updates in a Non-Active Directory Environment](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499) on the Microsoft technical documentation website. For a fleet of managed nodes running Windows Server 2012 or 2012 R2 , you can turn on the option by using a script, as described in [Enabling and Disabling Microsoft Update in Windows 7 via Script](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script) on the Microsoft Docs Blog website. For example, you could do the following: 1. Save the script from the blog post in a file. 1. Upload the file to an Amazon Simple Storage Service (Amazon S3) bucket or other accessible location. 1. Use Run Command, a tool in AWS Systems Manager, to run the script on your managed nodes using the Systems Manager document (SSM document) `AWS-RunPowerShellScript` with a command similar to the following. ``` Invoke-WebRequest ` -Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" ` -Outfile "C:\script.vbs" cscript c:\script.vbs ``` **Minimum parameter requirements** To include applications released by Microsoft in your custom patch baseline, you must, at a minimum, specify the product that you want to patch. The following AWS Command Line Interface (AWS CLI) command demonstrates the minimal requirements to patch a product, such as Microsoft Office 2016. ------ #### [ Linux & macOS ] ``` aws ssm create-patch-baseline \ --name "My-Windows-App-Baseline" \ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ #### [ Windows Server ] ``` aws ssm create-patch-baseline ^ --name "My-Windows-App-Baseline" ^ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ If you specify the Microsoft application product family, each product you specify must be a supported member of the selected product family. For example, to patch the product "Active Directory Rights Management Services Client 2.0," you must specify its product family as "Active Directory" and not, for example, "Office" or "SQL Server." The following AWS CLI command demonstrates a matched pairing of product family and product. ------ #### [ Linux & macOS ] ``` aws ssm create-patch-baseline \ --name "My-Windows-App-Baseline" \ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ #### [ Windows Server ] ``` aws ssm create-patch-baseline ^ --name "My-Windows-App-Baseline" ^ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]" ``` ------ **Note** If you receive an error message about a mismatched product and family pairing, see [Issue: mismatched product family/product pairs](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch) for help resolving the issue.