Merge pull request #17219 from ManikaDhiman/md-top40-refresh

Top40 refresh: Edit pass

Author: JillGrant615

azure-local/concepts/data-collection.md

@@ -5,7 +5,7 @@ author: jasongerend
 ms.author: jgerend
 ms.topic: conceptual
 ms.service: azure-local
-ms.date: 04/24/2023
+ms.date: 02/27/2025
 ---
 
 # Azure Stack HCI data collection
@@ -14,20 +14,20 @@ ms.date: 04/24/2023
 
 [!INCLUDE [azure-local-banner-22h2](../includes/azure-local-banner-22h2.md)]
 
-This topic describes required data collected to keep Azure Stack HCI secure, up to date, and working as expected.
+This article describes required data collected to keep Azure Stack HCI secure, up to date, and working as expected.
 
-Customer data, including the names, metadata, configuration, and contents of your on-premises virtual machines (VMs) is never sent to the cloud unless you turn on additional services like Azure Backup or Azure Site Recovery, or unless you enroll those VMs individually into cloud management services like Azure Arc.
+Customer data, including the names, metadata, configuration, and contents of your on-premises virtual machines (VMs) is never sent to the cloud unless you turn on other services like Azure Backup or Azure Site Recovery, or unless you enroll those VMs individually into cloud management services like Azure Arc.
 
-We do collect diagnostic data. The data described below is required for Microsoft to provide Azure Stack HCI. This data is collected once a day, and data collection events can be viewed in the event logs. Azure Stack HCI collects the minimum data required to keep your clusters up to date, secure, and operating properly.
+We do collect diagnostic data. The data described in the following section is required for Microsoft to provide Azure Stack HCI. This data is collected once a day, and data collection events can be viewed in the event logs. Azure Stack HCI collects the minimum data required to keep your clusters up to date, secure, and operating properly.
 
    > [!IMPORTANT]
-   > The data described below that Azure Stack HCI collects is independent from Windows diagnostic data, which can be configured for various levels of collection. In Azure Stack HCI, the default setting for Windows diagnostic data collection is Security (off), meaning that no Windows diagnostic data is sent unless the administrator changes the diagnostic data settings. For more information, see [Configure Windows diagnostic data in your organization](/windows/privacy/configure-windows-diagnostic-data-in-your-organization). Microsoft is an independent controller of any Windows diagnostic data collected in connection with Azure Stack HCI. Microsoft will handle the Windows diagnostic data in accordance with the [Microsoft Privacy Statement](https://privacy.microsoft.com/privacystatement).
+   > The data described below that Azure Stack HCI collects is independent from Windows diagnostic data, which can be configured for various levels of collection. In Azure Stack HCI, the default setting for Windows diagnostic data collection is Security (off), meaning that no Windows diagnostic data is sent unless the administrator changes the diagnostic data settings. For more information, see [Configure Windows diagnostic data in your organization](/windows/privacy/configure-windows-diagnostic-data-in-your-organization). Microsoft is an independent controller of any Windows diagnostic data collected in connection with Azure Stack HCI. Microsoft handles the Windows diagnostic data in accordance with the [Microsoft Privacy Statement](https://privacy.microsoft.com/privacystatement).
 
 ## Data collection and residency
 
 This Azure Stack HCI data:
 
-- is not sent to Microsoft until the product is registered with Azure. When Azure Stack HCI is unregistered, this data collection stops.
+- isn't sent to Microsoft until the product is registered with Azure. When Azure Stack HCI is unregistered, this data collection stops.
 - is logged to the Microsoft-AzureStack-HCI/Analytic event channel.
 - is in JSON format, so that system administrators can examine and analyze the data being sent.
 
@@ -43,14 +43,14 @@ To learn about how Microsoft stores diagnostic data in Azure, see [Data residenc
 
 ## Data retention
 
-After Azure Stack HCI collects this data, it is retained for 90 days. Aggregated, de-identified data may be kept longer.
+After Azure Stack HCI collects this data, it's retained for 90 days. Aggregated, de-identified data may be kept longer.
 
 ## What data is collected?
 
 Azure Stack HCI collects:
 
 - Information about servers such as operating system version, processor model, number of processor cores, memory size, cluster identifier, and hash of hardware ID
-- List of installed Azure Stack HCI server features (e.g. BitLocker)
+- List of installed Azure Stack HCI server features (for example, BitLocker)
 - Information necessary to compute the reliability of the Azure Stack HCI operating system
 - Information necessary to compute the reliability of the health collection data
 - Information gathered from the event log for specific errors, such as update download failed
@@ -97,7 +97,7 @@ Azure Stack HCI collects:
        } 
    }
    ```
- 
+
 The output should look something like this:
 
 ```shell

azure-local/concepts/nested-virtualization.md

@@ -5,7 +5,7 @@ author: jasongerend
 ms.author: jgerend
 ms.topic: conceptual
 ms.service: azure-local
-ms.date: 04/17/2023
+ms.date: 02/27/2025
 ---
 
 # Nested virtualization in Azure Stack HCI
@@ -17,7 +17,7 @@ ms.date: 04/17/2023
 Nested virtualization is a feature that lets you run Hyper-V inside a Hyper-V virtual machine (VM). This allows you to maximize your hardware investments and gain flexibility in evaluation and testing scenarios.
 
    > [!IMPORTANT]
-   > Because Azure Stack HCI is intended as a virtualization host where you run all of your workloads in VMs, nested virtualization is not supported in production environments. For production use, Azure Stack HCI should be deployed on validated physical hardware.
+   > Because Azure Stack HCI is intended as a virtualization host where you run all of your workloads in VMs, nested virtualization isn't supported in production environments. For production use, Azure Stack HCI should be deployed on validated physical hardware.
 
 Some scenarios in which nested virtualization can be useful are:
 
@@ -42,7 +42,7 @@ To configure nested virtualization on a VM using PowerShell, see [Run Hyper-V in
 ## Nested virtualization processor support
 
 Azure Stack HCI, version 21H2 adds support for nested virtualization on AMD processors. Now you can run nested virtualization on first generation EPYC processors or newer generations (Naples, Rome, Milan).
- 
+
 Prerequisites:
 
 - Azure Stack HCI, version 21H2

azure-local/manage/cluster-powershell.md

@@ -3,7 +3,7 @@ title: Manage Azure Stack HCI and Windows Server clusters using PowerShell
 description: Learn how to manage clusters on Azure Stack HCI and Windows Server using PowerShell
 author: JasonGerend
 ms.topic: how-to
-ms.date: 04/17/2023
+ms.date: 02/27/2025
 ms.author: jgerend
 ms.reviewer: stevenek
 ---
@@ -14,12 +14,14 @@ ms.reviewer: stevenek
 
 [!INCLUDE [azure-local-banner-22h2](../includes/azure-local-banner-22h2.md)]
 
-Windows PowerShell can be used to manage resources and configure features on your Azure Stack HCI and Windows Server clusters.
+This article describes how to manage Azure Stack HCI and Windows Server clusters using PowerShell.
+
+You can use Windows PowerShell to manage resources and configure features on your Azure Stack HCI and Windows Server clusters.
 
 You manage clusters from a remote computer, rather than on a host server in a cluster. This remote computer is called the management computer.
 
 > [!NOTE]
-> When running PowerShell commands from a management computer, include the `-Name` or `-Cluster` parameter with the name of the cluster you are managing. In addition, you will need to specify the fully qualified domain name (FQDN) when using the `-ComputerName` parameter for a server node.
+> When running PowerShell commands from a management computer, include the `-Name` or `-Cluster` parameter with the name of the cluster you're managing. In addition, you need to specify the fully qualified domain name (FQDN) when using the `-ComputerName` parameter for a server node.
 
 For the complete reference documentation for managing clusters using PowerShell, see the [FailoverCluster reference](/powershell/module/failoverclusters).
 
@@ -30,7 +32,7 @@ Windows PowerShell is used to perform all the tasks in this article. It's recomm
 If the following cmdlets aren't available in your PowerShell session, you may need to add the `Failover Cluster` Module for Windows PowerShell Feature, using the following PowerShell cmd: `Add-WindowsFeature RSAT-Clustering-PowerShell`.
 
 > [!NOTE]
-> Starting with Windows 10 October 2018 Update, RSAT is included as a set of "Features on Demand" right from Windows 10. For versions older than Windows 10 22H2, simply go to **Settings > Apps > Apps & features > Optional features > Add a feature > RSAT: Failover Clustering Tools**, and select **Install**. For Windows 10 22H2 and Windows 11, go to **Settings > System > Optional features > Add a feature > RSAT: Failover Clustering Tools**, and select **Add**. To see operation progress, click the Back button to view status on the "Manage optional features" page. The added feature will persist across Windows 10 version upgrades.
+> Starting with Windows 10 October 2018 Update, RSAT is included as a set of "Features on Demand" right from Windows 10. For versions older than Windows 10 22H2, go to **Settings > Apps > Apps & features > Optional features > Add a feature > RSAT: Failover Clustering Tools**, and select **Install**. For Windows 10 22H2 and Windows 11, go to **Settings > System > Optional features > Add a feature > RSAT: Failover Clustering Tools**, and select **Add**. To see operation progress, click the Back button to view status on the "Manage optional features" page. The added feature persists across Windows 10 version upgrades.
 ## View cluster settings and resources
 
 Gets information about a cluster named Cluster1:
@@ -84,7 +86,7 @@ Starts the Cluster service on all server nodes of the cluster on which it isn't
 Start-Cluster -Name Cluster1
 ```
 
-This example stops the Cluster service on all nodes in the cluster named Cluster1, which will stop all services and applications configured in the cluster:
+This example stops the Cluster service on all nodes in the cluster named Cluster1, which stops all services and applications configured in the cluster:
 
 ```powershell
 Stop-Cluster -Name Cluster1
@@ -107,7 +109,7 @@ Remove-ClusterNode -Cluster Cluster1 -Name Node4
 ```
 
 >[!NOTE]
-> If the node has been added to a single server, see these [manual steps](../deploy/single-server.md#change-a-single-node-to-a-multi-node-cluster-optional) to reconfigure Storage Spaces Direct.
+> If the node is added to a single server, see these [manual steps](../deploy/single-server.md#change-a-single-node-to-a-multi-node-cluster-optional) to reconfigure Storage Spaces Direct.
 
 ## Set up the cluster witness
 
@@ -164,7 +166,7 @@ Before you remove (destroy) a cluster, you must unregister it from Azure first.
 Use the `Remove-ClusterResource` cmdlet to remove one or all resources on a cluster. For more examples and usage information, see the [Remove-ClusterResource](/powershell/module/failoverclusters/remove-clusterresource) reference documentation.
 
 > [!NOTE]
-> You will need to temporarily enable Credential Security Service Provider (CredSSP) authentication to remove a cluster. For more information, see [Enable-WSManCredSSP](/powershell/module/microsoft.wsman.management/enable-wsmancredssp).
+> You need to temporarily enable Credential Security Service Provider (CredSSP) authentication to remove a cluster. For more information, see [Enable-WSManCredSSP](/powershell/module/microsoft.wsman.management/enable-wsmancredssp).
 
 The following example removes cluster resources by name on cluster Cluster1: