Merge pull request #258015 from ju-shim/ext

automatic-extension-upgrade FRESHNESS

Author: prmerger-automator[bot]

articles/virtual-machines/automatic-extension-upgrade.md

@@ -6,70 +6,69 @@ ms.subservice: extensions
 ms.workload: infrastructure
 ms.topic: how-to
 ms.reviewer: erd
-ms.date: 12/28/2022
+ms.date: 11/7/2023
 ms.custom: devx-track-azurepowershell
 
 ---
 
 # Automatic Extension Upgrade for VMs and Scale Sets in Azure
 
-**Applies to:** :heavy_check_mark: Linux VMs :heavy_check_mark: Windows VMs :heavy_check_mark: Flexible scale sets :heavy_check_mark: Uniform scale sets
-
 Automatic Extension Upgrade is available for Azure VMs and Azure Virtual Machine Scale Sets. When Automatic Extension Upgrade is enabled on a VM or scale set, the extension is upgraded automatically whenever the extension publisher releases a new version for that extension.
 
  Automatic Extension Upgrade has the following features:
 - Supported for Azure VMs and Azure Virtual Machine Scale Sets.
-- Upgrades are applied in an availability-first deployment model (detailed below).
-- For a Virtual Machine Scale Set, no more than 20% of the scale set virtual machines will be upgraded in a single batch. The minimum batch size is one virtual machine.
+- Upgrades are applied in an availability-first deployment model.
+- For a Virtual Machine Scale Set, no more than 20% of the scale set virtual machines upgrades in a single batch. The minimum batch size is one virtual machine.
 - Works for all VM sizes, and for both Windows and Linux extensions.
 - You can opt out of automatic upgrades at any time.
 - Automatic extension upgrade can be enabled on a Virtual Machine Scale Sets of any size.
 - Each supported extension is enrolled individually, and you can choose which extensions to upgrade automatically.
 - Supported in all public cloud regions.
 
 ## How does Automatic Extension Upgrade work?
-The extension upgrade process replaces the existing extension version on a VM with a new version of the same extension when published by the extension publisher. The health of the VM is monitored after the new extension is installed. If the VM is not in a healthy state within 5 minutes of the upgrade completion, the extension version is rolled back to the previous version.
+The extension upgrade process replaces the existing extension version on a VM with a new version of the same extension when published by the extension publisher. The health of the VM is monitored after the new extension is installed. If the VM isn't in a healthy state within 5 minutes of the upgrade completion, the extension version is rolled back to the previous version.
 
 A failed extension update is automatically retried. A retry is attempted every few days automatically without user intervention.
 
 ### Availability-first Updates
 The availability-first model for platform orchestrated updates ensures that availability configurations in Azure are respected across multiple availability levels.
 
-For a group of virtual machines undergoing an update, the Azure platform will orchestrate updates:
+For a group of virtual machines undergoing an update, the Azure platform orchestrates updates:
 
 **Across regions:**
-- An update will move across Azure globally in a phased manner to prevent Azure-wide deployment failures.
+- An update moves across Azure globally in a phased manner to prevent Azure-wide deployment failures.
 - A 'phase' can have one or more regions, and an update moves across phases only if eligible VMs in the previous phase update successfully.
-- Geo-paired regions will not be updated concurrently and cannot be in the same regional phase.
+- Geo-paired regions won't be updated concurrently and can't be in the same regional phase.
 - The success of an update is measured by tracking the health of a VM post update. VM health is tracked through platform health indicators for the VM. For Virtual Machine Scale Sets, the VM health is tracked through application health probes or the Application Health extension, if applied to the scale set.
 
 **Within a region:**
-- VMs in different Availability Zones are not updated concurrently with the same update.
-- Single VMs that are not part of an availability set are batched on a best effort basis to avoid concurrent updates for all VMs in a subscription.  
+- VMs in different Availability Zones aren't updated concurrently with the same update.
+- Single VMs that aren't part of an availability set are batched on a best effort basis to avoid concurrent updates for all VMs in a subscription.  
 
 **Within a 'set':**
-- All VMs in a common availability set or scale set are not updated concurrently.  
-- VMs in a common availability set are updated within Update Domain boundaries and VMs across multiple Update Domains are not updated concurrently.  
+- All VMs in a common availability set or scale set aren't updated concurrently.  
+- VMs in a common availability set are updated within Update Domain boundaries and VMs across multiple Update Domains aren't updated concurrently.  
 - VMs in a common virtual machine scale set are grouped in batches and updated within Update Domain boundaries.
 
 ### Upgrade process for Virtual Machine Scale Sets
-1. Before beginning the upgrade process, the orchestrator will ensure that no more than 20% of VMs in the entire scale set are unhealthy (for any reason).
+1. Before the upgrade process starts, the orchestrator ensures that no more than 20% of VMs in the entire scale set are unhealthy (for any reason).
 
 2. The upgrade orchestrator identifies the batch of VM instances to upgrade. An upgrade batch can have a maximum of 20% of the total VM count, subject to a minimum batch size of one virtual machine.
 
-3. For scale sets with configured application health probes or Application Health extension, the upgrade waits up to 5 minutes (or the defined health probe configuration) for the VM to become healthy before upgrading the next batch. If a VM does not recover its health after an upgrade, then by default the previous extension version on the VM is reinstalled.
+3. For scale sets with configured application health probes or Application Health extension, the upgrade waits up to 5 minutes (or the defined health probe configuration) for the VM to become healthy before upgrading the next batch. If a VM doesn't recover its health after an upgrade, then by default the previous extension version on the VM is reinstalled.
 
-4. The upgrade orchestrator also tracks the percentage of VMs that become unhealthy after an upgrade. The upgrade will stop if more than 20% of upgraded instances become unhealthy during the upgrade process.
+4. The upgrade orchestrator also tracks the percentage of VMs that become unhealthy after an upgrade. The upgrade stops if more than 20% of upgraded instances become unhealthy during the upgrade process.
 
 The above process continues until all instances in the scale set have been upgraded.
 
-The scale set upgrade orchestrator checks for the overall scale set health before upgrading every batch. While upgrading a batch, there could be other concurrent planned or unplanned maintenance activities that could impact the health of your scale set virtual machines. In such cases, if more than 20% of the scale set's instances become unhealthy, then the scale set upgrade stops at the end of current batch.
+The scale set upgrade orchestrator checks for the overall scale set health before upgrading every batch. During a batch upgrade, there could be other concurrent planned or unplanned maintenance activities that could impact the health of your scale set virtual machines. In such cases, if more than 20% of the scale set's instances become unhealthy, then the scale set upgrade stops at the end of current batch.
 
 ## Supported extensions
 Automatic Extension Upgrade supports the following extensions (and more are added periodically):
 - [Azure Automation Hybrid Worker extension](../automation/extension-based-hybrid-runbook-worker-install.md) - Linux and Windows
 - Dependency Agent – [Linux](./extensions/agent-dependency-linux.md) and [Windows](./extensions/agent-dependency-windows.md)
 - [Application Health Extension](../virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension.md) – Linux and Windows
+- [Guest Attestation Extension](../virtual-machines/boot-integrity-monitoring-overview.md) - Linux and Windows
 - [Guest Configuration Extension](./extensions/guest-configuration.md) – Linux and Windows
 - Key Vault – [Linux](./extensions/key-vault-linux.md) and [Windows](./extensions/key-vault-windows.md)
 - [Azure Monitor Agent](../azure-monitor/agents/azure-monitor-agent-overview.md)
@@ -83,7 +82,7 @@ Automatic Extension Upgrade supports the following extensions (and more are adde
 To enable Automatic Extension Upgrade for an extension, you must ensure the property `enableAutomaticUpgrade` is set to `true` and added to every extension definition individually.
 
 ### REST API for Virtual Machines
-To enable automatic extension upgrade for an extension (in this example the Dependency Agent extension) on an Azure VM, use the following:
+To enable automatic extension upgrade for an extension (in this example the Dependency Agent extension) on an Azure VM, use the following call:
 
 ```
 PUT on `/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/virtualMachines/<vmName>/extensions/<extensionName>?api-version=2019-12-01`
@@ -105,7 +104,7 @@ PUT on `/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/provi
 ```
 
 ### REST API for Virtual Machine Scale Sets
-Use the following to add the extension to the scale set model:
+Use the following call to add the extension to the scale set model:
 
 ```
 PUT on `/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/virtualMachineScaleSets/<vmssName>?api-version=2019-12-01`
@@ -195,7 +194,7 @@ az vmss extension set \
 
 A VM or Virtual Machine Scale Set can have multiple extensions with automatic extension upgrade enabled. The same VM or scale set can also have other extensions without automatic extension upgrade enabled.  
 
-If multiple extension upgrades are available for a virtual machine, the upgrades may be batched together, but each extension upgrade is applied individually on a virtual machine. A failure on one extension does not impact the other extension(s) that may be upgrading. For example, if two extensions are scheduled for an upgrade, and the first extension upgrade fails, the second extension will still be upgraded.
+If multiple extension upgrades are available for a virtual machine, the upgrades may be batched together, but each extension upgrade is applied individually on a virtual machine. A failure on one extension doesn't impact the other extension(s) that may be upgrading. For example, if two extensions are scheduled for an upgrade, and the first extension upgrade fails, the second extension will still be upgraded.
 
 Automatic Extension Upgrades can also be applied when a VM or virtual machine scale set has multiple extensions configured with [extension sequencing](../virtual-machine-scale-sets/virtual-machine-scale-sets-extension-sequencing.md). Extension sequencing is applicable for the first-time deployment of the VM, and any future extension upgrades on an extension are applied independently.