Merge pull request #306913 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: PhilKang0704

articles/virtual-network/virtual-network-service-endpoints-overview.md

@@ -90,8 +90,6 @@ Service endpoints provide the following benefits:
 
   ExpressRoute: If you're using [ExpressRoute](../expressroute/expressroute-introduction.md?toc=%2fazure%2fvirtual-network%2ftoc.json) for Microsoft peering from your premises, identify the NAT IP addresses that you're using. The NAT IP addresses are either customer provided or provided by the service provider. To allow access to your service resources, you must allow these public IP addresses in the resource IP firewall setting. For more information about NAT for ExpressRoute Microsoft peering, see [ExpressRoute NAT requirements](../expressroute/expressroute-nat.md?toc=%2fazure%2fvirtual-network%2ftoc.json).
 
-![Securing Azure services to virtual networks](./media/virtual-network-service-endpoints-overview/VNet_Service_Endpoints_Overview.png)
-
 :::image type="content" source="./media/virtual-network-service-endpoints-overview/VNet_Service_Endpoints_Overview.png" alt-text="Screenshot of diagram showing virtual network service endpoints securing Azure services to virtual networks.":::
 
 ### Configuration
@@ -185,4 +183,4 @@ For FAQs, see [Virtual Network Service Endpoint FAQs](./virtual-networks-faq.md#
 
 - [Virtual Network Service Endpoint Policies](./virtual-network-service-endpoint-policies-overview.md)
 
-- [Azure Resource Manager template](https://azure.microsoft.com/resources/templates/vnet-2subnets-service-endpoints-storage-integration)
+- [Azure Resource Manager template](https://azure.microsoft.com/resources/templates/vnet-2subnets-service-endpoints-storage-integration)

articles/virtual-network/virtual-networks-faq.md

@@ -209,7 +209,7 @@ If you change your DNS server list, you need to perform a DHCP lease renewal on
 Azure-provided DNS is a multitenant DNS service from Microsoft. Azure registers all of your VMs and cloud service role instances in this service. This service provides name resolution:
 
 * By host name for VMs and role instances in the same cloud service.
-* By fully qualified domain main (FQDN) for VMs and role instances in the same virtual network.
+* By fully qualified domain name (FQDN) for VMs and role instances in the same virtual network.
 
 To learn more about DNS, see [Name resolution for resources in Azure virtual networks](virtual-networks-name-resolution-for-vms-and-role-instances.md).
 
@@ -345,7 +345,7 @@ No. You must set the [FlowTimeoutInMinutes](/powershell/module/az.network/set-az
 
 ```Powershell
 $Allvnet = Get-AzVirtualNetwork
-$time = 4 #The value should be 4 to 30 minutes (inclusive) to enable tracking, or null to disable tracking. 
+$time = 4 #The value should be from 4 to 30 minutes (inclusive) to enable tracking, or null to disable tracking. 
 ForEach ($vnet in $Allvnet)
 {
     $vnet.FlowTimeoutInMinutes = $time
@@ -506,7 +506,7 @@ Certain services (such as Azure SQL and Azure Cosmos DB) allow exceptions to the
 Turning on the service endpoints on the network side can lead to a connectivity drop, because the source IP changes from a public IPv4 address to a private address. Setting up virtual network ACLs on the Azure service side before turning on service endpoints on the network side can help avoid a connectivity drop.
 
 >[!NOTE]
-> If you enable Service Endpoint on certain services like "Microsoft.AzureActiveDirectory" you can see IPV6 address connections on Sign-In Logs. Microsoft use an internal IPV6 private range for this type of connection.
+> If you enable Service Endpoint on certain services like "Microsoft.AzureActiveDirectory" you can see IPv6 address connections on Sign-In Logs. Microsoft use an internal IPv6 private range for this type of connection.
 
 ### Do all Azure services reside in the Azure virtual network that the customer provides? How does a virtual network service endpoint work with Azure services?
 

articles/virtual-wan/whats-new.md

@@ -96,7 +96,7 @@ The following features are currently in gated public preview. After working with
 |#|Issue|Description |Date first reported|Mitigation|
 |---|---|---|---|---|
 |1.1 |On-premises  to Azure Storage accounts deployed in the same region as your Virtual WAN hub bypasses Virtual WAN routing configuration.|Traffic from on-premises ExpressRoute, Site-to-site VPN and Point-to-site VPN connections destined for same region storage account public IP addresses bypasses Virtual WAN routing configurations (routing via security appliance deployed in the Virtual WAN hub or spoke). In set-ups where routing intent private routing policy and internet routing policy are used, ExpressRoute connections are not able to reach storage account public IP addresses.| September 2023| This issue applies to storage account access over public IP. Utilize [Private Link](../private-link/private-link-overview.md) to deploy private endpoints in spoke Virtual Networks connected to Virtual WAN hub to access storage accounts over private IP. If Private Link is not a technically feasible solution, terminate on-premises connectivity on a SD-WAN or dual-role SD-WAN and Firewall [Network Virtual Appliance (NVA) deployed in the Virtual WAN hub](about-nva-hub.md). You can terminate VPN tunnels over the public Internet on the NVA public IPs  or use ExpressRoute as an underlay. Traffic forwarded to storage account public IPs from an NVA in the hub is not impacted by this issue.|
-|1.2|Traffic from a Virtual Network connected to Virtual WAN destined to Azure Storage accounts deployed in the same region as your Virtual WAN hub bypasses Virtual WAN routing configuration.|Traffic from a Virtual Network connected to Virtual WAN destined for same region storage account public IP addresses bypasses Virtual WAN routing configurations to send traffic to a security appliance deployed in another Virutal WAN spoke Virtual Network.| September 2023| This issue applies to storage account access over public IP. Utilize [Private Link](../private-link/private-link-overview.md) to deploy private endpoints in spoke Virtual Networks connected to Virtual WAN hub to access storage accounts over private IP. If Private Link is not a technically feasible solution, deploy and configure routing to a security appliance in the hub as instead of another Virtual WAN spoke. This mitigation only applies to traffic from Virtual Networks and does **not** apply to traffic from on-premises. Reference Known Issue #1.1 for guidance related to on-premises connections.|
+|1.2|Traffic from a Virtual Network connected to Virtual WAN destined to Azure Storage accounts deployed in the same region as your Virtual WAN hub bypasses Virtual WAN routing configuration.|Traffic from a Virtual Network connected to Virtual WAN destined for same region storage account public IP addresses bypasses Virtual WAN routing configurations to send traffic to a security appliance deployed in another Virtual WAN spoke Virtual Network.| September 2023| This issue applies to storage account access over public IP. Utilize [Private Link](../private-link/private-link-overview.md) to deploy private endpoints in spoke Virtual Networks connected to Virtual WAN hub to access storage accounts over private IP. If Private Link is not a technically feasible solution, deploy and configure routing to a security appliance in the hub as instead of another Virtual WAN spoke. This mitigation only applies to traffic from Virtual Networks and does **not** apply to traffic from on-premises. Reference Known Issue #1.1 for guidance related to on-premises connections.|
 |2| Default routes (0/0) won't propagate inter-hub |0/0 routes won't propagate between two virtual WAN hubs. | June 2020 |  None. Note: While the Virtual WAN team has fixed the issue, wherein static routes defined in the static route section of the VNet peering page propagate to route tables listed in "propagate to route tables" or the labels listed in "propagate to route tables" on the VNet connection page, default routes (0/0) won't propagate inter-hub. |
 |3| Two ExpressRoute circuits in the same peering location connected to multiple hubs |If you have two ExpressRoute circuits in the same peering location, and both of these circuits are connected to multiple virtual hubs in the same Virtual WAN, then connectivity to your Azure resources might be impacted. | July 2023 | Make sure each virtual hub has at least 1 virtual network connected to it. This ensures connectivity to your Azure resources. The Virtual WAN team is also working on a fix for this issue. |
 |4| ExpressRoute ECMP Support | Today, ExpressRoute ECMP isn't enabled by default for virtual hub deployments. When 1 or more ExpressRoute circuits are connected to a Virtual WAN hub, ECMP enables traffic from spoke virtual networks to on-premises over ExpressRoute to be distributed across 2 ExpressRoute circuits (corresponding to up to 4 ExpressRoute links) advertising the same on-premises routes. | To enable ECMP for your environment, you can create a [route-map](route-maps-how-to.md) for your virtual hub. When you create a route-map, your virtual hub will automatically be upgraded to the latest software version that supports ECMP, regardless of whether this route-map is applied on any connections. As a result, you only need to follow steps 1-7 [here](route-maps-how-to.md#configuration-workflow). If you do not plan to use the route-map, you can delete the route-map after step 7 is complete, as hubs with a route-map will incur additional cost. It is also recommended to first try creating a route-map in your test environment and validating routing and connectivity before creating a route-map in your production environment.  |