Merge pull request #3449 from MicrosoftDocs/main638711802341844907sync_temp

For protected branch, push strategy should use PR and merge to target branch method to work around git push error

Author: learn-build-service-prod[bot]

azure-local/includes/hci-applies-to-supplemental-package-22h2.md

@@ -3,7 +3,7 @@ title: Release notes with fixed and known issues in Azure Local 2411.1 baseline
 description: Read about the known issues and fixed issues in Azure Local 2411.1 baseline release.
 author: alkohli
 ms.topic: conceptual
-ms.date: 12/26/2024
+ms.date: 12/30/2024
 ms.author: alkohli
 ms.reviewer: alkohli
 ---
@@ -53,7 +53,7 @@ The following table lists the known issues in this release:
 
 |Feature  |Issue  |Workaround  |
 |---------|---------|---------|
-| Deployment | Validation times out due to timestamp deserialization. | When deploying the operating system, select **English (United States)** as the installation language, as well as the time and currency format. |
+| Deployment | Validation times out due to timestamp deserialization. | When deploying the operating system, select **English (United States)** as the installation language, as well as the time and currency format. <br> For detailed remediation steps, see the troubleshooting guide in the [Azure Local Supportability](https://github.com/Azure/AzureLocal-Supportability/blob/main/TSG/Deployment/Triggering-deployment-settings-validation-call-results-in-OperationTimeout-2411-1-and-LCM-Extension-2411-1.md) GitHub repository.|
 
 ## Known issues from previous releases
 

azure-local/includes/hci-applies-to-supplemental-package.md

@@ -3,7 +3,7 @@ title: Release notes with fixed and known issues in Azure Local 2411 baseline re
 description: Read about the known issues and fixed issues in Azure Local 2411 baseline release.
 author: alkohli
 ms.topic: conceptual
-ms.date: 12/17/2024
+ms.date: 12/30/2024
 ms.author: alkohli
 ms.reviewer: alkohli
 ---
@@ -48,13 +48,11 @@ The following table lists the known issues in this release:
 |Feature  |Issue  |Workaround  |
 |---------|---------|---------|
 | Security vulnerability <!--ADO--> |Microsoft has identified a security vulnerability that could expose the local admin credentials used during the creation of Arc VMs on Azure Local to non-admin users on the VM and on the hosts. <br> Arc VMs running on releases prior to Azure Local 2411 release are vulnerable.  |To identify the Arc VMs that require this change and to change the account passwords, see detailed instructions in: [Security vulnerability for Arc VMs on Azure Local](https://aka.ms/CVE-2024-49060).|
-| Deployment <!--30273426--><br>Upgrade |If the timezone is not set to UTC before you deploy Azure Local, an *ArcOperationTimeOut* error occurs during validation. The following error message is displayed: *OperationTimeOut, No updates received from device for operation.*   |Depending on your scenario, choose one of the following workarounds for this issue: <br><br> **Scenario 1.** Before you start the deployment, make sure that the timezone is set to UTC. <br><br>Connect to each of the Azure Local nodes and change the timezone to UTC. <br><br> Run the following command: `Set-TimeZone -Id "UTC"`. <br><br> **Scenario 2.** If you started the deployment without setting the UTC timezone and received the error mentioned in the validation phase, follow these steps:<br><br> 1. Connect to each Azure Local node. Change the time zone to UTC with `Set-TimeZone -Id "UTC"`. Reboot the nodes.<br><br> 2. After the nodes have restarted, go to the Azure Local resource in Azure portal. Start the validation again to resolve the issue and continue with the deployment or upgrade.|
+| Deployment <!--30273426--><br>Upgrade |If the timezone is not set to UTC before you deploy Azure Local, an *ArcOperationTimeOut* error occurs during validation. The following error message is displayed: *OperationTimeOut, No updates received from device for operation.*   |Depending on your scenario, choose one of the following workarounds for this issue: <br><br> **Scenario 1.** Before you start the deployment, make sure that the timezone is set to UTC. <br><br>Connect to each of the Azure Local nodes and change the timezone to UTC. <br><br> Run the following command: `Set-TimeZone -Id "UTC"`. <br><br> **Scenario 2.** If you started the deployment without setting the UTC timezone and received the error mentioned in the validation phase, follow these steps:<br><br> 1. Connect to each Azure Local node. Change the time zone to UTC with `Set-TimeZone -Id "UTC"`. Reboot the nodes.<br><br> 2. After the nodes have restarted, go to the Azure Local resource in Azure portal. Start the validation again to resolve the issue and continue with the deployment or upgrade.<br><br> For detailed remediation steps, see the troubleshooting guide in the [Azure Local Supportability](https://github.com/Azure/AzureLocal-Supportability/blob/main/TSG/Deployment/Triggering-deployment-settings-validation-call-results-in-OperationTimeout-2411-0.md) GitHub repository.|
 | Update <!--30345067--> | When updating from version 2408.2.7 to 2411.0.24, the update process could fail with the following error message: `Type 'CauPreRequisites' of Role 'CAU' raised an exception: Could not finish cau prerequisites due to error 'Cannot remove item C:\UpdateDistribution\<any_file_name>: Access to the path is denied.'` |For detailed steps on how to mitigate this issue, see [Azure Local Troubleshooting Guide for Update](https://github.com/Azure/AzureLocal-Supportability/blob/main/TSG/Update/mitigation-for-cannot-remove-c-update-distribution-with-access-denied.md).|
 | Update <!--ADO--> | With the 2411 release, solution and Solution Builder Extension update are not combined in a single update run.  |To apply a Solution Builder Extension package, you need a separate update run.|
 | Update <!--30221399--> | When applying solution update in this release, the update can fail. This will occur only if the update was started prior to November 26. The issue that causes the failure can result in one of the following error messages: <br><br>**Error 1** - The step "update ARB and extension" error "Clear-AzContext failed with 0 and Exception calling "Initialize" with "1" argument(s): "Object reference not set to an instance of an object." at "Clear-AzPowerShellCache". <br><br>**Error 2** - The step "EvalTVMFlow" error "CloudEngine.Actions.InterfaceInvocationFailedException: Type 'EvalTVMFlow' of Role 'ArcIntegration' raised an exception: This module requires `Az.Accounts` version 3.0.5. An earlier version of `Az.Accounts` is imported in the current PowerShell session. Please open a new session before importing this module. This error could indicate that multiple incompatible versions of the Azure PowerShell cmdlets are installed on your system. Please see https://aka.ms/azps-version-error for troubleshooting information." <br><br> Depending on the version of PowerShell modules, the above error could be reported for both versions 3.0.4 and 3.0.5.|For detailed steps on how to mitigate this issue, go to: [https://aka.ms/azloc-update-30221399](https://aka.ms/azloc-update-30221399).     |
 
-
-
 ## Known issues from previous releases
 
 The following table lists the known issues from previous releases:

azure-local/known-issues-2411-1.md

@@ -5,7 +5,7 @@ author: alkohli
 ms.author: alkohli
 ms.topic: how-to
 ms.service: azure-stack-hci
-ms.date: 10/29/2024
+ms.date: 12/27/2024
 ---
 
 # Evaluate the deployment readiness of your environment for Azure Local, version 23H2
@@ -406,46 +406,69 @@ To remediate the blocking issues in this output, open the Active Directory tool
 
 ### [Network](#tab/network)
 
-It is possible that the IP addresses allocated to Azure Local may already be active on the network. The network validator validates your network infrastructure for valid IP ranges reserved for deployment. It attempts to ping and connect to WinRM and SSH ports to ensure there's no active host using the IP address from the reserved IP range.
+It is possible that the IP addresses allocated to Azure Local may already be active on the network. The network validator validates your network infrastructure for valid IP ranges reserved for deployment. It attempts to ping and connect to WinRM and SSH ports to ensure there's no active host using the IP address from the reserved IP range. 
 
-You provide the network IP range reserved for Azure Local deployment as part of the answer file JSON, which you can use during network validation. Or, you can manually provide the starting and ending IP addresses when running the validator cmdlet.
+Network validator also checks storage connection, adapter driver readiness, and other host network configuration readiness.
 
-### Run the network validator
-
-To run the network validator locally on the Azure Local machine node, the workstation, or the staging server with the answer file, follow these steps.
-
-1. Run one of the following cmdlets:
-
-    
-   - If using the answer file:
-   
-      ```powershell
-      Invoke-AzStackHciNetworkValidation -AnswerFile <Answerfilename>.json
-      ```
-   
-   - If entering the starting and ending IP addresses manually:
-       
-      ```powershell
-      Invoke-AzStackHciNetworkValidation -StartingAddress <StartingIPRangeAddress> -EndingAddress <EndingIPRangeAddress> 
-      ```
+You provide the answer file JSON as the input for network validator cmdlet call. Or you can manually provide the individual parameters when running the validator cmdlet.
 
-### Network validator output
+> [!NOTE]
+> You must run the network validator on the final hardware that you want to use for the Azure local instance deployment.
 
-The following samples are the output from successful and unsuccessful runs of the network validator.
+### Run the network validator
 
-To learn more about different sections in the readiness check report, see [Understand readiness check report](#understand-readiness-check-report).
+To run the network validator locally on the Azure Local node with the answer file, use the following commands:
 
-**Sample output: Successful test**
+```powershell
+$allServers = "<ARRAY OF SERVERS' IP>" # you need to use IP for the connection 
+$userName = "<LOCALADMIN>" 
+$secPassWord = ConvertTo-SecureString "<LOCALADMINPASSWORD>" -AsPlainText -Force 
+$hostCred = New-Object System.Management.Automation.PSCredential($userName, $secPassWord) 
+[System.Management.Automation.Runspaces.PSSession[]] $allServerSessions = @() 
+foreach ($currentServer in $allServers) { 
+   $currentSession = Microsoft.PowerShell.Core\New-PSSession -ComputerName $currentServer -Credential $hostCred -ErrorAction Stop 
+   $allServerSessions += $currentSession 
+} 
+$answerFilePath = "<ANSWERFILELOCATION>" # Like C:\MASLogs\Unattended-2024-07-18-20-44-48.json 
+Invoke-AzStackHciNetworkValidation -DeployAnswerFile $answerFilePath -PSSession $allServerSessions -ProxyEnabled $false 
+```
 
-The following sample is the output from a successful run of the network validator. The output indicates no active host is using an IP address from the reserved IP range.
+To run the network validator locally on the Azure Local node using individual parameters, use the following commands:
 
-   :::image type="content" source="./media/use-environment-checker/network-validator-sample-passed.png" alt-text="Screenshot of a passed report after running the network validator." lightbox="./media/use-environment-checker/network-validator-sample-passed.png":::
+```powershell
+$answerFilePath = "<ANSWERFILELOCATION>" 
+$managementSubnetCIDR = "<CIDR string for management subnet>" 
+$logOutputPath = "<LOGFILELOCATION>" 
+$userName = "<LOCALADMIN>" 
+$secPassWord = ConvertTo-SecureString "<LOCALADMINPASSWORD>" -AsPlainText -Force 
+$sessionCredential = New-Object System.Management.Automation.PSCredential($userName, $secPassWord) 
+$answerFileContent = Get-Content $answerFilePath -Raw | ConvertFrom-Json 
+$ipPools = New-Object System.Collections.ArrayList 
+[System.Management.Automation.Runspaces.PSSession[]] $allServerSessions = @() 
+foreach ($ipPool in $answerFileContent.scaleUnits[0].deploymentData.infrastructureNetwork[0].ipPools) { 
+   $currentPoolObject = [PSCustomObject] @{ 
+     StartingAddress = $ipPool.StartingAddress 
+     EndingAddress = $ipPool.EndingAddress 
+   } 
+   $ipPools.Add($currentPoolObject) 
+} 
+[PSObject[]] $atcHostIntentsInfo = $answerFileContent.scaleUnits[0].deploymentData.hostNetwork.intents 
+[System.String[]] $allServers = $answerFileContent.scaleUnits[0].deploymentData.physicalNodes.Name 
+[System.Management.Automation.Runspaces.PSSession[]] $allServerSessions = @() 
+foreach ($currentServer in $allServers) { 
+   $currentSession = Microsoft.PowerShell.Core\New-PSSession -ComputerName $currentServer -Credential $sessionCredential -ErrorAction Stop 
+   $allServerSessions += $currentSession 
+} 
+Invoke-AzStackHciNetworkValidation -IpPools $ipPools -ManagementSubnetValue $managementSubnetCIDR -PSSession $allServerSessions -SessionCredential $sessionCredential -OutputPath $logOutputPath -AtcHostIntents $atcHostIntentsInfo 
+```
+  
+### Network validator sample output
 
-**Sample output: Failed test**
+Here's a sample output of an unsuccessful run of the network validator. The failure occurs because the network adapter has two IP addresses, when it should have only one.  
 
-The following sample is the output from a failed run of the network validator. This output shows two active hosts are using IP address from the reserved IP range.
+:::image type="content" source="./media/use-environment-checker/network-validator-sample-failed.png" alt-text="Screenshot of a failed report after running the network validator." lightbox="./media/use-environment-checker/network-validator-sample-failed.png":::
 
-   :::image type="content" source="./media/use-environment-checker/network-validator-sample-failed.png" alt-text="Screenshot of a failed report after running the network validator." lightbox="./media/use-environment-checker/network-validator-sample-failed.png":::
+To learn more about different sections in the readiness check report, see [Understand readiness check report](#understand-readiness-check-report).
 
 ### [Arc integration](#tab/arc-integration)
 
@@ -517,7 +540,7 @@ The information displayed on each readiness check report varies depending on the
 | **Diagnostics** | Displays the result of the diagnostic tests. For example, the health and availability of a DNS server. It also shows what information the validator collects for diagnostic purposes, such as WinHttp, IE proxy, and environment variable proxy settings. | Connectivity validator report|
 | Hardware | Displays the health status of all the physical machines and their hardware components. For information on the tests performed on each hardware, see the table under the "Hardware" tab in the [Run readiness checks](#run-readiness-checks) section. | Hardware validator report|
 | **AD OU Diagnostics** | Displays the result of the Active Directory organization unit test. Displays if the specified organizational unit exists and contains proper sub-organizational units. | Active Directory validator report|
-| Network range test | Displays the result of the network range test. If the test fails, it displays the IP addresses that belong to the reserved IP range. | Network validator report |
+| Network test | Displays the result of the network test. If the test fails, it displays the results and corresponding remediations. | Network validator report |
 | **Summary** | Lists the count of successful and failed tests. Failed test results are expanded to show the failure details under **Needs Remediation**.| All reports |
 | **Remediation** | Displays only if a test fails. Provides a link to the article that provides guidance on how to remediate the issue. | All reports |
 | **Log location (contains PII)** | Provides the path where the log file is saved. The default path is:<br><br>- `$HOME\.AzStackHci\AzStackHciEnvironmentChecker.log` when you run the Environment Checker in a standalone mode.<br>- `C:\CloudDeployment\Logs` when the Environment Checker is run as part of the deployment process.<br><br> Each run of the validator overwrites the existing file.| All reports |