Fix PR review blocking issues

duongau · duongau · commit 862af6d98df9 · 2025-11-10T16:54:16.000-08:00
- Fixed grammar: 'set up' → 'setup' (noun), 'an built-in' → 'a built-in', 'scenarios is' → 'scenario is'
- Fixed terminology: 'Public Azure cloud' → 'global Azure cloud', 'Shutdown' → 'Shut down' (verb), 'failover' → 'fail over' (verb)
- Removed duplication: '(virtual network)' redundancy
- Fixed typos: 'bring run' → 'being run', 'maintenances' → 'maintenance'
- Improved link anchor text and removed extraneous commas
- All fixes per PR review comment #3514454348
diff --git a/articles/expressroute/design-architecture-for-resiliency.md b/articles/expressroute/design-architecture-for-resiliency.md
@@ -31,7 +31,7 @@ There are three ExpressRoute resiliency architectures that can be utilized to en
 
 ### Maximum resiliency
 
-The Maximum resiliency architecture in ExpressRoute is structured to eliminate any single point of failure within the Microsoft network path. This set up is achieved by configuring a pair of circuits across two distinct locations for site diversity with ExpressRoute. The objective of Maximum resiliency is to enhance reliability, resiliency, and availability, as a result ensuring the highest level of resilience for business and/or mission-critical workloads. For such operations, we recommend that you configure maximum resiliency. This architectural design is recommended as part of the [Well Architected Framework](/azure/well-architected/service-guides/azure-expressroute#reliability) under the reliability pillar. The ExpressRoute engineering team developed a [guided portal experience](expressroute-howto-circuit-portal-resource-manager.md?pivots=expressroute-preview) to assist you in configuring maximum resiliency.
+The Maximum resiliency architecture in ExpressRoute is structured to eliminate any single point of failure within the Microsoft network path. This setup is achieved by configuring a pair of circuits across two distinct locations for site diversity with ExpressRoute. The objective of Maximum resiliency is to enhance reliability, resiliency, and availability, as a result ensuring the highest level of resilience for business and/or mission-critical workloads. For such operations, we recommend that you configure maximum resiliency. This architectural design is recommended as part of the [Well Architected Framework](/azure/well-architected/service-guides/azure-expressroute#reliability) under the reliability pillar. The ExpressRoute engineering team developed a [guided portal experience](expressroute-howto-circuit-portal-resource-manager.md?pivots=expressroute-preview) to assist you in configuring maximum resiliency.
 
 :::image type="content" source="./media/expressroute-howto-circuit-portal-resource-manager/maximum-resiliency.png" alt-text="Diagram of maximum resiliency for an ExpressRoute connection.":::
 
diff --git a/articles/expressroute/expressroute-howto-linkvnet-arm.md b/articles/expressroute/expressroute-howto-linkvnet-arm.md
@@ -107,7 +107,7 @@ $connection = New-AzVirtualNetworkGatewayConnection -Name "ERConnection" -Resour
 You can share an ExpressRoute circuit across multiple subscriptions. The following figure shows a simple schematic of how sharing works for ExpressRoute circuits across multiple subscriptions.
 
 > [!NOTE]
-> Connecting virtual networks between Azure sovereign clouds and Public Azure cloud is not supported. You can only link virtual networks from different subscriptions in the same cloud.
+> Connecting virtual networks between Azure sovereign clouds and global Azure cloud is not supported. You can only link virtual networks from different subscriptions in the same cloud.
 
 Each of the smaller clouds within the large cloud is used to represent subscriptions that belong to different departments within an organization. Each of the departments within the organization uses their own subscription for deploying their services--but they can share a single ExpressRoute circuit to connect back to your on-premises network. A single department (in this example: IT) can own the ExpressRoute circuit. Other subscriptions within the organization may use the ExpressRoute circuit.
 
@@ -124,7 +124,7 @@ The 'circuit owner' is an authorized Power User of the ExpressRoute circuit reso
 The circuit owner has the power to modify and revoke authorizations at any time. Revoking an authorization results in all link connections being deleted from the subscription whose access was revoked.
 
   > [!NOTE]
-  > Circuit owner is not an built-in RBAC role or defined on the ExpressRoute resource.
+  > Circuit owner is not a built-in RBAC role or defined on the ExpressRoute resource.
   > The definition of the circuit owner is any role with the following access:
   > - Microsoft.Network/expressRouteCircuits/authorizations/write
   > - Microsoft.Network/expressRouteCircuits/authorizations/read
@@ -257,7 +257,7 @@ With Virtual Network Peering and UDR support, FastPath will send traffic directl
 
 With FastPath and Private Link, Private Link traffic sent over ExpressRoute bypasses the ExpressRoute virtual network gateway in the data path. With both of these features enabled, FastPath will directly send traffic to a Private Endpoint deployed in a "spoke" Virtual Network.
 
-This scenarios is Generally Available for limited scenarios with connections associated to 10 Gbps and 100 Gbps ExpressRoute Direct circuits. To enable, follow the below guidance:
+This scenario is Generally Available for limited scenarios with connections associated to 10 Gbps and 100 Gbps ExpressRoute Direct circuits. To enable, follow the below guidance:
 1. Complete this [Microsoft Form](https://aka.ms/fplimitedga) to request to enroll your subscription. Requests may take up to 4 weeks to complete, so plan deployments accordingly.
 2. Once you receive a confirmation from Step 1, run the following Azure PowerShell command in the target Azure subscription.
  ```azurepowershell-interactive
diff --git a/articles/expressroute/expressroute-howto-linkvnet-cli.md b/articles/expressroute/expressroute-howto-linkvnet-cli.md
@@ -52,7 +52,7 @@ az network vpn-connection create --name ERConnection --resource-group ExpressRou
 You can share an ExpressRoute circuit across multiple subscriptions. The following figure shows a simple schematic of how sharing works for ExpressRoute circuits across multiple subscriptions.
 
 > [!NOTE]
-> Connecting virtual networks between Azure sovereign clouds and Public Azure cloud is not supported. You can only link virtual networks from different subscriptions in the same cloud.
+> Connecting virtual networks between Azure sovereign clouds and global Azure cloud is not supported. You can only link virtual networks from different subscriptions in the same cloud.
 
 Each of the smaller clouds within the large cloud is used to represent subscriptions that belong to different departments within an organization. Each of the departments within the organization uses their own subscription for deploying their services--but they can share a single ExpressRoute circuit to connect back to your on-premises network. A single department (in this example: IT) can own the ExpressRoute circuit. Other subscriptions within the organization may use the ExpressRoute circuit.
 
@@ -70,7 +70,7 @@ The 'Circuit Owner' is an authorized Power User of the ExpressRoute circuit reso
 The Circuit Owner has the power to modify and revoke authorizations at any time. When an authorization is revoked, all link connections are deleted from the subscription whose access was revoked.
 
   > [!NOTE]
-  > Circuit owner is not an built-in RBAC role or defined on the ExpressRoute resource.
+  > Circuit owner is not a built-in RBAC role or defined on the ExpressRoute resource.
   > The definition of the circuit owner is any role with the following access:
   >- Microsoft.Network/expressRouteCircuits/authorizations/write
   >- Microsoft.Network/expressRouteCircuits/authorizations/read
diff --git a/articles/expressroute/expressroute-howto-linkvnet-portal-resource-manager.md b/articles/expressroute/expressroute-howto-linkvnet-portal-resource-manager.md
@@ -18,7 +18,7 @@ ms.custom: sfi-image-nochange
 > * [Azure CLI](expressroute-howto-linkvnet-cli.md)
 > * [PowerShell (classic)](expressroute-howto-linkvnet-classic.md)
 
-This article helps you create a connection to link a virtual network (virtual network) to Azure ExpressRoute circuits using the Azure portal. The virtual networks that you connect to your Azure ExpressRoute circuit can either be in the same subscription or part of another subscription.
+This article helps you create a connection to link a virtual network to Azure ExpressRoute circuits using the Azure portal. The virtual networks that you connect to your Azure ExpressRoute circuit can either be in the same subscription or part of another subscription.
 
 :::image type="content" source="./media/expressroute-howto-linkvnet-portal-resource-manager/gateway-circuit.png" alt-text="Diagram showing a virtual network linked to an ExpressRoute circuit." lightbox="./media/expressroute-howto-linkvnet-portal-resource-manager/gateway-circuit.png":::
 
@@ -114,7 +114,7 @@ You can share an ExpressRoute circuit across multiple subscriptions. The followi
 Each of the smaller clouds within the large cloud is used to represent subscriptions that belong to different departments within an organization. Each of the departments within the organization uses their own subscription for deploying their services--but they can share a single ExpressRoute circuit to connect back to your on-premises network. A single department (in this example: IT) can own the ExpressRoute circuit. Other subscriptions within the organization may use the ExpressRoute circuit.
 
 > [!NOTE]
-> * Connecting virtual networks between Azure sovereign clouds and Public Azure cloud is not supported. You can only link virtual networks from different subscriptions in the same cloud.
+> * Connecting virtual networks between Azure sovereign clouds and global Azure cloud is not supported. You can only link virtual networks from different subscriptions in the same cloud.
 > * Connectivity and bandwidth charges for the dedicated circuit will be applied to the ExpressRoute circuit owner. All virtual networks share the same bandwidth.
 
 ### Administration - About circuit owners and circuit users
@@ -124,7 +124,7 @@ The 'circuit owner' is an authorized Power User of the ExpressRoute circuit reso
 The circuit owner has the power to modify and revoke authorizations at any time. Revoking an authorization results in all link connections being deleted from the subscription whose access was revoked.
 
   > [!NOTE]
-  > Circuit owner is not an built-in RBAC role or defined on the ExpressRoute resource.
+  > Circuit owner is not a built-in RBAC role or defined on the ExpressRoute resource.
   > The definition of the circuit owner is any role with the following access:
   > - Microsoft.Network/expressRouteCircuits/authorizations/write
   > - Microsoft.Network/expressRouteCircuits/authorizations/read
@@ -216,7 +216,7 @@ You can delete a connection and unlink your virtual network to an ExpressRoute c
 
 In this tutorial, you learned how to connect a virtual network to a circuit in the same subscription and in a different subscription. For more information about ExpressRoute gateways, see: [ExpressRoute virtual network gateways](expressroute-about-virtual-network-gateways.md).
 
-To learn how to configure, route filters for Microsoft peering using the Azure portal, advance to the next tutorial.
+To learn how to configure route filters for Microsoft peering using the Azure portal, advance to the next tutorial.
 
 > [!div class="nextstepaction"]
 > [Configure route filters for Microsoft peering](how-to-routefilter-portal.md)
diff --git a/articles/expressroute/how-to-configure-connection-monitor.md b/articles/expressroute/how-to-configure-connection-monitor.md
@@ -45,7 +45,7 @@ Create a workspace in the subscription that has the VNets linked to the ExpressR
 1. Sign in to the [Azure portal](https://portal.azure.com). From the subscription with the virtual networks connected to your ExpressRoute circuit, select **+ Create a resource**. Search for *Log Analytics Workspace*, then select **Create**.
 
    > [!NOTE]
-   > You can create a new workspace or use an existing one. If using an existing workspace, ensure it's been migrated to the new query language. [More information...](/azure/azure-monitor/logs/log-query-overview)
+   > You can create a new workspace or use an existing one. If using an existing workspace, ensure it's been migrated to the new query language. For more information, see [Log queries in Azure Monitor](/azure/azure-monitor/logs/log-query-overview).
 
 1. Create a workspace by entering or selecting the following information:
 
@@ -143,7 +143,7 @@ Ensure firewall rules allow TCP or ICMP packets between source and destination s
 Run the [EnableRules](https://aka.ms/npmpowershellscript) PowerShell script (downloaded earlier) in a PowerShell window with administrative privileges. This script creates the necessary registry keys and Windows Firewall rules.
 
 > [!NOTE]
-> The script configures Windows Firewall rules only on the server where it's bring run. Ensure network firewalls allow traffic for the TCP port used by Connection Monitor.
+> The script configures Windows Firewall rules only on the server where it's being run. Ensure network firewalls allow traffic for the TCP port used by Connection Monitor.
 
 #### Linux
 
diff --git a/articles/expressroute/planned-maintenance.md b/articles/expressroute/planned-maintenance.md
@@ -52,13 +52,13 @@ After you complete the activation of an ExpressRoute circuit and before being us
 
 The process of validation of ExpressRoute circuit failover can be executed in two steps:
 
-1. Shutdown the BGP session between your on-premises edge router and the primary connection on the MSEE router. This forces the traffic only through the secondary connection. You can monitor the traffic statistics on the MSEE connection using the [`Get-AzExpressRouteCircuitStats`](expressroute-troubleshooting-expressroute-overview.md#confirm-the-traffic-flow) command. The **BitsInPerSecond** and **BitsOutPerSecond** traffic metrics should only increment on the path that is currently active.  
+1. Shut down the BGP session between your on-premises edge router and the primary connection on the MSEE router. This forces the traffic only through the secondary connection. You can monitor the traffic statistics on the MSEE connection using the [`Get-AzExpressRouteCircuitStats`](expressroute-troubleshooting-expressroute-overview.md#confirm-the-traffic-flow) command. The **BitsInPerSecond** and **BitsOutPerSecond** traffic metrics should only increment on the path that is currently active.  
 
     :::image type="content" source="./media/planned-maintenance/primary-down.png" alt-text="Diagram of BGP peering down for primary connection of an ExpressRoute circuit.":::
 
     When the test is completed successful, move to the second step.
 
-1. Shutdown the BGP session between your on-premises edge router and the secondary MSEE connection. Repeat the verification actions in Step 1 to validate the traffic is only incrementing on the primary path.
+1. Shut down the BGP session between your on-premises edge router and the secondary MSEE connection. Repeat the verification actions in Step 1 to validate the traffic is only incrementing on the primary path.
 
     :::image type="content" source="./media/planned-maintenance/secondary-down.png" alt-text="Diagram of BGP peering down for secondary connection of an ExpressRoute circuit.":::
 
@@ -71,7 +71,7 @@ The failover validation of an ExpressRoute circuit reduces the risk of outages d
 If the verification of ExpressRoute circuit failover hasn't been completed and the ExpressRoute circuit is already in production, it's never too late to schedule a customer’s maintenance, out of working hours, and proceed with failover test. 
 
 > [!NOTE]
-> As general guideline, terminating ExpressRoute BGP connections on stateful devices (such as firewalls) can cause issues with failover during planned or unplanned maintenances by Microsoft or your ExpressRoute service provider. You should evaluate your set up to ensure your traffic will failover properly, and when possible, terminate BGP sessions on stateless devices.
+> As general guideline, terminating ExpressRoute BGP connections on stateful devices (such as firewalls) can cause issues with failover during planned or unplanned maintenance by Microsoft or your ExpressRoute service provider. You should evaluate your setup to ensure your traffic will fail over properly, and when possible, terminate BGP sessions on stateless devices.
 
 ##	Monitor of ExpressRoute circuit
 
