Acrolinx flags

Author: v-regandowner

articles/storage/file-sync/file-sync-networking-overview.md

@@ -55,7 +55,7 @@ Azure File Sync requires the IP address ranges for the following services, as id
 
 If you're using Azure File Sync within Azure, even if it's in a different region, you can use the name of the service tag directly in your network security group to allow traffic to that service. To learn more, see [Network security groups](../../virtual-network/network-security-groups-overview.md).
 
-If you're using Azure File Sync on-premises, you can use the service tag API to get specific IP address ranges for your firewall's allow list. There are two methods for getting this information:
+If you're using Azure File Sync on-premises, you can use the service tag API to get specific IP address ranges for your firewall's allowlist. There are two methods for getting this information:
 
 - The current list of IP address ranges for all Azure services supporting service tags are published weekly on the Microsoft Download Center in the form of a JSON document. Each Azure cloud has its own JSON document with the IP address ranges relevant for that cloud:
     - [Azure Public](https://www.microsoft.com/download/details.aspx?id=56519)
@@ -67,10 +67,10 @@ If you're using Azure File Sync on-premises, you can use the service tag API to
     - [Azure PowerShell](/powershell/module/az.network/Get-AzNetworkServiceTag)
     - [Azure CLI](/cli/azure/network#az-network-list-service-tags)
 
-To learn more about how to use the service tag API to retrieve the addresses of your services, see [Allow list for Azure File Sync IP addresses](file-sync-firewall-and-proxy.md#allow-list-for-azure-file-sync-ip-addresses).
+To learn more about how to use the service tag API to retrieve the addresses of your services, see [Allowlist for Azure File Sync IP addresses](file-sync-firewall-and-proxy.md#allow-list-for-azure-file-sync-ip-addresses).
 
 ### Tunneling traffic over a virtual private network or ExpressRoute
-Some organizations require communication with Azure to go over a network tunnel, such as a virtual private private network (VPN) or ExpressRoute, for an additional layer of security or to ensure communication with Azure follows a deterministic route. 
+Some organizations require communication with Azure to go over a network tunnel, such as a virtual private network (VPN) or ExpressRoute, for an additional layer of security or to ensure communication with Azure follows a deterministic route. 
 
 When you establish a network tunnel between your on-premises network and Azure, you are peering your on-premises network with one or more virtual networks in Azure. A [virtual network](../../virtual-network/virtual-networks-overview.md), or VNet, is similar to a traditional network that you'd operate on-premises. Like an Azure storage account or an Azure VM, a VNet is an Azure resource that is deployed in a resource group.
 
@@ -92,7 +92,7 @@ An individual private endpoint is associated with a specific Azure virtual netwo
 
 Using private endpoints enables you to:
 - Securely connect to your Azure resources from on-premises networks using a VPN or ExpressRoute connection with private peering.
-- Secure your Azure resources by disabling the the public endpoints for Azure Files and File Sync. By default, creating a private endpoint does not block connections to the public endpoint.
+- Secure your Azure resources by disabling the public endpoints for Azure Files and File Sync. By default, creating a private endpoint does not block connections to the public endpoint.
 - Increase security for the virtual network by enabling you to block exfiltration of data from the virtual network (and peering boundaries).
 
 To create a private endpoint, see [Configuring private endpoints for Azure File Sync](file-sync-networking-endpoints.md).
@@ -101,11 +101,11 @@ To create a private endpoint, see [Configuring private endpoints for Azure File
 When you create a private endpoint, by default we also create (or update an existing) private DNS zone corresponding to the `privatelink` subdomain. For public cloud regions, these DNS zones are `privatelink.file.core.windows.net` for Azure Files and `privatelink.afs.azure.net` for Azure File Sync.
 
 > [!Note]  
-> This article uses the storage account DNS suffix for the Azure Public regions, `core.windows.net`. This commentary also applies to Azure Sovereign clouds such as the Azure US Government cloud and the Azure China cloud - just substitute the the appropriate suffixes for your environment.
+> This article uses the storage account DNS suffix for the Azure Public regions, `core.windows.net`. This commentary also applies to Azure Sovereign clouds such as the Azure US Government cloud and the Azure China cloud - just substitute the appropriate suffixes for your environment.
 
 When you create private endpoints for a storage account and a Storage Sync Service, we create A records for them in their respective private DNS zones. We also update the public DNS entry such that the regular fully qualified domain names are CNAMEs for the relevant `privatelink` name. This enables the fully qualified domain names to point at the private endpoint IP address(es) when the requester is inside of the virtual network and to point at the public endpoint IP address(es) when the requester is outside of the virtual network.
 
-For Azure Files, each private endpoint has a single fully qualified domain name, following the pattern `storageaccount.privatelink.file.core.windows.net`, mapped to one private IP address for the private endpoint. For Azure File Sync, each private endpoint has four fully qualified domain names, for the four different endpoints that Azure File Sync exposes: management, sync (primary), sync (secondary), and monitoring. The fully qualified domain names for these endpoints will normally follow the the name of the Storage Sync Service unless the name contains non-ASCII characters. For example, if your Storage Sync Service name is `mysyncservice` in the West US 2 region, the equivalent endpoints would be `mysyncservicemanagement.westus2.afs.azure.net`, `mysyncservicesyncp.westus2.afs.azure.net`, `mysyncservicesyncs.westus2.afs.azure.net`, and `mysyncservicemonitoring.westus2.afs.azure.net`. Each private endpoint for a Storage Sync Service will contain 4 distinct IP addresses. 
+For Azure Files, each private endpoint has a single fully qualified domain name, following the pattern `storageaccount.privatelink.file.core.windows.net`, mapped to one private IP address for the private endpoint. For Azure File Sync, each private endpoint has four fully qualified domain names, for the four different endpoints that Azure File Sync exposes: management, sync (primary), sync (secondary), and monitoring. The fully qualified domain names for these endpoints will normally follow the name of the Storage Sync Service unless the name contains non-ASCII characters. For example, if your Storage Sync Service name is `mysyncservice` in the West US 2 region, the equivalent endpoints would be `mysyncservicemanagement.westus2.afs.azure.net`, `mysyncservicesyncp.westus2.afs.azure.net`, `mysyncservicesyncs.westus2.afs.azure.net`, and `mysyncservicemonitoring.westus2.afs.azure.net`. Each private endpoint for a Storage Sync Service will contain 4 distinct IP addresses. 
 
 Since your Azure private DNS zone is connected to the virtual network containing the private endpoint, you can observe the DNS configuration when by calling the `Resolve-DnsName` cmdlet from PowerShell in an Azure VM (alternately `nslookup` in Windows and Linux):
 
@@ -159,9 +159,9 @@ IP4Address : 52.239.194.40
 
 This reflects the fact that the Azure Files and Azure File Sync can expose both their public endpoints and one or more private endpoints per resource. To ensure that the fully qualified domain names for your resources resolve to the private endpoints private IP addresses, you must change the configuration on your on-premises DNS servers. This can be accomplished in several ways:
 
-- Modifying the hosts file on your clients to make the fully qualified domain names for your storage accounts and Storage Sync Services resolve to the desired private IP addresses. This is strongly discouraged for production environments, since you will need make these changes to every client that needs to access your private endpoints. Changes to your private endpoints/resources (deletions, modifications, etc.) will not be automatically handled.
+- Modifying the hosts file on your clients to make the fully qualified domain names for your storage accounts and Storage Sync Services resolve to the desired private IP addresses. This is strongly discouraged for production environments, since you will need to make these changes to every client that needs to access your private endpoints. Changes to your private endpoints/resources (deletions, modifications, etc.) will not be automatically handled.
 - Creating DNS zones on your on-premises servers for `privatelink.file.core.windows.net` and `privatelink.afs.azure.net` with A records for your Azure resources. This has the advantage that clients in your on-premises environment will be able to automatically resolve Azure resources without needing to configure each client, however this solution is similarly brittle to modifying the hosts file because changes are not reflected. Although this solution is brittle, it may be the best choice for some environments.
-- Forward the `core.windows.net` and `afs.azure.net` zones from your on-premises DNS servers to your Azure private DNS zone. The Azure private DNS host can be reached through a special IP address (`168.63.129.16`) that is only accessible inside virtual networks that are linked to the Azure private DNS zone. To workaround this limitation, you can run additional DNS servers within your virtual network that will forward `core.windows.net` and `afs.azure.net` to the equivalent Azure private DNS zones. To simplify this set up, we have provided PowerShell cmdlets that will auto-deploy DNS servers in your Azure virtual network and configure them as desired. To learn how to set up DNS forwarding, see [Configuring DNS with Azure Files](../files/storage-files-networking-dns.md?toc=%2fazure%2fstorage%2ffilesync%2ftoc.json).
+- Forward the `core.windows.net` and `afs.azure.net` zones from your on-premises DNS servers to your Azure private DNS zone. The Azure private DNS host can be reached through a special IP address (`168.63.129.16`) that is only accessible inside virtual networks that are linked to the Azure private DNS zone. To work around this limitation, you can run additional DNS servers within your virtual network that will forward `core.windows.net` and `afs.azure.net` to the equivalent Azure private DNS zones. To simplify this set up, we have provided PowerShell cmdlets that will auto-deploy DNS servers in your Azure virtual network and configure them as desired. To learn how to set up DNS forwarding, see [Configuring DNS with Azure Files](../files/storage-files-networking-dns.md?toc=%2fazure%2fstorage%2ffilesync%2ftoc.json).
 
 ## Encryption in transit
 Connections made from the Azure File Sync agent to your Azure file share or Storage Sync Service are always encrypted. Although Azure storage accounts have a setting to disable requiring encryption in transit for communications to Azure Files (and the other Azure storage services that are managed out of the storage account), disabling this setting will not affect Azure File Sync's encryption when communicating with the Azure Files. By default, all Azure storage accounts have encryption in transit enabled.
@@ -170,4 +170,4 @@ For more information about encryption in transit, see [requiring secure transfer
 
 ## See also
 - [Planning for an Azure File Sync deployment](file-sync-planning.md)
-- [Deploy Azure File Sync](file-sync-deployment-guide.md)
+- [Deploy Azure File Sync](file-sync-deployment-guide.md)