Updated KI tables per request from K Choi

Author: ronmiab

azure-stack/hci/known-issues-2405-1.md

@@ -56,6 +56,7 @@ Here are the known issues from previous releases:
 |Feature  |Issue  |Workaround  |
 |---------|---------|---------|
 | Update<!--XX--> | When viewing the readiness check results for an Azure Stack HCI cluster via the Azure Update Manager, there might be multiple readiness checks with the same name.  |There's no known workaround in this release. Select **View details** to view specific information about the readiness check. |
+| Deployment | In large deployment scenarios, such as extensive AVD host pool deployments or large-scale VM provisioning, you might encounter reliability issues caused by a Hyper-V socket external library problem. | Follow these steps to mitigate the issue: </brb><br> 1. Run the command `Get-service mochostagent (\) get-process (\) kill`. Check the output of the command and verify if the handle count is in the thousands. </br><br> 2. Run the command `Get-service mochostagent (\) get-process` to kill the processes. </br><br> 3. Run the command `restart-service mochostagent` to restart the mochostagent service. |
 | Deployment<!--532173261--> | When deploying Azure Stack HCI, version 23H2 via the Azure portal, you might encounter the following deployment validation failure: <br><br> `Could not complete the operation. 400: Resource creation validation failed. Details: [{"Code":"AnswerFileValidationFailed","Message":"Errors in Value Validation:\r\nPhysicalNodesValidator found error at deploymentdata.physicalnodes[0].ipv4address: The specified  for \u0027deploymentdata.physicalnodes[0].ipv4address\u0027 is not a valid IPv4 address. Example: 192.168.0.1 or 192.168.0.1","Target":null,"Details":null}].` <br><br> If you go to the **Networking** tab in Azure portal deployment, within the **Network Intent** configuration, you could see the following error: The selected physical network adapter is not binded to the management virtual switch. | Follow the procedure in [Troubleshoot deployment validation failures in Azure portal](../hci/manage/troubleshoot-deployment.md). |
 | Deployment<!--534763786--> |The deployment via the Azure portal fails with this error: *Failed to fetch secret LocalAdminCredential from key vault.*  |There is no workaround for this issue in this release. If the issue occurs, contact Microsoft Support for next steps.|
 | Deployment<!--27312671--> | In some instances, during the registration of Azure Stack HCI servers, this error might be seen in the debug logs: *Encountered internal server error*. One of the mandatory extensions for device deployment might not be installed. |Follow these steps to mitigate the issue: <br><br> `$Settings = @{ "CloudName" = $Cloud; "RegionName" = $Region; "DeviceType" = "AzureEdge" }` <br><br> `New-AzConnectedMachineExtension -Name "AzureEdgeTelemetryAndDiagnostics"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -Settings $Settings -ExtensionType "TelemetryAndDiagnostics" -EnableAutomaticUpgrade` <br><br> `New-AzConnectedMachineExtension -Name "AzureEdgeDeviceManagement"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.Edge" -ExtensionType "DeviceManagementExtension"`<br><br> `New-AzConnectedMachineExtension -Name "AzureEdgeLifecycleManager"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Orchestration" -ExtensionType "LcmController"` <br><br>`New-AzConnectedMachineExtension -Name "AzureEdgeRemoteSupport"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -ExtensionType "EdgeRemoteSupport" -EnableAutomaticUpgrade`  |

azure-stack/hci/known-issues-2405-2.md

@@ -58,6 +58,7 @@ Here are the known issues from previous releases:
 |Feature  |Issue  |Workaround  |
 |---------|---------|---------|
 | Update<!--XX--> | When viewing the readiness check results for an Azure Stack HCI cluster via the Azure Update Manager, there might be multiple readiness checks with the same name.  |There's no known workaround in this release. Select **View details** to view specific information about the readiness check. |
+| Deployment | In large deployment scenarios, such as extensive AVD host pool deployments or large-scale VM provisioning, you might encounter reliability issues caused by a Hyper-V socket external library problem. | Follow these steps to mitigate the issue: </brb><br> 1. Run the command `Get-service mochostagent (\) get-process (\) kill`. Check the output of the command and verify if the handle count is in the thousands. </br><br> 2. Run the command `Get-service mochostagent (\) get-process` to kill the processes. </br><br> 3. Run the command `restart-service mochostagent` to restart the mochostagent service. |
 | Deployment<!--532173261--> | When deploying Azure Stack HCI, version 23H2 via the Azure portal, you might encounter the following deployment validation failure: <br><br> `Could not complete the operation. 400: Resource creation validation failed. Details: [{"Code":"AnswerFileValidationFailed","Message":"Errors in Value Validation:\r\nPhysicalNodesValidator found error at deploymentdata.physicalnodes[0].ipv4address: The specified  for \u0027deploymentdata.physicalnodes[0].ipv4address\u0027 is not a valid IPv4 address. Example: 192.168.0.1 or 192.168.0.1","Target":null,"Details":null}].` <br><br> If you go to the **Networking** tab in Azure portal deployment, within the **Network Intent** configuration, you could see the following error: The selected physical network adapter is not binded to the management virtual switch. | Follow the procedure in [Troubleshoot deployment validation failures in Azure portal](../hci/manage/troubleshoot-deployment.md). |
 | Deployment<!--534763786--> |The deployment via the Azure portal fails with this error: *Failed to fetch secret LocalAdminCredential from key vault.*  |There is no workaround for this issue in this release. If the issue occurs, contact Microsoft Support for next steps.|
 | Deployment<!--27312671--> | In some instances, during the registration of Azure Stack HCI servers, this error might be seen in the debug logs: *Encountered internal server error*. One of the mandatory extensions for device deployment might not be installed. |Follow these steps to mitigate the issue: <br><br> `$Settings = @{ "CloudName" = $Cloud; "RegionName" = $Region; "DeviceType" = "AzureEdge" }` <br><br> `New-AzConnectedMachineExtension -Name "AzureEdgeTelemetryAndDiagnostics"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -Settings $Settings -ExtensionType "TelemetryAndDiagnostics" -EnableAutomaticUpgrade` <br><br> `New-AzConnectedMachineExtension -Name "AzureEdgeDeviceManagement"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.Edge" -ExtensionType "DeviceManagementExtension"`<br><br> `New-AzConnectedMachineExtension -Name "AzureEdgeLifecycleManager"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Orchestration" -ExtensionType "LcmController"` <br><br>`New-AzConnectedMachineExtension -Name "AzureEdgeRemoteSupport"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -ExtensionType "EdgeRemoteSupport" -EnableAutomaticUpgrade`  |

azure-stack/hci/known-issues-2405-3.md

@@ -50,6 +50,7 @@ Here are the known issues from previous releases:
 |Feature  |Issue  |Workaround  |
 |---------|---------|---------|
 | Update<!--XX--> | When viewing the readiness check results for an Azure Stack HCI cluster via the Azure Update Manager, there might be multiple readiness checks with the same name.  |There's no known workaround in this release. Select **View details** to view specific information about the readiness check. |
+| Deployment | In large deployment scenarios, such as extensive AVD host pool deployments or large-scale VM provisioning, you might encounter reliability issues caused by a Hyper-V socket external library problem. | Follow these steps to mitigate the issue: </brb><br> 1. Run the command `Get-service mochostagent (\) get-process (\) kill`. Check the output of the command and verify if the handle count is in the thousands. </br><br> 2. Run the command `Get-service mochostagent (\) get-process` to kill the processes. </br><br> 3. Run the command `restart-service mochostagent` to restart the mochostagent service. |
 | Deployment<!--532173261--> | When deploying Azure Stack HCI, version 23H2 via the Azure portal, you might encounter the following deployment validation failure: <br><br> `Could not complete the operation. 400: Resource creation validation failed. Details: [{"Code":"AnswerFileValidationFailed","Message":"Errors in Value Validation:\r\nPhysicalNodesValidator found error at deploymentdata.physicalnodes[0].ipv4address: The specified  for \u0027deploymentdata.physicalnodes[0].ipv4address\u0027 is not a valid IPv4 address. Example: 192.168.0.1 or 192.168.0.1","Target":null,"Details":null}].` <br><br> If you go to the **Networking** tab in Azure portal deployment, within the **Network Intent** configuration, you could see the following error: The selected physical network adapter is not binded to the management virtual switch. | Follow the procedure in [Troubleshoot deployment validation failures in Azure portal](../hci/manage/troubleshoot-deployment.md). |
 | Deployment<!--534763786--> |The deployment via the Azure portal fails with this error: *Failed to fetch secret LocalAdminCredential from key vault.*  |There is no workaround for this issue in this release. If the issue occurs, contact Microsoft Support for next steps.|
 | Deployment<!--27312671--> | In some instances, during the registration of Azure Stack HCI servers, this error might be seen in the debug logs: *Encountered internal server error*. One of the mandatory extensions for device deployment might not be installed. |Follow these steps to mitigate the issue: <br><br> `$Settings = @{ "CloudName" = $Cloud; "RegionName" = $Region; "DeviceType" = "AzureEdge" }` <br><br> `New-AzConnectedMachineExtension -Name "AzureEdgeTelemetryAndDiagnostics"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -Settings $Settings -ExtensionType "TelemetryAndDiagnostics" -EnableAutomaticUpgrade` <br><br> `New-AzConnectedMachineExtension -Name "AzureEdgeDeviceManagement"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.Edge" -ExtensionType "DeviceManagementExtension"`<br><br> `New-AzConnectedMachineExtension -Name "AzureEdgeLifecycleManager"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Orchestration" -ExtensionType "LcmController"` <br><br>`New-AzConnectedMachineExtension -Name "AzureEdgeRemoteSupport"  -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -ExtensionType "EdgeRemoteSupport" -EnableAutomaticUpgrade`  |

azure-stack/hci/known-issues-2405.md

@@ -61,6 +61,7 @@ Here are the known issues in this release:
 
 |Feature|Issue|Workaround/Comments|
 |------|------|----------|
+| Deployment | In large deployment scenarios, such as extensive AVD host pool deployments or large-scale VM provisioning, you might encounter reliability issues caused by a Hyper-V socket external library problem. | Follow these steps to mitigate the issue: </brb><br> 1. Run the command `Get-service mochostagent (\) get-process (\) kill`. Check the output of the command and verify if the handle count is in the thousands. </br><br> 2. Run the command `Get-service mochostagent (\) get-process` to kill the processes. </br><br> 3. Run the command `restart-service mochostagent` to restart the mochostagent service. |
 | Deployment<!--532173261--> | When deploying Azure Stack HCI, version 23H2 via the Azure portal, you might encounter the following deployment validation failure: <br><br> `Could not complete the operation. 400: Resource creation validation failed. Details: [{"Code":"AnswerFileValidationFailed","Message":"Errors in Value Validation:\r\nPhysicalNodesValidator found error at deploymentdata.physicalnodes[0].ipv4address: The specified  for \u0027deploymentdata.physicalnodes[0].ipv4address\u0027 is not a valid IPv4 address. Example: 192.168.0.1 or 192.168.0.1","Target":null,"Details":null}].` <br><br> If you go to the **Networking** tab in Azure portal deployment, within the **Network Intent** configuration, you could see the following error: The selected physical network adapter is not binded to the management virtual switch. | Follow the procedure in [Troubleshoot deployment validation failures in Azure portal](../hci/manage/troubleshoot-deployment.md). |
 | Deployment<!--534763786--> |The deployment via the Azure portal fails with this error: *Failed to fetch secret LocalAdminCredential from key vault.*  |There is no workaround for this issue in this release. If the issue occurs, contact Microsoft Support for next steps.|
 | Deployment<!--XX--> |The new ISO image for the Azure Stack HCI, version 23H2 operating system was rolled back to a previous version owing to compatibility issues with some hardware configurations.   |If you encounter any issues in Arc registration, roll back to the previous version. No action is required for you if you have already successfully deployed the newer image. Both the ISO images are the same operating system build version.|

azure-stack/hci/known-issues-2408.md

@@ -39,6 +39,7 @@ The following issues are fixed in this release:
 |------|------|----------|
 | Updates <!--28101226-->|An update issue related to missing resource type ID field in the health checks was fixed.  ||
 | Updates <!--28101677-->|An update issue related to different health checks having the same name was fixed.   ||
+| Deployment | In large deployment scenarios, such as extensive AVD host pool deployments or large-scale VM provisioning, you might encounter reliability issues caused by a Hyper-V socket external library problem. ||
 
 ## Known issues in this release
 
@@ -50,6 +51,7 @@ The following table lists the known issues in this release:
 | Networking <!--29180461--> | When a node is configured with a proxy server that has capital letters in its address, such as **HTTP://10.100.000.00:8080**, Arc extensions fail to install or update on the node in existing builds, including version 2408. However, the node remains Arc connected. | Follow these steps to mitigate the issue: </br><br> 1. Set the environment values in lowercase. `[System.Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://10.100.000.00:8080", "Machine")`. </br><br> 2. Validate that the values were set. `[System.Environment]::GetEnvironmentVariable("HTTP_PROXY", "Machine").` </br><br> 3. Restart Arc services. </br><br> `Restart-Service himds` </br><br> `Restart-Service ExtensionService` </br><br> `Restart-Service GCArcService` </br><br> 4. Signal the AzcmaAgent with the lowercase proxy information. </br><br> `& 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config set proxy.url http://10.100.000.00:8080` </br><br>`& 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config list` |
 | Networking <!--29229789--> | When Arc machines go down, the "**All Clusters**" page, in the new portal experience shows a "**PartiallyConnected**" or "**Not Connected Recently** status. Even when the Arc machines become healthy, they may not show a "**Connected**" status. | There's no known workaround for this issue. To check the connectivity status, use the old experience to see if it shows as "**Connected**". |
 | Security <!--29333930--> | The SideChannelMitigation security feature may not show an enabled state even if it's enabled. | There's no workaround in this release. If you encounter this issue, contact Microsoft Support to determine next steps. |
+| Deployment | The Mochostagent service might appear to be running but can get stuck without updating logs for over a month. You can identify this issue by checking if the service logs in C:\programdata\mochostagent\logs are not being updated. | Run the following command to restart the mochostagent service: `restart-service mochostagent`. |
 
 ## Known issues from previous releases