Merge pull request #300641 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: v-alje

articles/application-gateway/for-containers/faq.yml

@@ -34,7 +34,7 @@ sections:
     questions:
       - question: How does Application Gateway for Containers support high availability and scalability?
         answer: |
-          Application Gateway for Containers automatically ensures underlying components are spread across availability zones for increased resiliency, if the Azure region supports it.  If the region doesn't support zones, fault domains and update domains be used to help mitigate impact during planned maintainence and unexpected failures. 
+          Application Gateway for Containers automatically ensures underlying components are spread across availability zones for increased resiliency, if the Azure region supports it.  If the region doesn't support zones, fault domains and update domains be used to help mitigate impact during planned maintenance and unexpected failures. 
         
           > [!WARNING] 
           > Ensure the Application Gateway for Containers subnet is a /24 prior to upgrading. Upgrading from CNI to CNI Overlay with a larger subnet (i.e., /23) will lead to an outage and require the Application Gateway for Containers subnet to be recreated with a /24 subnet size.

articles/application-gateway/for-containers/how-to-cert-manager-lets-encrypt-ingress-api.md

@@ -177,7 +177,7 @@ spec:
   tls:
   - hosts:
     - backend-v1.contoso.com
-    # - backend-v2.contoso.com # You can uncomment this and the host line to add an aditional subject alternate name (SAN) to the certificate
+    # - backend-v2.contoso.com # You can uncomment this and the host line to add an additional subject alternate name (SAN) to the certificate
     secretName: tls-backend
   rules:
     - host: backend-v1.contoso.com
@@ -233,7 +233,7 @@ spec:
   tls:
   - hosts:
     - backend-v1.contoso.com
-    # - backend-v2.contoso.com # You can uncomment this and the host line to add an aditional subject alternate name (SAN) to the certificate
+    # - backend-v2.contoso.com # You can uncomment this and the host line to add an additional subject alternate name (SAN) to the certificate
     secretName: tls-backend
   rules:
     - host: backend-v1.contoso.com

articles/databox/data-box-deploy-export-ordered.md

@@ -180,7 +180,7 @@ Perform the following steps in the Azure portal to order a device.
 
     On the **Create new key** screen, choose settings for the new key version, and select **Create**.
 
-    ![Screen capture showing the options for generating a new version of an exsiting Azure Key Vault key to provide a customer-managed key in the Data Box export order's Security tab.](./media/data-box-deploy-export-ordered/customer-managed-key-08-b.png)
+    ![Screen capture showing the options for generating a new version of an existing Azure Key Vault key to provide a customer-managed key in the Data Box export order's Security tab.](./media/data-box-deploy-export-ordered/customer-managed-key-08-b.png)
 
     The **Encryption type** settings on the **Security** screen show your key vault and key.
 
@@ -227,7 +227,7 @@ Perform the following steps in the Azure portal to order a device.
 
     We recommend that you use a group email so that you continue to receive notifications if an admin in the group leaves.
 
-    ![Screen capture showing the resullts of adding a new shipping address on the Contact details tab of a Data Box export order.](media/data-box-deploy-export-ordered/azure-data-box-export-order-contact-details.png)
+    ![Screen capture showing the results of adding a new shipping address on the Contact details tab of a Data Box export order.](media/data-box-deploy-export-ordered/azure-data-box-export-order-contact-details.png)
 
 15. Select **Next: Review + Order>**. You must accept the terms and conditions to proceed with order creation.
 

articles/virtual-desktop/rdp-shortpath.md

@@ -114,7 +114,7 @@ The following diagram gives a high-level overview of the network connections whe
 
 #### TURN relay availability
 
-TURN relay is available in the following Azure regions:
+TURN relay is available in the following Azure regions with ACS TURN Relay (20.202.0.0/16):
 
 :::row:::
     :::column:::
@@ -188,9 +188,7 @@ Where users have RDP Shortpath for both managed network and public networks is a
 The following sections contain the source, destination and protocol requirements for your session hosts and client devices that must be allowed for RDP Shortpath to work.
 
 > [!NOTE]
-> For a relayed connection with TURN, the IP subnet `20.202.0.0/16` is shared with Azure Communication Services. However, Azure Virtual Desktop and Windows 365 will transition to `51.5.0.0/16`, which is dedicated exclusively to these services. We recommend you configure both ranges in your network environment now to ensure a seamless transition. 
->  
-> If you want to wait to use the dedicated subnet, please follow the steps in [Configure host pool networking settings](configure-rdp-shortpath.md#configure-host-pool-networking-settings) and set **RDP Shortpath for public network (via TURN/relay)** to **Disabled**. Alternatively you can disable UDP on the local device, but that will disable UDP for all connections. To disable UDP on the local device, follow the steps in [Check that UDP is enabled on Windows client devices](configure-rdp-shortpath.md#check-that-udp-is-enabled-on-windows-client-devices), but set **Turn Off UDP On Client** to **Enabled**. If you block the IP range `20.202.0.0/16` on your network and are using VPN applications, it might cause disconnection issues.
+> Starting June 15, Microsoft will begin rolling out a new TURN relay IP range, `51.5.0.0/16`, across 40 Azure regions. This new range is dedicated exclusively to Azure Virtual Desktop and Windows 365, marking a transition away from the previously shared 20.202.0.0/16 subnet used by Azure Communication Services. The upgrade is designed to enhance RDP Shortpath for Public Networks (via TURN/Relay), delivering faster, more reliable connectivity for users.
 
 #### Session host virtual network
 
@@ -212,6 +210,9 @@ The following table details the source, destination and protocol requirements fo
 | STUN infrastructure/TURN relay | Client network | Any | `20.202.0.0/16` | 3478 | UDP | Allow |
 | TURN relay | Client network | Any | `51.5.0.0/16` | 3478 | UDP | Allow |
 
+> [!NOTE]
+> From June 15th, the traffic will progressively be redirected from the current Azure Communication Service (ACS) TURN Relay range (`20.202.0.0/16`) to the newly designated subnet `51.5.0.0/16`. While this shift is designed to be seamless, it’s essential that customers preemptively configure bypass rules for the new range to maintain uninterrupted service. With both IP ranges properly bypassed, end users shouldn't experience any connectivity issues.
+
 ### Teredo support
 
 While not required for RDP Shortpath, Teredo adds extra NAT traversal candidates and increases the chance of the successful RDP Shortpath connection in IPv4-only networks. To learn how to enable Teredo on session hosts and clients, see [Enable Teredo support](configure-rdp-shortpath.md#optional-enable-teredo-support).

articles/virtual-wan/how-to-network-virtual-appliance-add-ip-configurations.md

@@ -63,7 +63,7 @@ The following section describes known limitations and considerations associated
 ### Limitations
 
 * Each NVA NIC (External or Internal) can have at most three IP-configurations. This limit is to help ensure that there are sufficient IP addresses available in the Virtual WAN hub to allocate to NVA deployments.  
-* Additonal/Auxillary NICs must have exactly one IP-configuration. You can't add additional IP addresses to Additional/Auxillary NICs.
+* Additional/Auxillary NICs must have exactly one IP-configuration. You can't add additional IP addresses to Additional/Auxillary NICs.
 * Azure Virtual WAN Hub routers initiates/accepts Border Gateway Protocol (BGP) sessions with the primary IP configuration of the internal/private NIC assigned to each NVA VM instance. Secondary IP configurations assigned to the internal/private NIC of NVA instances can't be used to establish BGP.
 * IP configurations must adhere to the following naming convention:
     * IP configurations on the private/internal NIC must have *privatenicipconfig* prefix. For example, *privatenicipconfig-1* is a valid name while *myprivateipconfig* isn't a valid name for private/internal NIC IP configurations.