Merge pull request #228930 from mimckitt/upgrade-policy-vmss

JamesJBarnett · web-flow · commit 535736808a99 · 2023-05-12T13:05:24.000-07:00
Upgrade Policies for Virtual Machine Scale Sets
diff --git a/articles/chaos-studio/troubleshooting.md b/articles/chaos-studio/troubleshooting.md
@@ -84,7 +84,7 @@ You can upgrade your Virtual Machine Scale Sets instances with Azure CLI:
     az vmss update-instances --resource-group myResourceGroup --name myScaleSet --instance-ids {instanceIds}
     ```
 
-For more information, see [How to bring VMs up-to-date with the latest scale set model](../virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model)
+For more information, see [How to bring VMs up-to-date with the latest scale set model](../virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-policy.md)
 
 ### AKS Chaos Mesh faults fail
 AKS Chaos Mesh faults may fail for various reasons related to missing prerequisites:
diff --git a/articles/load-balancer/load-balancer-nat-pool-migration.md b/articles/load-balancer/load-balancer-nat-pool-migration.md
@@ -39,7 +39,7 @@ The migration process will create a new Backend Pool for each Inbound NAT Pool e
 ### Prerequisites 
 
 * In order to migrate a Load Balancer's NAT Pools to NAT Rules, the Load Balancer SKU must be 'Standard'. To automate this upgrade process, see the steps provided in [Upgrade a basic load balancer used with Virtual Machine Scale Sets](upgrade-basic-standard-virtual-machine-scale-sets.md).
-* Virtual Machine Scale Sets associated with the target Load Balancer must use either a 'Manual' or 'Automatic' upgrade policy--'Rolling' upgrade policy is not supported. For more information, see [Virtual Machine Scale Sets Upgrade Policies](../virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model)
+* Virtual Machine Scale Sets associated with the target Load Balancer must use either a 'Manual' or 'Automatic' upgrade policy--'Rolling' upgrade policy is not supported. For more information, see [Virtual Machine Scale Sets Upgrade Policies](../virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-policy.md)
 * Install the latest version of [PowerShell](/powershell/scripting/install/installing-powershell)
 * Install the [Azure PowerShell modules](/powershell/azure/install-azure-powershell)
 
diff --git a/articles/virtual-machine-scale-sets/TOC.yml b/articles/virtual-machine-scale-sets/TOC.yml
@@ -124,6 +124,8 @@
       href: azure-hybrid-benefit-linux.md
 - name: Management
   items: 
+  - name: Manage Upgrade Policies
+    href: virtual-machine-scale-sets-upgrade-policy.md
   - name: Common management tasks
     items:
     - name: Use the Azure CLI
diff --git a/articles/virtual-machine-scale-sets/azure-hybrid-benefit-linux.md b/articles/virtual-machine-scale-sets/azure-hybrid-benefit-linux.md
@@ -103,7 +103,7 @@ az vmss update -g myResourceGroup -n myVmName --license-type None
 ```
 
 >[!NOTE]
-> Scale sets have an [upgrade policy](./virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model) that determines how virtual machines are brought up to date with the latest scale set model. 
+> Scale sets have an [upgrade policy](./virtual-machine-scale-sets-upgrade-policy.md) that determines how virtual machines are brought up to date with the latest scale set model. 
 >
 > If your scale sets have an **Automatic** upgrade policy, Azure Hybrid Benefit will be applied automatically as virtual machines are updated. If your scale sets have a **Rolling** upgrade policy, based on the scheduled updates, Azure Hybrid Benefit will be applied. 
 >
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-instance-repairs.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-instance-repairs.md
@@ -153,7 +153,7 @@ The above example uses an existing load balancer and health probe for monitoring
 
 Before enabling automatic repairs policy in an existing scale set, ensure that all the [requirements](#requirements-for-using-automatic-instance-repairs) for opting in to this feature are met. The application endpoint should be correctly configured for scale set instances to avoid triggering unintended repairs while the endpoint is getting configured. To enable the automatic instance repair in a scale set, use *automaticRepairsPolicy* object in the Virtual Machine Scale Set model.
 
-After updating the model of an existing scale set, ensure that the latest model is applied to all the instances of the scale. Refer to the instruction on [how to bring VMs up-to-date with the latest scale set model](./virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model).
+After updating the model of an existing scale set, ensure that the latest model is applied to all the instances of the scale. Refer to the instruction on [how to bring VMs up-to-date with the latest scale set model](./virtual-machine-scale-sets-upgrade-policy.md).
 
 ### Azure portal
 
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade.md
@@ -126,7 +126,7 @@ The following platform SKUs are currently supported (and more are added periodic
 ### Service Fabric requirements
 
 If you are using Service Fabric, ensure the following conditions are met:
--	Service Fabric [durability level](../service-fabric/service-fabric-cluster-capacity.md#durability-characteristics-of-the-cluster) is Silver or Gold. If Service Fabric durability is Bronze, only Stateless-only node types supports automatic OS image upgrades).
+-	Service Fabric [durability level](../service-fabric/service-fabric-cluster-capacity.md#durability-characteristics-of-the-cluster) is Silver or Gold. If Service Fabric durability is Bronze, only Stateless-only node types support automatic OS image upgrades).
 -	The Service Fabric extension on the scale set model definition must have TypeHandlerVersion 1.1 or above.
 -	Durability level should be the same at the Service Fabric cluster and Service Fabric extension on the scale set model definition.
 - An additional health probe or use of application health extension is not required for Silver or Gold durability. Bronze durability with Stateless-only node types requires an additional health probe.
@@ -188,7 +188,7 @@ az vmss update --name myScaleSet --resource-group myResourceGroup --set UpgradeP
 ```
 
 > [!NOTE]
->After configuring automatic OS image upgrades for your scale set, you must also bring the scale set VMs to the latest scale set model if your scale set uses the 'Manual' [upgrade policy](virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model).
+>After configuring automatic OS image upgrades for your scale set, you must also bring the scale set VMs to the latest scale set model if your scale set uses the 'Manual' [upgrade policy](virtual-machine-scale-sets-upgrade-policy.md).
 
 ### ARM templates
 The following example describes how to set automatic OS upgrades on a scale set model via Azure Resource Manager templates (ARM templates):
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-extension-sequencing.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-extension-sequencing.md
@@ -179,7 +179,7 @@ PATCH on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/provider
   }                  
 }
 ```
-Changes to existing scale set instances are applied on the next [upgrade](virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model).
+Changes to existing scale set instances are applied on the next [upgrade](virtual-machine-scale-sets-upgrade-policy.md).
 
 ### Azure PowerShell
 Use the [Add-AzVmssExtension](/powershell/module/az.compute/add-azvmssextension) cmdlet to add the Application Health extension to the scale set model definition. Extension sequencing requires the use of Az PowerShell 1.2.0 or above.
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-health-extension.md
@@ -13,15 +13,20 @@ ms.custom: mimckitt, devx-track-azurepowershell
 
 # Using Application Health extension with Virtual Machine Scale Sets
 
-Monitoring your application health is an important signal for managing and upgrading your deployment. Azure Virtual Machine Scale Sets provide support for [Rolling Upgrades](virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model) including [Automatic OS-Image Upgrades](virtual-machine-scale-sets-automatic-upgrade.md) and [Automatic VM Guest Patching](../virtual-machines/automatic-vm-guest-patching.md), which rely on health monitoring of the individual instances to upgrade your deployment. You can also use Application Health Extension to monitor the application health of each instance in your scale set and perform instance repairs using [Automatic Instance Repairs](virtual-machine-scale-sets-automatic-instance-repairs.md).
+> [!IMPORTANT]
+> **Rich Health States** is currently in public preview. **Binary Health States** is generally available.
+> This preview version is provided without a service-level agreement, and we don't recommend it for production workloads. Certain features might not be supported or might have constrained capabilities. 
+> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
+
+Monitoring your application health is an important signal for managing and upgrading your deployment. Azure Virtual Machine Scale Sets provide support for [Rolling Upgrades](virtual-machine-scale-sets-upgrade-policy.md) including [Automatic OS-Image Upgrades](virtual-machine-scale-sets-automatic-upgrade.md) and [Automatic VM Guest Patching](../virtual-machines/automatic-vm-guest-patching.md), which rely on health monitoring of the individual instances to upgrade your deployment. You can also use Application Health Extension to monitor the application health of each instance in your scale set and perform instance repairs using [Automatic Instance Repairs](virtual-machine-scale-sets-automatic-instance-repairs.md).
 
 This article describes how you can use the two types of Application Health extension, **Binary Health States** or **Rich Health States**, to monitor the health of your applications deployed on Virtual Machine Scale Sets.
 
 ## Prerequisites
 
 This article assumes that you're familiar with:
 -	Azure virtual machine [extensions](../virtual-machines/extensions/overview.md)
--	[Modifying](virtual-machine-scale-sets-upgrade-scale-set.md) Virtual Machine Scale Sets
+-	[Modifying](virtual-machine-scale-sets-upgrade-policy.md) Virtual Machine Scale Sets
 
 > [!CAUTION]
 > Application Health Extension expects to receive a consistent probe response at the configured port `tcp` or request path `http/https` in order to label a VM as *Healthy*. If no application is running on the VM, or you're unable to configure a probe response, your VM is going to show up as *Unhealthy*.
@@ -133,7 +138,7 @@ This state only applies to Rich Health States. The *Unknown* state is only repor
 
 An instance in an *Unknown* state is treated similar to an *Unhealthy* instance. If enabled, instance repairs will be carried out on an *Unknown* instance while rolling upgrades will be paused until the instance falls back into a *Healthy* state.
 
-The following table shows the health status interpretation for [Rolling Upgrades](virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model) and [Instance Repairs](virtual-machine-scale-sets-automatic-instance-repairs.md): 
+The following table shows the health status interpretation for [Rolling Upgrades](virtual-machine-scale-sets-upgrade-policy.md) and [Instance Repairs](virtual-machine-scale-sets-automatic-instance-repairs.md): 
 
 | Health State | Rolling Upgrade interpretation | Instance Repairs trigger |
 | ------------ | ------------------------------ | ------------------------ |
@@ -288,6 +293,7 @@ Update extension functionality is currently not available on PowerShell. To swit
 
 The following example adds the Application Health extension to the `extensionProfile` in the scale set model of a Windows-based scale set. The example uses the new Az PowerShell module.
 
+
 ```azurepowershell-interactive
 # Define the scale set variables
 $vmScaleSetName = "myVMScaleSet"
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-instance-protection.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-instance-protection.md
@@ -15,7 +15,7 @@ ms.custom: avverma
 > [!NOTE]
 > This document covers Virtual Machine Scale Sets using Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for Virtual Machine Scale Sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).
 
-Azure Virtual Machine Scale Sets enable better elasticity for your workloads through [Autoscale](virtual-machine-scale-sets-autoscale-overview.md), so you can configure when your infrastructure scales-out and when it scales-in. Scale sets also enable you to centrally manage, configure, and update a large number of VMs through different [upgrade policy](virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model) settings. You can configure an update on the scale set model and the new configuration is applied automatically to every scale set instance if you've set the upgrade policy to Automatic or Rolling.
+Azure Virtual Machine Scale Sets enable better elasticity for your workloads through [Autoscale](virtual-machine-scale-sets-autoscale-overview.md), so you can configure when your infrastructure scales-out and when it scales-in. Scale sets also enable you to centrally manage, configure, and update a large number of VMs through different [upgrade policy](virtual-machine-scale-sets-upgrade-policy.md) settings. You can configure an update on the scale set model and the new configuration is applied automatically to every scale set instance if you've set the upgrade policy to Automatic or Rolling.
 
 As your application processes traffic, there can be situations where you want specific instances to be treated differently from the rest of the scale set instance. For example, certain instances in the scale set could be performing long-running operations, and you don't want these instances to be scaled-in until the operations complete. You might also have specialized a few instances in the scale set to perform additional or different tasks than the other members of the scale set. You require these 'special' VMs not to be modified with the other instances in the scale set. Instance protection provides the additional controls to enable these and other scenarios for your application.
 
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-mvss-start.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-mvss-start.md
@@ -121,7 +121,7 @@ The scale set needs to know what size of VM to create ("sku name") and how many
 ```
 
 ### Choose type of updates
-The scale set also needs to know how to handle updates on the scale set. Currently, there are three options, `Manual`, `Rolling` and `Automatic`. For more information on the differences between the two, see the documentation on [how to upgrade a scale set](./virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model).
+The scale set also needs to know how to handle updates on the scale set. Currently, there are three options, `Manual`, `Rolling` and `Automatic`. For more information on the differences between the two, see the documentation on [how to upgrade a scale set](./virtual-machine-scale-sets-upgrade-policy.md).
 
 ```json
        "properties": {
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-terminate-notification.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-terminate-notification.md
@@ -67,7 +67,7 @@ PUT on `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/provi
 
 The above block specifies a timeout delay of 5 minutes (as indicated by *PT5M*) for any terminate operation on all instances in your scale set. The field *notBeforeTimeout* can take any value between 5 and 15 minutes in ISO 8601 format. You can change the default timeout for the terminate operation by modifying the *notBeforeTimeout* property under *terminateNotificationProfile* described above.
 
-After enabling *scheduledEventsProfile* on the scale set model and setting the *notBeforeTimeout*, update the individual instances to the [latest model](virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model) to reflect the changes.
+After enabling *scheduledEventsProfile* on the scale set model and setting the *notBeforeTimeout*, update the individual instances to the [latest model](virtual-machine-scale-sets-upgrade-policy.md) to reflect the changes.
 
 > [!NOTE]
 >Terminate notifications on scale set instances can only be enabled with API version 2019-03-01 and above
@@ -98,7 +98,7 @@ Update-AzVmss `
 ```
 The above example enables terminate notifications on an existing scale set and sets a 15-minute timeout for the terminate event.
 
-After enabling scheduled events on the scale set model and setting the timeout, update the individual instances to the [latest model](virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model) to reflect the changes.
+After enabling scheduled events on the scale set model and setting the timeout, update the individual instances to the [latest model](virtual-machine-scale-sets-upgrade-policy.md) to reflect the changes.
 
 ### Azure CLI 2.0
 
@@ -199,7 +199,7 @@ If you're not getting any **Terminate** events through Scheduled Events, then ch
 >'http://169.254.169.254/metadata/scheduledevents?api-version=2019-01-01'
 
 ### Getting Terminate event with incorrect NotBefore time  
-After enabling *scheduledEventsProfile* on the scale set model and setting the *notBeforeTimeout*, update the individual instances to the [latest model](virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model) to reflect the changes.
+After enabling *scheduledEventsProfile* on the scale set model and setting the *notBeforeTimeout*, update the individual instances to the [latest model](virtual-machine-scale-sets-upgrade-policy.md) to reflect the changes.
 
 ## Next steps
 Learn how to [deploy your application](virtual-machine-scale-sets-deploy-app.md) on Virtual Machine Scale Sets.
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-policy.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-policy.md
diff --git a/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set.md b/articles/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set.md
diff --git a/articles/virtual-machines/capacity-reservation-associate-virtual-machine-scale-set.md b/articles/virtual-machines/capacity-reservation-associate-virtual-machine-scale-set.md
diff --git a/articles/virtual-machines/capacity-reservation-remove-virtual-machine-scale-set.md b/articles/virtual-machines/capacity-reservation-remove-virtual-machine-scale-set.md

Original file line number	Diff line number	Diff line change
`@@ -103,7 +103,7 @@ az vmss update -g myResourceGroup -n myVmName --license-type None`
`103`	`103`	```
`104`	`104`
`105`	`105`	`>[!NOTE]`
`106`		`-> Scale sets have an [upgrade policy](./virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model) that determines how virtual machines are brought up to date with the latest scale set model.`
	`106`	`+> Scale sets have an [upgrade policy](./virtual-machine-scale-sets-upgrade-policy.md) that determines how virtual machines are brought up to date with the latest scale set model.`
`107`	`107`	`>`
`108`	`108`	`> If your scale sets have an Automatic upgrade policy, Azure Hybrid Benefit will be applied automatically as virtual machines are updated. If your scale sets have a Rolling upgrade policy, based on the scheduled updates, Azure Hybrid Benefit will be applied.`
`109`	`109`	`>`
Original file line number	Diff line number	Diff line change
@@ -179,7 +179,7 @@ PATCH on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/provider
`179`	`179`	`}`
`180`	`180`	`}`
`181`	`181`	```
`182`		`-Changes to existing scale set instances are applied on the next [upgrade](virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model).`
	`182`	`+Changes to existing scale set instances are applied on the next [upgrade](virtual-machine-scale-sets-upgrade-policy.md).`
`183`	`183`
`184`	`184`	`### Azure PowerShell`
`185`	`185`	`Use the [Add-AzVmssExtension](/powershell/module/az.compute/add-azvmssextension) cmdlet to add the Application Health extension to the scale set model definition. Extension sequencing requires the use of Az PowerShell 1.2.0 or above.`