Merge pull request #10109 from MicrosoftDocs/main

learn-build-service-prod[bot] · web-flow · commit 0014f9c2760a · 2025-11-04T18:05:20.000Z
Auto Publish – main to live - 2025-11-04 18:00 UTC
diff --git a/support/azure/azure-monitor/app-insights/troubleshoot-application-map-issues.md b/support/azure/azure-monitor/app-insights/troubleshoot-application-map-issues.md
@@ -1,10 +1,14 @@
 ---
 title: Troubleshoot Application Map Issues
 description: Provides general recommendations and specific suggestions for Application map issues.
+author: JarrettRenshaw
+ms.author: jarrettr
+manager: dcscontentpm
+ms.topic: troubleshooting
 ms.date: 10/14/2025
 ms.service: azure-monitor
 ms.custom: sap:Application Insights portal experiences
-ms.reviewer: aaronmax, v-weizhu, jarrettr
+ms.reviewer: aaronmax, v-weizhu, jarrettr, v-ryanberg, v-gsitser
 ---
 # Troubleshoot Application map issues
 
@@ -77,5 +81,6 @@ If **Intelligent view** doesn't load, set the configured time frame to six days
 
 If **Intelligent view** takes longer to load than expected, don't select the **Update map components** option. Enable **Intelligent view** only for a single Application Insights resource.
 
-[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)]
+[!INCLUDE [Azure Help Support](~/includes/azure-help-support.md)]
 
+[!INCLUDE [Third-party contact disclaimer](~/includes/third-party-contact-disclaimer.md)]
diff --git a/support/azure/azure-monitor/app-insights/troubleshoot-work-item-integration.md b/support/azure/azure-monitor/app-insights/troubleshoot-work-item-integration.md
@@ -0,0 +1,103 @@
+---
+title: Troubleshoot Work Item Integration Issues in Application Insights
+description: Provides general recommendations and specific suggestions for issues that affect work item integration in Application Insights.
+author: JarrettRenshaw
+ms.author: jarrettr
+manager: dcscontentpm
+ms.topic: troubleshooting
+ms.date: 10/28/2025
+ms.service: azure-monitor
+ms.custom: sap:Application Insights portal experiences
+ms.reviewer: v-ryanberg, v-gsitser
+---
+# Troubleshoot work item integration issues in Application Insights
+
+[Work item integration](/azure/azure-monitor/app/work-item-integration) in Application Insights enables you to create and link work items directly from telemetry data. If this feature isn't working as expected, the following guidance helps you to diagnose and resolve common issues.
+
+## The "Create work item" option doesn't appear in transaction details
+
+If you don't see the option to create a work item, it's likely that integration wasn't enabled or the resource isn't linked to Azure DevOps or GitHub.
+
+**What to do:**
+
+1. In Application Insights, navigate to **Work Items**, and verify that integration settings are configured.
+1. Start the process from the **Create a work item** flow, or use a workbook template.
+
+## On-premises Azure DevOps URL rejected
+
+This issue occurs if the URL format doesn't meet validation requirements.
+
+**What to do:**
+
+* Make sure that the URL uses the HTTPS protocol and matches the validation rule in the workbook parameter.
+* If you're using a self-hosted Azure DevOps instance, make sure that it's accessible from the Azure portal.
+
+## Authorization prompt doesn't appear or linking fails
+
+If you don't see the authorization prompt, or if linking fails, the cause might be a pop-up blocker or cached tokens.
+
+**What to do:**
+
+* Disable pop-up blockers and allow third-party cookies in your browser.
+* Clear your browser cache, and then try again to link.
+* If you're using OAuth, verify that the required scopes are granted.
+
+## Work item creation fails and returns permission errors
+
+Permission errors usually indicate that your account doesn't have sufficient rights in Azure DevOps or GitHub.
+
+**What to do:**
+
+* For Azure DevOps, ensure you have *Contribute* permissions.
+* For GitHub, confirm you have *Write* access to the repository.
+* If you're using a Personal Access Token (PAT), make sure it includes the *Work Items (read/write)* scope.
+
+## Template doesn't load or save
+
+This issue typically occurs because of region limitations or missing permissions.
+
+**What to do:**
+
+* Verify that the region supports the *Microsoft.Insights/workbooks* resource type.
+* Check that the resource provider is registered in your subscription.
+* Assign the *Microsoft.Insights/workbooks/write* role, or try saving the template in a supported region.
+
+## Contextual data is missing from created work items
+
+If the work item doesn't include expected data, the Kusto Query Language (KQL) query might not return the correct schema.
+
+**What to do:**
+
+* Run the query in **Logs** to verify the output fields.
+* Update the query or bindings to match the expected schema.
+
+## Template isn't visible to other users
+
+This issue usually occurs if the template is saved as private, or if role-based access control (RBAC) permissions are insufficient.
+
+**What to do:**
+
+* Make sure that the template is stored in a shared resource group and not saved as *My Reports*.
+* Grant other users at least *Reader* access to the resource.
+
+## Deleting a template doesn't remove existing links
+
+Removing a workbook doesn't automatically clear cached configuration.
+
+**What to do:**
+
+* Refresh the **Work Items** pane in Application Insights or clear your browser cache.
+* If links persist, manually unlink them in the resource settings.
+
+## GitHub issue or Azure DevOps item opens in the wrong repository or project
+
+This issue occurs if the default repository or organization URL is incorrect or multiple templates override settings.
+
+**What to do:**
+
+* Open the workbook, and verify the default repository or organization URL parameter.
+* Remove or update conflicting templates.
+
+[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)]
+
+[!INCLUDE [Third-party contact disclaimer](~/includes/third-party-contact-disclaimer.md)]
diff --git a/support/azure/azure-monitor/toc.yml b/support/azure/azure-monitor/toc.yml
@@ -82,6 +82,8 @@ items:
       href: app-insights/troubleshoot-application-map-issues.md
     - name: Troubleshoot Live Metrics issues
       href: app-insights/troubleshoot-live-metrics.md
+    - name: Troubleshoot work item integration
+      href: app-insights/troubleshoot-work-item-integration.md
   - name: Availability Tests
     items:
     - name: Availability monitoring common issues FAQ
diff --git a/support/windows-server/high-availability/csv-offline-after-component-goes-offline-during-active-io.md b/support/windows-server/high-availability/csv-offline-after-component-goes-offline-during-active-io.md
@@ -0,0 +1,181 @@
+---
+title: CSV Goes Offline after a Node or Storage Component Goes Offline During Active I/O
+description: Discusses a change in Cluster Shared Volume behavior that sends the CSV offline and could cause it to fail.
+ms.date: 11/05/2025
+author: kaushika-msft
+ms.author: kaushika
+manager: dcscontentpm
+audience: itpro
+ms.topic: troubleshooting
+ms.custom:
+- sap:clustering and high availability\cluster shared volume (csv)
+- pcy:WinComm Storage High Avail
+ms.reviewer: kaushika, v-mikiwu, v-appelgatet
+appliesto:
+  - <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2025</a>
+---
+# Cluster Shared Volume goes offline after a node or storage component goes offline
+
+This article discusses a situation in which the Cluster Shared Volume (CSV) of a cluster goes offline after other components go offline. The article includes steps to resolve the issue and, if it's necessary, recover any affected virtual machines (VMs).
+
+## Symptoms
+
+This issue starts under the following circumstances:
+
+1. A cluster node or storage component becomes unavailable, but I/O operations continue. For example, a disk array fails or requires maintenance.
+1. As I/O operations continue, metadata records accumulate.
+1. When the metadata records reach their allocated limits, I/O operations fail.
+1. The associated CSV enters a Failed state.
+1. Every 15 minutes (the default setting), the cluster tries to bring the CSV online. If the Virtual Machine Management Service (VMMS) manages VMs on the cluster, VMMS periodically tries to start the VMs.
+1. After 30 minutes, VMMS stops trying to start the VMs. Any VMs that use the affected CSV can't automatically recover.
+
+## Cause
+
+A recent change in cluster behavior affects how the CSV responds in the situation that's mentioned in the "Symptoms" section. Previously, when metadata records accumulated to the allocated limits, I/O operations could stop indefinitely. Because of the change, I/O operations fail in this situation instead of hanging. The I/O failure, in turn, causes the CSV to go offline and enter a Failed state.
+
+## Recovery
+
+You can use one of two methods to recover the cluster. The method to use depends on whether you can restore the previous cluster components, or you have to replace parts of the cluster.
+
+### Method 1: Restore the offline component and automatically repair the cluster
+
+After you restore the offline node or storage, the following steps occur automatically.
+
+1. The next time that the cluster automatically tries to bring the CSV online, it succeeds.
+1. Automatic repair processes start, and then the volume becomes available.
+
+> [!IMPORTANT]  
+> After the cluster recovers, you might have to manually start any VMMS-managed VMs that use the cluster. After the cluster is down for 30 minutes, VMMS stops automatically trying to restart the VMs.
+
+### Method 2: Replace the offline component and manually recover the cluster
+
+If you can't restore the missing node or storage, follow these steps to manually recover the cluster.
+
+> [!IMPORTANT]  
+>
+> - This procedure temporarily takes all volumes in the pool offline.
+> - You can use this procedure for either Storage Spaces or failover clusters. Every step that applies to virtual disks or volumes also applies to Cluster Virtual Disks and Cluster Shared Volumes.
+
+Run the following steps as a cluster administrator on a node that has full access to the storage pool.
+
+1. On a cluster node that has full access to the storage pool, open an administrative PowerShell Command Prompt window.
+
+1. To get the properties of the affected storage pool, run the following command at the PowerShell command prompt:
+
+   ```powershell
+   Get-ClusterResource <Pool>  
+   ```
+
+   > [!NOTE]  
+   >
+   > - In this cmdlet, \<Pool> is the name of the storage pool resource.
+   > - Later steps in this procedure use properties such as the name and owner group of the resource.
+
+1. To get the properties of the storage pool's virtual disks and CSVs, run the following command:
+
+   ```powershell
+   Get-ClusterResource | Where-Object { $_.ResourceType -eq "Physical Disk" }
+   ```
+
+   ```powershell
+   Get-ClusterSharedVolume
+   ```
+
+1. Review the properties to determine which resources are in a "Failed" state.
+
+   > [!NOTE]  
+   > If you intend to reuse name and ID information for any resources that you replace, you can use `Get-ClusterResource` and `Get-ClusterParameter` to get that information.
+
+1. Whether you're replacing a node, or just storage, run the following cmdlets to add unpooled disks to the storage pool:
+
+   ```powershell
+   Get-StoragePool -isprimordial $false | Add-PhysicalDisk -PhysicalDisks $(Get-PhysicalDisk -CanPool $true)
+   ```
+
+1. To retire unhealthy disks (or disks that are associated with a failed node), run the following cmdlets:
+
+   ```powershell
+   Get-PhysicalDisk | Where-Object { $_.OperationalStatus -eq "Lost Communication" } | Set-PhysicalDisk -usage Retired
+   ```
+
+1. Monitor the virtual disks by running `Get-VirtualDisk` and looking for `OperationalStatus = InService` in the cmdlet output. When the `OperationalStatus` parameter is clear for all the virtual disks, go to the next step.
+
+1. To move the affected storage pool (that you identified previously) to the current node, run a PowerShell cmdlet that resembles the following command:
+
+   ```powershell
+   Move-ClusterResource -node <Current Node> -name <OwnerGroup>
+   ```
+
+   > [!NOTE]  
+   > In this command, \<Current Node> is the name of the node that you're working from, and \<OwnerGroup> is the value of the OwnerGroup property of the storage group resource.
+
+1. To move the failed disk and CSV resources to the current node, run `Move-ClusterResource` again for each physical disk and CSV resource. To see the OwnerGroup value of the CSV, run `Get-ClusterSharedVolume | get-ClusterGroup`.
+
+1. To remove all cluster virtual disks and CSVs from cluster management, run the following PowerShell commands in sequence:
+
+   ```powershell
+   Remove-ClusterSharedVolume
+   Get-ClusterResource | Where-Object { $_.ResourceType -eq "Physical Disk" } | Remove-ClusterResource
+   ```
+
+1. To remove the storage pool from cluster management, run the `Remove-ClusterResource` command for the storage pool objects that you identified in step 2 of this procedure.
+
+1. To make the storage pool writable, run the following commands:
+
+   ```powershell
+   Get-StoragePool -isPrimordial $false | Set-StoragePool -IsReadOnly $false
+   ```
+
+1. To configure the virtual disks, run the following commands for each virtual disk that you identified in step 3 of this procedure.
+
+   ```powershell
+   Get-VirtualDisk | Set-VirtualDisk -IsManualAttach $false
+   ```
+
+1. Use the `Get-StorageJob` cmdlet to monitor the storage jobs that are related to repair. After the jobs start (the percentage completed is greater than 0), go to the next step.
+
+1. To restore the storage pool to cluster management, run the following commands:
+
+   ```powershell
+   Get-CimInstance -Namespace "root\MSCluster" -ClassName "MSCluster_AvailableStoragePool" | invoke-cimmethod -MethodName AddToCluster
+   ```
+
+1. Restore all non-failed virtual disks to cluster management. If any of the virtual disks from the previous step were configured as CSVs before the failure, convert them to CSVs.
+
+   For example, you can bring back any of the virtual disk or CSV resources that weren't in a failed state. To restore these resources, use the `virtualdiskid` and `name` property values from step 3, and then run commands that resemble the following script excerpt:
+
+   ```powershell
+   `$virtualdiskname = "ClusterPerformanceHistory"`
+   `$virtualdiskid = "603bb5d0-9c4d-4fc6-9c25-eec92a478733"`
+   `(get-clusteravailabledisk  | Where-Object { $_.Id -eq $virtualdiskid} | add-clusterdisk).Name = $virtualdiskname`
+   ```
+
+   You can use `Add-ClusterSharedVolume` to reconfigure the CSVs.
+
+1. Monitor the virtual disks by running `Get-VirtualDisk` and looking for `OperationalStatus = InService` in the cmdlet output. When the `OperationalStatus` parameter is clear for all of the virtual disks, continue to the next step.
+
+1. To bring the virtual disks online and configure them as read/write, run the following commands:
+
+   ```powershell
+   Get-VirtualDisk | get-disk | Where-Object { $_.IsReadonly -eq $true } | set-disk -IsReadOnly $false
+   Get-VirtualDisk | get-disk | Where-Object { $_.IsOffline -eq $true} | set-disk -IsOffline $false
+   ```
+
+1. Monitor the virtual disk footprints of the retired physical disks by running the following cmdlet:
+
+   ```powershell
+    get-physicaldisk -Usage Retired | ft Deviceid, Usage, VirtualDiskFootprint 
+   ```
+
+   When the footprint reaches zero, go to the next step.
+
+1. Restore the previously failed virtual disks to cluster management. If any of these virtual disks were previously configured as CSVs, convert them to CSVs.
+
+1. Bring the virtual disks from the previous step online, and configure them as read/write.
+
+> [!IMPORTANT]  
+> After the cluster recovers, you might have to manually start any VMMS-managed VMs that use the cluster. After the cluster is down for 30 minutes, VMMS stops automatically trying to restart the VMs.
+
+## Status
+
+This behavior is by design in Windows Server 2025. It's intended to prevent indefinite I/O unresponsiveness.
diff --git a/support/windows-server/toc.yml b/support/windows-server/toc.yml
@@ -1124,6 +1124,8 @@ items:
     items:
     - name: 'Troubleshooting guidance: Event ID 5120 Cluster Shared Volume'
       href: ./high-availability/event-id-5120-cluster-shared-volume-troubleshooting-guidance.md
+    - name: Cluster Shared Volume goes offline
+      href: ./high-availability/csv-offline-after-component-goes-offline-during-active-io.md
   - name: Errors when running the Validation Wizard
     items:
     - name: Cluster validation account causes events or messages
diff --git a/support/windows-server/virtualization/starting-or-live-migrating-hyper-v-vms-fails.md b/support/windows-server/virtualization/starting-or-live-migrating-hyper-v-vms-fails.md
@@ -1,36 +1,36 @@
 ---
 title: Starting or live migrating Hyper-V VMs fails
 description: Error 0x80070569 occurs when you try to start or do a live migration for a Hyper-V virtual machine.
-ms.date: 01/15/2025
+ms.date: 11/4/2025
 manager: dcscontentpm
 audience: ITPro
 ms.topic: troubleshooting
-ms.reviewer: kaushika, ctimon, kledman
+ms.reviewer: kaushika, crloewen
 ms.custom:
 - sap:virtualization and hyper-v\migration
 - pcy:WinComm Storage High Avail
 appliesto:
   - <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Supported versions of Windows Server</a>
 ---
-# Starting or live migrating Hyper-V virtual machines may fail with error 0x80070569
+# Starting or live migrating Hyper-V virtual machines might fail with error 0x80070569
 
 This article provides workarounds to solve the issue that virtual machines can't start or you can't do a live migration for a Hyper-V virtual machine in Windows Server.
 
 _Original KB number:_ &nbsp; 2779204
 
 ## Symptoms
 
-Virtual machines running on Windows Server 2016 or Windows Server 2012 R2 Hyper-V hosts may fail to start. You may receive an error message that's similar to:
+Virtual machines running on Windows Server or Hyper-V hosts might fail to start. You might receive an error message that's similar to:
 
-> Error 0x80070569 ('VM_NAME' failed to start worker process: Logon Failure: The user has not been granted the requested logon type at this computer.)
+> Error 0x80070569 ('VM_NAME' failed to start worker process: Logon Failure: The user isn't granted the requested logon type at this computer.)
 
-When you do a live migration of a Hyper-V virtual machine, the live migration may fail. You may receive an error message that's similar to:
+When you do a live migration of a Hyper-V virtual machine, the live migration might fail. You might receive an error message that's similar to:
 
-> Failed to create Planned Virtual Machine at migration destination: Logon failure: the user has not been granted the requested logon type at this computer. (0x80070569)
+> Failed to create Planned Virtual Machine at migration destination: Logon failure: the user isn't granted the requested logon type at this computer. (0x80070569)
 
-Additionally, when you do a recovery checkpoint and try to convert it to a reference point by using the `ConvertToReferencePoint` method, the conversion may fail. You may receive an error message that's similar to:
+Additionally, when you do a recovery checkpoint and try to convert it to a reference point by using the `ConvertToReferencePoint` method, the conversion might fail. You might receive an error message that's similar to:
 
-> Failed to write VHD attachment "VHDX_NAME" to "VM_NAME": Account restrictions are preventing this user from signing in. For example, blank passwords aren't allowed, sign-in times are limited, or a policy restriction has been enforced. (0x8007052f)
+> Failed to write VHD attachment "VHDX_NAME" to "VM_NAME": Account restrictions prevent this user from signing in. For example, blank passwords aren't allowed, sign-in times are limited, or a policy restriction is enforced. (0x8007052f)
 
 > [!NOTE]
 > The issue may stop temporarily if an Administrator logs into the Hyper-V host and runs the command `gpupdate /force`.
@@ -39,6 +39,10 @@ Additionally, when you do a recovery checkpoint and try to convert it to a refer
 
 This issue occurs because the NT Virtual Machine\Virtual Machines special identity doesn't have the **Log on as a service** right on the Hyper-V host computer. Usually, the Virtual Machine Management Service (VMMS) replaces this user permission at every Group Policy refresh to ensure it's always present. However, you may notice that the Group Policy refresh doesn't function correctly in certain situations.
 
+## Potential Fix
+
+One potential way to resolve this issue is to enable service log on. For more information, see [How to Enable Service Logon](/system-center/scsm/enable-service-log-on-sm?view=sc-sm-2025#enable-service-logon-as-log-on-type).
+
 ## Workaround
 
 To work around this problem, use the output of the `gpresult` command to identify the Group Policy Object (GPO) that modifies user rights settings. Then, use one of the following methods to correct the issue:
