Merge pull request #249276 from cherylmc/fresh4

prmerger-automator[bot] · web-flow · commit 7960a5e3bcc5 · 2023-08-24T20:15:16.000Z
freshness update
diff --git a/articles/virtual-wan/azure-vpn-client-optional-configurations-windows.md b/articles/virtual-wan/azure-vpn-client-optional-configurations-windows.md
@@ -5,7 +5,7 @@ description: Learn how to configure the Azure VPN Client optional configuration
 author: cherylmc
 ms.service: virtual-wan
 ms.topic: how-to
-ms.date: 07/20/2022
+ms.date: 08/24/2023
 ms.author: cherylmc
 
 ---
diff --git a/articles/virtual-wan/install-client-certificates.md b/articles/virtual-wan/install-client-certificates.md
@@ -5,7 +5,7 @@ description: Learn how to install client certificates for User VPN P2S certifica
 author: cherylmc
 ms.service: virtual-wan
 ms.topic: how-to
-ms.date: 07/06/2022
+ms.date: 08/24/2023
 ms.author: cherylmc
 
 ---
diff --git a/articles/virtual-wan/quickstart-any-to-any-template.md b/articles/virtual-wan/quickstart-any-to-any-template.md
@@ -5,7 +5,7 @@ description: Learn how to create an any-to-any configuration using an Azure Reso
 author: cherylmc
 ms.service: virtual-wan
 ms.topic: quickstart
-ms.date: 06/14/2022
+ms.date: 08/24/2023
 ms.author: cherylmc
 ms.custom: subject-armqs, mode-arm, devx-track-arm-template
 ---
diff --git a/articles/virtual-wan/scenario-any-to-any.md b/articles/virtual-wan/scenario-any-to-any.md
@@ -7,7 +7,7 @@ author: cherylmc
 
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 04/27/2021
+ms.date: 08/24/2023
 ms.author: cherylmc
 ms.custom: fasttrack-edit
 
diff --git a/articles/virtual-wan/scenario-isolate-vnets-custom.md b/articles/virtual-wan/scenario-isolate-vnets-custom.md
@@ -7,7 +7,7 @@ author: cherylmc
 
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 04/27/2021
+ms.date: 08/24/2023
 ms.author: cherylmc
 
 ---
diff --git a/articles/virtual-wan/scenario-isolate-vnets.md b/articles/virtual-wan/scenario-isolate-vnets.md
@@ -7,7 +7,7 @@ author: cherylmc
 
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 05/26/2021
+ms.date: 08/24/2023
 ms.author: cherylmc
 ms.custom: fasttrack-edit
 
@@ -18,7 +18,7 @@ When working with Virtual WAN virtual hub routing, there are quite a few availab
 
 ## <a name="design"></a>Design
 
-In this scenario, the workload within a certain VNet remains isolated and is not able to communicate with other VNets. However, the VNets are required to reach all branches (VPN, ER, and User VPN). In order to figure out how many route tables will be needed, you can build a connectivity matrix. For this scenario it will look like the following table, where each cell represents whether a source (row) can communicate to a destination (column):
+In this scenario, the workload within a certain VNet remains isolated and isn't able to communicate with other VNets. However, the VNets are required to reach all branches (VPN, ER, and User VPN). In order to figure out how many route tables will be needed, you can build a connectivity matrix. For this scenario it will look like the following table, where each cell represents whether a source (row) can communicate to a destination (column):
 
 | From |   To |  *VNets* | *Branches* |
 | -------------- | -------- | ---------- | ---|
@@ -27,9 +27,9 @@ In this scenario, the workload within a certain VNet remains isolated and is not
 
 Each of the cells in the previous table describes whether a Virtual WAN connection (the "From" side of the flow, the row headers) communicates with a destination prefix (the "To" side of the flow, the column headers in italics). In this scenario there are no firewalls or Network Virtual Appliances, so communications flows directly over Virtual WAN (hence the word "Direct" in the table).
 
-This connectivity matrix gives us two different row patterns, which translate to two route tables. Virtual WAN already has a Default route table, so we will need another route table. For this example, we will name the route table **RT_VNET**.
+This connectivity matrix gives us two different row patterns, which translate to two route tables. Virtual WAN already has a Default route table, so we'll need another route table. For this example, we'll name the route table **RT_VNET**.
 
-VNets will be associated to this **RT_VNET** route table. Because they need connectivity to branches, branches will need to propagate to **RT_VNET** (otherwise the VNets would not learn the branch prefixes). Since the branches are always associated to the Default route table, VNets will need to propagate to the Default route table. As a result, this is the final design:
+VNets will be associated to this **RT_VNET** route table. Because they need connectivity to branches, branches need to propagate to **RT_VNET** (otherwise the VNets wouldn't learn the branch prefixes). Since the branches are always associated to the Default route table, VNets need to propagate to the Default route table. As a result, this is the final design:
 
 * Virtual networks:
   * Associated route table: **RT_VNET**
@@ -50,7 +50,7 @@ In order to configure this scenario, take the following steps into consideration
 2. When you create the **RT_VNet** route table, configure the following settings:
 
    * **Association**: Select the VNets you want to isolate.
-   * **Propagation**: Select the option for branches, implying branch(VPN/ER/P2S) connections will propagate routes to this route table.
+   * **Propagation**: Select the option for branches, implying branch(VPN/ER/P2S) connections propagate routes to this route table.
 
 :::image type="content" source="./media/routing-scenarios/isolated/isolated-vnets.png" alt-text="Isolated VNets":::
 
diff --git a/articles/virtual-wan/scenario-shared-services-vnet.md b/articles/virtual-wan/scenario-shared-services-vnet.md
@@ -7,7 +7,7 @@ author: cherylmc
 
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 04/27/2021
+ms.date: 08/24/2023
 ms.author: cherylmc
 ms.custom: fasttrack-edit
 
@@ -32,9 +32,9 @@ We can use a connectivity matrix to summarize the requirements of this scenario:
 
 Each of the cells in the previous table describes whether a Virtual WAN connection (the "From" side of the flow, the row headers) communicates with a destination (the "To" side of the flow, the column headers in italics). In this scenario there are no firewalls or Network Virtual Appliances, so communication flows directly over Virtual WAN (hence the word "Direct" in the table).
 
-Similarly to the [Isolated VNet scenario](scenario-isolate-vnets.md), this connectivity matrix gives us two different row patterns, which translate to two route tables (the shared services VNets and the branches have the same connectivity requirements). Virtual WAN already has a Default route table, so we will need another custom route table, which we will call **RT_SHARED** in this example.
+Similarly to the [Isolated VNet scenario](scenario-isolate-vnets.md), this connectivity matrix gives us two different row patterns, which translate to two route tables (the shared services VNets and the branches have the same connectivity requirements). Virtual WAN already has a Default route table, so we'll need another custom route table, which we will call **RT_SHARED** in this example.
 
-VNets will be associated to the **RT_SHARED** route table. Because they need connectivity to branches and to the shared service VNets, the shared service VNet and branches will need to propagate to **RT_SHARED** (otherwise the VNets would not learn the branch and shared VNet prefixes). Because the branches are always associated to the Default route table, and the connectivity requirements are the same for shared services VNets, we will associate the shared service VNets to the Default route table too.
+VNets will be associated to the **RT_SHARED** route table. Because they need connectivity to branches and to the shared service VNets, the shared service VNet and branches will need to propagate to **RT_SHARED** (otherwise the VNets wouldn't learn the branch and shared VNet prefixes). Because the branches are always associated to the Default route table, and the connectivity requirements are the same for shared services VNets, we'll associate the shared service VNets to the Default route table too.
 
 As a result, this is the final design:
 
@@ -61,13 +61,13 @@ To configure the scenario, consider the following steps:
 2. Create a custom route table. In the example, we refer to the route table as **RT_SHARED**. For steps to create a route table, see [How to configure virtual hub routing](how-to-virtual-hub-routing.md). Use the following values as a guideline:
 
    * **Association**
-     * For **VNets *except* the shared services VNet**, select the VNets to isolate. This will imply that all these VNets (except the shared services VNet) will be able to reach destination based on the routes of RT_SHARED route table.
+     * For **VNets *except* the shared services VNet**, select the VNets to isolate. This implies that all these VNets (except the shared services VNet) will be able to reach destination based on the routes of RT_SHARED route table.
 
    * **Propagation**
       * For **Branches**, propagate routes to this route table, in addition to any other route tables you may have already selected. Because of this step, the RT_SHARED route table will learn routes from all branch connections (VPN/ER/User VPN).
       * For **VNets**, select the **shared services VNet**. Because of this step, RT_SHARED route table will learn routes from the shared services VNet connection.
 
-This will result in the routing configuration shown in the following figure:
+This results in the routing configuration shown in the following figure:
 
    :::image type="content" source="./media/routing-scenarios/shared-service-vnet/shared-services.png" alt-text="Diagram for shared services VNet." lightbox="./media/routing-scenarios/shared-service-vnet/shared-services.png":::
 
diff --git a/articles/virtual-wan/virtual-wan-route-table-nva-portal.md b/articles/virtual-wan/virtual-wan-route-table-nva-portal.md
@@ -6,7 +6,7 @@ author: cherylmc
 
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 08/19/2021
+ms.date: 08/24/2023
 ms.author: cherylmc
 # Customer intent: As someone with a networking background, I want to create a route table using the portal.
 ---
@@ -25,7 +25,7 @@ Verify that you have met the following criteria:
 
     * A private IP address must be assigned to the NVA network interface.
 
-    * The NVA is not deployed in the virtual hub. It must be deployed in a separate virtual network.
+    * The NVA isn't deployed in the virtual hub. It must be deployed in a separate virtual network.
 
     *  The NVA virtual network may have one or many virtual networks connected to it. In this article, we refer to the NVA virtual network as an 'indirect spoke VNet'. These virtual networks can be connected to the NVA VNet by using VNet peering. The VNet Peering links are depicted by black arrows in the above figure between VNet 1, VNet 2, and NVA VNet.
 *  You have created two virtual networks. They will be used as spoke VNets.
@@ -34,7 +34,7 @@ Verify that you have met the following criteria:
 
     * Ensure there are no virtual network gateways in any of the VNets.
 
-    * The VNets do not require a gateway subnet.
+    * The VNets don't require a gateway subnet.
 
 ## <a name="signin"></a>1. Sign in
 
@@ -99,7 +99,7 @@ Repeat the following procedure for each virtual network that you want to connect
     * **Connection name** - Name your connection.
     * **Hubs** - Select the hub you want to associate with this connection.
     * **Subscription** - Verify the subscription.
-    * **Virtual network** - Select the virtual network you want to connect to this hub. The virtual network cannot have an already existing virtual network gateway.
+    * **Virtual network** - Select the virtual network you want to connect to this hub. The virtual network can't have an already existing virtual network gateway.
 4. Click **OK** to create the connection.
 
 ## Next steps
diff --git a/articles/virtual-wan/virtual-wan-route-table-nva.md b/articles/virtual-wan/virtual-wan-route-table-nva.md
@@ -6,7 +6,7 @@ author: cherylmc
 
 ms.service: virtual-wan
 ms.topic: conceptual
-ms.date: 09/22/2020
+ms.date: 08/24/2023
 ms.author: cherylmc 
 ms.custom: devx-track-azurepowershell
 # Customer intent: As someone with a networking background, I want to work with routing tables for NVA.
@@ -35,16 +35,16 @@ Verify that you have met the following criteria:
 
 * You have a Network Virtual Appliance (NVA). This is a third-party software of your choice that is typically provisioned from Azure Marketplace in a virtual network.
 * You have a private IP assigned to the NVA network interface. 
-* The NVA cannot be deployed in the virtual hub. It must be deployed in a separate VNet. For this article, the NVA VNet is referred to as the 'DMZ VNet'.
+* The NVA can't be deployed in the virtual hub. It must be deployed in a separate VNet. For this article, the NVA VNet is referred to as the 'DMZ VNet'.
 * The ‘DMZ VNet’ may have one or many virtual networks connected to it. In this article, this VNet is referred to as ‘Indirect spoke VNet’. These VNets can be connected to the DMZ VNet using VNet peering.
 * Verify that you have 2 VNets already created. These will be used as spoke VNets. For this article, the VNet spoke address spaces are 10.0.2.0/24 and 10.0.3.0/24. If you need information on how to create a VNet, see [Create a virtual network using PowerShell](../virtual-network/quick-create-powershell.md).
 * Ensure there are no virtual network gateways in any VNets.
 
 ## <a name="signin"></a>1. Sign in
 
-Make sure you install the latest version of the Resource Manager PowerShell cmdlets. For more information about installing PowerShell cmdlets, see [How to install and configure Azure PowerShell](/powershell/azure/install-azure-powershell). This is important because earlier versions of the cmdlets do not contain the current values that you need for this exercise.
+Make sure you install the latest version of the Resource Manager PowerShell cmdlets. For more information about installing PowerShell cmdlets, see [How to install and configure Azure PowerShell](/powershell/azure/install-azure-powershell). This is important because earlier versions of the cmdlets don't contain the current values that you need for this exercise.
 
-1. Open your PowerShell console with elevated privileges, and sign in to your Azure account. This cmdlet prompts you for the sign-in credentials. After signing in, it downloads your account settings so that they are available to Azure PowerShell.
+1. Open your PowerShell console with elevated privileges, and sign in to your Azure account. This cmdlet prompts you for the sign-in credentials. After signing in, it downloads your account settings so that they're available to Azure PowerShell.
 
    ```powershell
    Connect-AzAccount
