Merge pull request #239594 from SnehaSudhirG/30May-UMCKnownIssue

added a known issue

Author: v-regandowner

articles/update-center/troubleshoot.md

@@ -2,7 +2,7 @@
 title: Troubleshoot known issues with update management center (preview)
 description: The article provides details on the known issues and troubleshooting any problems with update management center (preview).
 ms.service: update-management-center
-ms.date: 04/21/2022
+ms.date: 05/30/2023
 ms.topic: conceptual
 ms.author: sudhirsneha
 author: SnehaSudhirG
@@ -18,23 +18,23 @@ The following troubleshooting steps apply to the Azure VMs related to the patch
 
 ### Azure Linux VM
 
-To verify if the Microsoft Azure Virtual Machine Agent (VM Agent) is running, has triggered appropriate actions on the machine, and the sequence number for the AutoPatching request, check the agent log for more details in `/var/log/waagent.log`. Every AutoPatching request has a unique sequence number associated with it on the machine. Look for a log similar to: `2021-01-20T16:57:00.607529Z INFO ExtHandler`.
+To verify if the Microsoft Azure Virtual Machine Agent (VM Agent) is running, has triggered appropriate actions on the machine, and the sequence number for the Auto-Patching request, check the agent log for more details in `/var/log/waagent.log`. Every Auto-Patching request has a unique sequence number associated with it on the machine. Look for a log similar to: `2021-01-20T16:57:00.607529Z INFO ExtHandler`.
 
-The package directory for the extension is `/var/lib/waagent/Microsoft.CPlat.Core.Edp.LinuxPatchExtension-<version>` and in the `/status` subfolder is a `<sequence number>.status` file, which includes a brief description of the actions performed during a single AutoPatching request, and the status. It also includes a short list of errors that occurred while applying updates. 
+The package directory for the extension is `/var/lib/waagent/Microsoft.CPlat.Core.Edp.LinuxPatchExtension-<version>` and in the `/status` subfolder is a `<sequence number>.status` file, which includes a brief description of the actions performed during a single Auto-Patching request, and the status. It also includes a short list of errors that occurred while applying updates. 
 
 To review the logs related to all actions performed by the extension, check for more details in `/var/log/azure/Microsoft.CPlat.Core.Edp.LinuxPatchExtension/`. It includes the following two log files of interest:
 
 * `<seq number>.core.log`: Contains details related to the patch actions, such as the patches assessed and installed on the machine, and any issues encountered in the process.
-* `<Date and Time>_<Handler action>.ext.log`: There is a wrapper above the patch action, which is used to manage the extension and invoke specific patch operation. This log contains details about the wrapper. For AutoPatching, the `<Date and Time>_Enable.ext.log` has details on whether the specific patch operation was invoked.
+* `<Date and Time>_<Handler action>.ext.log`: There is a wrapper above the patch action, which is used to manage the extension and invoke specific patch operation. This log contains details about the wrapper. For Auto-Patching, the `<Date and Time>_Enable.ext.log` has details on whether the specific patch operation was invoked.
 
 ### Azure Windows VM 
 
-To verify if the Microsoft Azure Virtual Machine Agent (VM Agent) is running, has triggered appropriate actions on the machine, and the sequence number for the AutoPatching request, check the agent log for more details in `C:\WindowsAzure\Logs\AggregateStatus`. The package directory for the extension is `C:\Packages\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version>`.
+To verify if the Microsoft Azure Virtual Machine Agent (VM Agent) is running, has triggered appropriate actions on the machine, and the sequence number for the Auto-Patching request, check the agent log for more details in `C:\WindowsAzure\Logs\AggregateStatus`. The package directory for the extension is `C:\Packages\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version>`.
 
 To review the logs related to all actions performed by the extension, check for more details in `C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version>`. It includes the following two log files of interest:
 
 * `WindowsUpdateExtension.log`: Contains details related to the patch actions, such as the patches assessed and installed on the machine, and any issues encountered in the process.
-* `CommandExecution.log`: There is a wrapper above the patch action, which is used to manage the extension and invoke specific patch operation. This log contains details about the wrapper. For AutoPatching, the log has details on whether the specific patch operation was invoked.
+* `CommandExecution.log`: There is a wrapper above the patch action, which is used to manage the extension and invoke specific patch operation. This log contains details about the wrapper. For Auto-Patching, the log has details on whether the specific patch operation was invoked.
 
 ### Arc-enabled servers
 
@@ -43,11 +43,26 @@ For Arc-enabled servers, review the [troubleshoot VM extensions](../azure-arc/se
 To review the logs related to all actions performed by the extension, on Windows check for more details in `C:\ProgramData\GuestConfig\extension_Logs\Microsoft.SoftwareUpdateManagement\WindowsOsUpdateExtension`. It includes the following two log files of interest:
 
 * `WindowsUpdateExtension.log`: Contains details related to the patch actions, such as the patches assessed and installed on the machine, and any issues encountered in the process.
-* `cmd_execution_<numeric>_stdout.txt`: There is a wrapper above the patch action, which is used to manage the extension and invoke specific patch operation. This log contains details about the wrapper. For AutoPatching, the log has details on whether the specific patch operation was invoked.
+* `cmd_execution_<numeric>_stdout.txt`: There is a wrapper above the patch action, which is used to manage the extension and invoke specific patch operation. This log contains details about the wrapper. For Auto-Patching, the log has details on whether the specific patch operation was invoked.
 * `cmd_excution_<numeric>_stderr.txt`
 
 ## Known issues
 
+### Scenario: Unable to apply patches for the shutdown machines 
+
+#### Issue
+
+Patches aren’t getting applied for the machines that are in shutdown state, and you may also see that machines are losing their associated maintenance configurations/Schedules.
+
+#### Cause
+
+The machines are in a shutdown state.
+
+### Resolution: 
+
+Keep your machines turned on at least 15 minutes before the scheduled update. For more information, see, [Shut down machines](../virtual-machines/maintenance-configurations.md#shut-down-machines).
+
+
 ### Scenario: Patch run failed with Maintenance window exceeded property showing true even if time remained
 
 #### Issue
@@ -56,12 +71,12 @@ When you view an update deployment in **Update History**, the property **Failed
 
 * No updates are shown.
 * One or more updates are in a **Pending** state.
-* Reboot status is **Required**, but a reboot was not attempted even when the reboot setting passed was `IfRequired` or `Always`.
+* Reboot status is **Required**, but a reboot wasn't attempted even when the reboot setting passed was `IfRequired` or `Always`.
 
 #### Cause
 
-During an update deployment, it checks for maintenance window utilization at multiple steps. Ten minutes of the maintenance window is reserved for reboot at any point. Before getting a list of missing updates or downloading/installing any update (except Windows service pack updates), it checks to verify if there are 15 minutes + 10 minutes for reboot (that is, 25 mins left in the maintenance window). 
-For  Windows service pack updates, we check for 20 minutes + 10 minutes for reboot (that is, 30 minutes). If the deployment doesn't have the sufficient left, it skips the scan/download/install of updates. The deployment run then checks if a reboot is needed and if there is ten minutes left in the maintenance window. If there is, the deployment triggers a reboot, otherwise the reboot is skipped. In such cases, the status is updated to **Failed**, and the Maintenance window exceeded property is updated to ***true**. For cases where the time left is less than 25 minutes, updates are not scanned or attempted for installation. 
+During an update deployment, it checks for maintenance window utilization at multiple steps. 10 minutes of the maintenance window are reserved for reboot at any point. Before getting a list of missing updates or downloading/installing any update (except Windows service pack updates), it checks to verify if there are 15 minutes + 10 minutes for reboot (that is, 25 mins left in the maintenance window). 
+For  Windows service pack updates, we check for 20 minutes + 10 minutes for reboot (that is, 30 minutes). If the deployment doesn't have the sufficient left, it skips the scan/download/install of updates. The deployment run then checks if a reboot is needed and if there's ten minutes left in the maintenance window. If there is, the deployment triggers a reboot, otherwise the reboot is skipped. In such cases, the status is updated to **Failed**, and the Maintenance window exceeded property is updated to ***true**. For cases where the time left is less than 25 minutes, updates aren't scanned or attempted for installation. 
 
 More details can be found by reviewing the logs in the file path provided in the error message of the deployment run.