acrolinx fixes

Author: Manika Dhiman

azure-local/concepts/data-collection.md

@@ -16,12 +16,12 @@ ms.date: 02/27/2025
 
 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
 
@@ -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

azure-local/manage/cluster-powershell.md

@@ -21,7 +21,7 @@ You can use Windows PowerShell to manage resources and configure features on you
 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).
 
@@ -32,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:
@@ -86,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
@@ -109,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
 
@@ -166,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:
 

azure-local/manage/convert-to-stretched-cluster.md

@@ -38,24 +38,24 @@ Whenever you add or remove a server, perform cluster validation afterwards to en
 
 ## Before you add server nodes
 
-Stretched clusters require the same number of server nodes and the same number of drives in each site. When adding servers to an Azure Stack HCI cluster, their drives are automatically added to a single storage pool. In a stretched cluster however, each site must have its own storage pool.
+Stretched clusters require the same number of server nodes and the same number of drives in each site. When you add servers to an Azure Stack HCI cluster, their drives are automatically added to a single storage pool. In a stretched cluster however, each site must have its own storage pool.
 
 To ensure that separate storage pools are created, sites must be created first before new server nodes can be added. Once the sites are created, the server nodes can be added to the cluster and its own pool created, one for each site.
 
 ## Create an additional site
 
 Azure Stack HCI automatically creates a site when you create a (non-stretched) cluster. Because the cluster is created in a single site, server nodes are added to this site and a single drive pool is created.
 
-Normally, when creating additional sites, the [New-ClusterFaultDomain](/powershell/module/failoverclusters/new-clusterfaultdomain) cmdlet is used. However, you cannot add server nodes to a site when the servers are not a part of the cluster.  
+Normally, when creating additional sites, the [New-ClusterFaultDomain](/powershell/module/failoverclusters/new-clusterfaultdomain) cmdlet is used. However, you can't add server nodes to a site when the servers aren't a part of the cluster.  
 
-Much like when you [Add or remove servers](add-cluster.md) to an Azure Stack HCI cluster using Windows Admin Center, the [Get-ClusterFaultDomainXML](/powershell/module/failoverclusters/get-clusterfaultdomainxml) and [Set-ClusterFaultDomainXML](/powershell/module/failoverclusters/set-clusterfaultdomainxml) cmdlets are used to create an XML file that specifies the sites and nodes in them. When additional server nodes are added to the cluster, they are added to the new site and the second site's drive pool is created.
+Much like when you [Add or remove servers](add-cluster.md) to an Azure Stack HCI cluster using Windows Admin Center, the [Get-ClusterFaultDomainXML](/powershell/module/failoverclusters/get-clusterfaultdomainxml) and [Set-ClusterFaultDomainXML](/powershell/module/failoverclusters/set-clusterfaultdomainxml) cmdlets are used to create an XML file that specifies the sites and nodes in them. When additional server nodes are added to the cluster, they're added to the new site and the second site's drive pool is created.
 
 You can add additional servers simultaneously using the [Add-ClusterNode](/powershell/module/failoverclusters/add-clusternode) cmdlet, which adds each new server's drives at the same time.
 
 Typically, you manage clusters from a remote client computer, rather than on a server in the cluster. This remote computer is called the management computer.
 
 >[!NOTE]
->When running PowerShell commands from a management computer, include the `-Cluster` parameter with the name of the cluster you are managing.
+>When running PowerShell commands from a management computer, include the `-Cluster` parameter with the name of the cluster you're managing.
 
 Ok, let's begin:
 
@@ -65,7 +65,7 @@ Ok, let's begin:
     Get-ClusterFaultDomainXML | out-file sites.xml
     ```
 
-1. Navigate to where the `Sites.xml` file is located on your management computer and open the file. For example, if there are two nodes currently in the cluster, the `Sites.xml` file will look like this:
+1. Navigate to where the `Sites.xml` file is located on your management computer and open the file. For example, if there are two nodes currently in the cluster, the `Sites.xml` file looks like this:
 
     ```PowerShell
     <Topology>
@@ -106,7 +106,7 @@ Ok, let's begin:
 
 ## Add new server nodes
 
-Once the sites have been created, you next add the new servers to the cluster. These servers would be added to the new site as specified previously and a new pool of the drives is also created.
+Once the sites are created, you next add the new servers to the cluster. These servers would be added to the new site as specified previously and a new pool of the drives is also created.
 
 1. Using the `Add-ClusterNode` cmdlet, add the new server nodes to the cluster:
 
@@ -130,7 +130,7 @@ Once the sites have been created, you next add the new servers to the cluster. T
 
 Creating the virtual disks on the secondary site and setting up Storage Replica is a manual process. To see all the virtual disks currently in the cluster, use the [Get-VirtualDisk](/powershell/module/storage/get-virtualdisk) cmdlet.  
 
-With Storage Replica, all disks must be of the same size and attributes. When creating the disks on the secondary site, the same method of virtual disk creation and disk resiliency that you used for the primary site nodes. Storage Replica also requires a log drive for each site to perform replication.  
+With Storage Replica, all disks must be of the same size and attributes. When you create the disks on the secondary site, use the same method of virtual disk creation and disk resiliency that you used for the primary site nodes. Storage Replica also requires a log drive for each site to perform replication.  
 
 ## Next steps
 

azure-local/manage/create-stretched-volumes.md

@@ -16,7 +16,7 @@ ms.date: 02/27/2025
 
 This article describes how to create volumes and set up replication for stretched clusters in Azure Stack HCI using Windows Admin Center and PowerShell.
 
-We'll create volumes on four servers in two sites, two servers per site as an example. Keep in mind however, that if you want to create three-way mirror volumes, you need at least six servers, three servers per site.
+We create volumes on four servers in two sites, two servers per site as an example. Keep in mind however, that if you want to create three-way mirror volumes, you need at least six servers, three servers per site.
 
 ## Stretched volumes and replication using Windows Admin Center
 
@@ -150,7 +150,7 @@ Test-SRTopology -SourceComputerName Server1 -SourceVolumeName W: -SourceLogVolum
 
 ### Step 2: Create the replication partnership
 
-Now that you completed the `Test-SRTopology` tests, you are ready to configure Storage Replica and create the replication partnership. In a nutshell, we'll configure Storage Replica by creating replication groups (RG) for each site and specifying the data volumes and log volumes for both the source server nodes in Site1 (Server1, Server2) and the destination (replicated) server nodes in Site2 (Server3, Server4).
+Now that you completed the `Test-SRTopology` tests, you're ready to configure Storage Replica and create the replication partnership. In a nutshell, we'll configure Storage Replica by creating replication groups (RG) for each site and specifying the data volumes and log volumes for both the source server nodes in Site1 (Server1, Server2) and the destination (replicated) server nodes in Site2 (Server3, Server4).
 
 Let's begin:
 
@@ -160,7 +160,7 @@ Let's begin:
    Add-ClusterSharedVolume -Name "Cluster Virtual Disk (Site1)"
    ```
 
-1. The Available Storage group should be "owned" by the node it is currently sitting on. The group can be moved to Server1 using:
+1. The Available Storage group should be "owned" by the node it's currently sitting on. The group can be moved to Server1 using:
 
    ```powershell
    Move-ClusterGroup -Name "Available Storage" -Node Server1

azure-local/manage/languages.md

@@ -65,7 +65,7 @@ To manually obtain and add language packs to the operating system:
 
     To learn more, see [Add languages to Windows images](/windows-hardware/manufacture/desktop/add-language-packs-to-windows).
 
-1. We recommend adding Language Features on Demand (FODs) to enable additional functionality to the language you added, as in the following example:
+1. We recommend adding Language Features on Demand (FODs) to enable other functionality to the language you added, as in the following example:
 
     ```DOS
     dism /online /add-capability /capabilityname:Language.Basic~~~de-de~0.0.1.0