Changed structure of Troubleshoot document. Updated overview page

Author: ApnaLakshay

articles/virtual-machines/maintenance-configurations.md

@@ -57,21 +57,23 @@ This scope is integrated with [Update Manager](../update-center/overview.md), wh
 - The upper maintenance window is 3 hours 55 mins.
 - A minimum of 1 hour and 30 minutes is required for the maintenance window.
 - The value of **Repeat** should be at least 6 hours.
-- The start time for a schedule should be at least 10 minutes after the schedule's creation time.
+- The start time for a schedule should be at least 15 minutes after the schedule's creation time.
 
 >[!NOTE]
 > 1. The minimum maintenance window has been increased from 1 hour 10 minutes to 1 hour 30 minutes, while the minimum repeat value has been set to 6 hours for new schedules. **Please note that your existing schedules will not get impacted; however, we strongly recommend updating existing schedules to include these new changes.**
 > 2. The count of characters of Resource Group name along with Maintenance Configuration name should be less than 128 characters
 
-In rare cases if platform catchup host update window happens to coincide with the guest (VM) patching window and if the guest patching window don't get sufficient time to execute after host update then the system would show **Schedule timeout, waiting for an ongoing update to complete the resource** error since only a single update is allowed by the platform at a time. 
+Maintenance Configuration provides two scheduled patching modes for In-guest VMs: Static Mode and [Dynamic Scope](../update-manager/dynamic-scope-overview.md) Mode. By default, the system operates in Static Mode if no Dynamic Scope Mode is configured. To schedule or modify the maintenance configuration in either mode, a buffer of 15 minutes prior to the scheduled patch time is required. For instance, if the patch is scheduled for 3PM, all modifications, including adding or removing VMs, altering the dynamic scope etc., should be finalized by 2:45PM.
 
 To learn more about this topic, checkout [Update Manager and scheduled patching](../update-center/scheduled-patching.md)
 
 > [!IMPORTANT]
 > If you move a resource to a different resource group or subscription, then scheduled patching for the resource stops working as this scenario is currently unsupported by the system. The team is working to provide this capability but in the meantime, as a workaround, for the resource you want to move (in static scope)
+>
 > 1. You need to remove the assignment of it
 > 2. Move the resource to a different resource group or subscription
 > 3. Recreate the assignment of it
+>
 > In the dynamic scope, the steps are similar, but after removing the assignment in step 1, you simply need to initiate or wait for the next scheduled run. This action prompts the system to completely remove the assignment, enabling you to proceed with steps 2 and 3.
 > If you forget/miss any one of the above mentioned steps, you can reassign the resource to original assignment and repeat the steps again sequentially.
 
@@ -117,4 +119,5 @@ The following are the Dynamic Scope recommended limits for **each dynamic scope*
 
 ## Next steps
 
-To learn more, see [Maintenance and updates](maintenance-and-updates.md).
+To troubleshoot issues, see [Troubleshoot Maintenance Configurations](troubleshoot-maintenance-configurations.md)
+To learn more, see [Maintenance and updates](maintenance-and-updates.md)

articles/virtual-machines/troubleshoot-maintenance-configurations.md

@@ -11,87 +11,133 @@ ms.author: lnagpal
 
 # Troubleshoot issues with Maintenance Configurations
 
-This article describes the open and fixed issues that might occur when you use Maintenance Configurations, their scope and their mitigation steps.
+This article outlines common errors that may arise during the deployment or utilization of Maintenance Configuration for Scheduled Patching, along with strategies to address them effectively.
 
-## Fixed Issues
+### Shutdown and Unresponsive VM when using `dynamic` scope in Guest Maintenance 
 
-#### Shutdown and Unresponsive VM in Guest Maintenance Scope
+#### Issue
+Scheduled patching doesn't install the patches on the VMs and gives an error `ShutdownOrUnresponsive`
 
-#####  Dynamic Scope
+#### Resolution
+It takes 12 hours to complete the cleanup process for the maintenance configuration assignment so make sure to keep the buffer of 12 hours before recreating the VM with the same name. 
+If a new VM is recreated with the same name before the cleanup, Maintenance Configuration service will be unable to trigger the schedule.
 
-It takes 12 hours to complete the cleanup process for the maintenance configuration assignment. If a new VM is recreated with the same name before the cleanup, the backend service is unable to trigger the schedule.
+### Shutdown and Unresponsive VM when using `static` scope in Guest Maintenance 
 
-##### Static Scope
+#### Issue
+Scheduled patching doesn't install the patches on the VMs and gives an error `ShutdownOrUnresponsive`
 
-Ensure that the VM is up and running. If the VM was indeed up and running, and the issue persists, verify whether the VM was recreated with the same name within a 12-hour window. If so, delete all configuration assignments associated with the recreated VM and then proceed to recreate the assignments.
+#### Resolution
+In a static scope, it's crucial for customers to avoid relying on outdated VM configurations. Instead, they should prioritize re-assigning configurations after recreating instances.
 
-#### Failed to create dynamic scope due to RBAC
+### Schedule Patching stops working after the resource is moved
 
+#### Issue
+If a resource is moved to a different resource group or subscription, then scheduled patching for the resource stops working.
+
+#### Resolution 
+Resource move or Maintenance Configuration move capability across resource group or subscription is currently unsupported by the system. The team is working to provide this capability but in the meantime, as a workaround, for the resource you want to move (in static scope)
+
+1. You need to remove the assignment of it
+2. Move the resource to a different resource group or subscription
+3. Recreate the assignment of it
+
+In the dynamic scope, the steps are similar, but after removing the assignment in step 1, you simply need to initiate or wait for the next scheduled run. This action prompts the system to completely remove the assignment, enabling you to proceed with steps 2 and 3.
+
+If you forget/miss any one of the above mentioned steps, you can reassign the resource to original assignment and repeat the steps again sequentially.
+
+### Dynamic Scope creation fails
+
+#### Issue
+Failed to create dynamic scope due to RBAC
+
+#### Resolution
 In order to create a dynamic scope, user must have the permission at the subscription level or at a resource group level. Refer to the [list of permissions list for different resources](../update-manager/overview.md#permissions) for more details.
 
-#### Apply Update stuck and Update not progressing
+### Apply Update stuck and Update not progressing
+
+#### Issue
 **Applies to:** :heavy_check_mark: Dedicated Hosts :heavy_check_mark: VMs 
+User initiated update stuck for long time and update is not progressing
+
+#### Resolution
+If a resource is redeployed to a different cluster, and a pending update request is created using the old cluster value, the request becomes stuck indefinitely. If the status of the apply update operation is closed/not found, then retry after 120 hours. If the issue persist, contact the support team for further mitigation.
+
+### Dedicated host updates even after Maintenance Configuration is attached
 
-If a resource is redeployed to a different cluster, and a pending update request is created using the old cluster value, the request becomes stuck indefinitely. If a request is stuck for an extended period (more than 300 minutes), contact the  support team for further mitigation.
+#### Issue
+Dedicated Host update not blocked by Maintenance Configuration and it gets updated even after maintenance configuration is attached
 
-#### Dedicated host update even after Maintenance Configuration is attached
+#### Resolution
+If a Dedicated Host is recreated with the same name, Maintenance Configuration service retains the old Dedicated Host ID, preventing it from blocking updates. Customers can resolve this issue by removing the Maintenance Configuration and reassigning it. If the issue persists, reach out to the support team for further assistance.
 
-If a Dedicated Host is recreated with the same name, the backend retains the old Dedicated Host ID, preventing it from blocking updates. Customers can resolve this issue by removing the maintenance configuration and reassigning it for mitigation. If the issue persists, reach out to the support team for further assistance.
+### Install patch operation fails for invalid classification type
 
-#### Install patch operation failed due to invalid classification type in Maintenance Configuration
+#### Issue
+Install patch operation failed due to invalid classification type in Maintenance Configuration
 
+#### Resolution
 Due to a previous bug, the system patch operation couldn't perform validation, and an invalid classification type was found in the Maintenance Configuration. The bug has been fixed and deployed. To address this issue, customers can update the Maintenance Configuration and set the correct classification type.
 
-## Open Issues
+### Schedule didn't trigger
 
-#### Schedule Patching stops working after the resource is moved
+#### Issue
+If a resource has two maintenance configurations with the same trigger time and an install patch configuration, and both are assigned to the same VM/resource, only one maintenance configuration triggers.
 
-If you move a resource to a different resource group or subscription, then scheduled patching for the resource stops working as this scenario is currently unsupported by the system. The team is working to provide this capability but in the meantime, as a workaround, for the resource you want to move (in static scope)
-1. You need to remove the assignment of it
-2. Move the resource to a different resource group or subscription
-3. Recreate the assignment of it
-In the dynamic scope, the steps are similar, but after removing the assignment in step 1, you simply need to initiate or wait for the next scheduled run. This action prompts the system to completely remove the assignment, enabling you to proceed with steps 2 and 3.
+#### Resolution
+Please modify the start time of one of the maintenance configurations to mitigate the issue. It's a known system limitation due to which Maintenance Configuration is unable to identify which maintenance configuration triggers. The team is working on solving this limitation. 
 
-If you forget/miss any one of the above mentioned steps, you can reassign the resource to original assignment and repeat the steps again sequentially.
+### Unable to create dynamic scope (at Resource Group Level)
 
-#### Schedule didn't trigger
+#### Issue
+Dynamic scope validation fails due to a null value in the location
 
-If a resource has two maintenance configurations with the same trigger time and an install patch configuration, and both are assigned to the same VM/resource, only one policy triggers. This is a known bug, and it's rarely observed. To mitigate this issue, adjust the start time of the maintenance configuration.
+#### Resolution
+Due to this issue in dynamic scope validation, it results in regression in the validation process. We recommend that customers provide the required set of locations for resource group-level dynamic scope.
 
-#### Unable to create dynamic scope (at Resource Group Level)
+### Dynamic Scope not executed and no resources patched
 
-Dynamic scope validation fails due to a null value in the location, resulting in a regression in the validation process. We recommend that customers provide the required set of locations for resource group-level dynamic scope.
+#### Issue
+Dynamic scope flattening failed due to throttling, and the service is unable to determine the list of VMs associated with VM.
 
-#### Dynamic Scope not executed
+#### Resolution
+This issue might be occurring due to the number of subscriptions per dynamic scope that should be less than 30. Refer to this [page](../virtual-machines/maintenance-configurations.md#service-limits) for more details on the service limits of Dynamic Scoping 
 
-If in your maintenance schedule, dynamic schedule isn't evaluated and no machines are patched then this error might be occurring due to the number of subscriptions per dynamic scope that should be less than 30. Dynamic scope flattening failed due to throttling, and the service is unable to determine the list of VMs associated with VM.  Refer to this [page](../virtual-machines/maintenance-configurations.md#service-limits) for more details on the service limits of Dynamic Scoping 
+### Dedicated host configuration assignment not cleaned up after Dedicated Host removal
 
-#### Dedicated host configuration assignment not cleaned up after Dedicated Host removal
+#### Issue
+After deleting the dedicated hosts, configuration assignments attached to dedicated hosts still exists.
 
-Before deleting a dedicated host, make sure to delete the maintenance configuration associated with it. If the dedicated host is deleted but still appears on the portal, reach out to the support team. Cleanup processes are currently in place for dedicated hosts, ensuring no impact on customers as the dedicated host no longer exists.
+#### Resolution
+Before deleting a dedicated host, make sure to delete the maintenance configuration associated with it. If the dedicated host is deleted but still appears on the portal, reach out to the support team. Cleanup processes are currently in place for dedicated hosts, ensuring no impact on customers.
 
-#### Maintenance Configuration recreated with the same name and old dynamic scope appeared on portal
+### Unable to provide Multiple tag values for dynamic scope
 
-After deleting the maintenance configuration, the system performs cleanup of all associations (static as well as dynamic). However, due to a regression from the backend, the backend system is unable to delete the dynamic scope from ARG. The portal displays configurations using ARG, and old configurations may be visible. Stale configurations in ARG will automatically be purged after 60 hours. The backend doesn't utilize any stale dynamic scope.
+#### Issue
+Portal users might not be able to provide multiple tag values for dynamic scope
 
-#### Unable to provide Multiple tag values for dynamic scope
+#### Resolution
+This is a currently known limitation on the portal. The team is working on making this feature accessible on the portal as well but in the meantime, customers can use CLI/PowerShell to create dynamic scope. The system accepts multiple values for tag using CLI/PowerShell option.
 
-This is a currently know limitation on the portal. The team is working on making this feature accessible on the portal as well but in the meantime, customers can use CLI/PowerShell to create dynamic scope. The system accepts multiple values for tag using CLI/PowerShell option.
+### Maintenance Configuration triggered again with older trigger time
 
-#### Unable to remove tag from maintenance configuration
+#### Issue
+Maintenance Configuration executed again with the older trigger time, after the update
 
-This is a known bug in the backend system where the customer is unable to remove tag from Maintenance Configuration. The mitigation is to remove all tags and then update the maintenance configuration. Then you can add all the previous tags defined. Removal of a single tag isn't working due to regression.
+#### Resolution 
+There's a known issue in Maintenance Schedule related to the caching of old maintenance policies. If an old policy is cached and the new policy processing is moved to a new instance, the old machine may trigger the schedule with the outdated start time. It's recommended to update the Maintenance Configuration at least 1 hour before. If the issue persists, reach out to support team for further assistance.
 
-#### Maintenance Configuration executes twice after policy updates (Policy trigger with old trigger time)
+### Schedule timeout, waiting for an ongoing update to complete the resource
 
-There's a known issue in Maintenance Schedule related to the caching of old maintenance policies. If an old policy is cached and the new policy processing is moved to a new instance, the old machine may trigger the schedule with the outdated start time.
-It's recommended to update the Maintenance Configuration at least 1 hour before. If the issue persists, reach out to support team for further assistance.
+#### Issue
+Maintenance configuration timeout due to the host update window coinciding with the guest (VM) patching window
 
-## Unsupported
+#### Resolution
+In rare cases if platform catchup host update window happens to coincide with the guest (VM) patching window and if the guest patching window don't get sufficient time to execute after host update then the system would show **Schedule timeout, waiting for an ongoing update to complete the resource** error since only a single update is allowed by the platform at a time. 
 
-#### Unimplemented APIs
+### Unimplemented APIs
 
-Following is the list of APIs that aren't yet implemented and we are in the process of implementing it in the next few days
+Following is the list of APIs that aren't yet supported.
 + Get Apply Update at Subscription Level
 + Get Apply Update at Resource Group Level.
 + Get Pending Update at Subscription Level