Merge pull request #291509 from duongau/erpublicpeering

denrea · web-flow · commit 6c1f69341085 · 2024-12-09T13:12:37.000-08:00
[SCOPED] Removing ExpressRoute Public Peering from all Azure Content
diff --git a/articles/app-service/environment/app-service-app-service-environment-network-configuration-expressroute.md b/articles/app-service/environment/app-service-app-service-environment-network-configuration-expressroute.md
@@ -81,7 +81,7 @@ The combined effect of this configuration is that the subnet-level UDR takes pre
 > [!IMPORTANT]
 > The routes defined in a UDR must be specific enough to take precedence over any routes that are advertised by the ExpressRoute configuration. The example described in the next section uses the broad 0.0.0.0/0 address range. This range can accidentally be overridden by route advertisements that use more specific address ranges.
 >
-> App Service Environment isn't supported with ExpressRoute configurations that cross-advertise routes from the public peering path to the private peering path. ExpressRoute configurations that have public peering configured receive route advertisements from Microsoft for a large set of Microsoft Azure IP address ranges. If these address ranges are cross-advertised on the private peering path, all outbound network packets from the App Service Environment subnet are force tunneled to the customer's on-premises network infrastructure. This network flow isn't currently supported with App Service Environment. One solution is to stop cross-advertising routes from the public peering path to the private peering path.
+> App Service Environment isn't supported with ExpressRoute configurations that cross-advertise routes from the Microsoft peering path to the private peering path. ExpressRoute configurations that have Microsoft peering configured receive route advertisements from Microsoft for a large set of Microsoft Azure IP address ranges. If these address ranges are cross-advertised on the private peering path, all outbound network packets from the App Service Environment subnet are force tunneled to the customer's on-premises network infrastructure. This network flow isn't currently supported with App Service Environment. One solution is to stop cross-advertising routes from the Microsoft peering path to the private peering path.
 >
 >
 
diff --git a/articles/app-service/environment/forced-tunnel-support.md b/articles/app-service/environment/forced-tunnel-support.md
@@ -56,7 +56,7 @@ If the network is already routing traffic on premises, then you need to create t
 > [!IMPORTANT]
 > The routes defined in a UDR must be specific enough to take precedence over any routes advertised by the ExpressRoute configuration. The preceding example uses the broad 0.0.0.0/0 address range. It can potentially be accidentally overridden by route advertisements that use more specific address ranges.
 >
-> App Service Environments aren't supported with ExpressRoute configurations that cross-advertise routes from the public-peering path to the private-peering path. ExpressRoute configurations with public peering configured receive route advertisements from Microsoft. The advertisements contain a large set of Microsoft Azure address ranges. If the address ranges are cross-advertised on the private-peering path, all outbound network packets from the App Service Environment's subnet are routed to a customer's on-premises network infrastructure. This network flow is not supported by default with App Service Environments. One solution to this problem is to stop cross-advertising routes from the public-peering path to the private-peering path. Another solution is to enable your App Service Environment to work in a forced tunnel configuration.
+> App Service Environments aren't supported with ExpressRoute configurations that cross-advertise routes from the Microsoft peering path to the private-peering path. ExpressRoute configurations with Microsoft peering configured receive route advertisements from Microsoft. The advertisements contain a large set of Microsoft Azure address ranges. If the address ranges are cross-advertised on the private-peering path, all outbound network packets from the App Service Environment's subnet are routed to a customer's on-premises network infrastructure. This network flow is not supported by default with App Service Environments. One solution to this problem is to stop cross-advertising routes from the Microsoft peering path to the private-peering path. Another solution is to enable your App Service Environment to work in a forced tunnel configuration.
 
 ![Direct internet access][1]
 
diff --git a/articles/azure-cache-for-redis/cache-how-to-premium-vnet.md b/articles/azure-cache-for-redis/cache-how-to-premium-vnet.md
@@ -266,7 +266,7 @@ Connecting to an Azure Cache for Redis instance from an on-premises application
 >The routes defined in a UDR _must_ be specific enough to take precedence over any routes advertised by the ExpressRoute configuration. The following example uses the broad 0.0.0.0/0 address range and, as such, can potentially be accidentally overridden by route advertisements that use more specific address ranges.
 
 >[!WARNING]
->Azure Cache for Redis isn't supported with ExpressRoute configurations that _incorrectly cross-advertise routes from the public peering path to the private peering path_. ExpressRoute configurations that have public peering configured receive route advertisements from Microsoft for a large set of Microsoft Azure IP address ranges. If these address ranges are incorrectly cross-advertised on the private peering path, the result is that all outbound network packets from the Azure Cache for Redis instance's subnet are incorrectly force-tunneled to a customer's on-premises network infrastructure. This network flow breaks Azure Cache for Redis. The solution to this problem is to stop cross-advertising routes from the public peering path to the private peering path.
+>Azure Cache for Redis isn't supported with ExpressRoute configurations that _incorrectly cross-advertise routes from the Microsoft peering path to the private peering path_. ExpressRoute configurations that have Microsoft peering configured receive route advertisements from Microsoft for a large set of Microsoft Azure IP address ranges. If these address ranges are incorrectly cross-advertised on the private peering path, the result is that all outbound network packets from the Azure Cache for Redis instance's subnet are incorrectly force-tunneled to a customer's on-premises network infrastructure. This network flow breaks Azure Cache for Redis. The solution to this problem is to stop cross-advertising routes from the Microsoft peering path to the private peering path.
 
 Background information on UDRs is available in [Virtual network traffic routing](../virtual-network/virtual-networks-udr-overview.md).
 
diff --git a/articles/azure-government/azure-secure-isolation-guidance.md b/articles/azure-government/azure-secure-isolation-guidance.md
@@ -546,7 +546,7 @@ Azure private endpoint is a network interface that connects you privately and se
 From the networking isolation standpoint, key benefits of Private Link include:
 
 - You can connect your VNet to services in Azure without a public IP address at the source or destination. Private Link handles the connectivity between the service and its consumers over the Microsoft global backbone network.
-- You can access services running in Azure from on-premises over Azure ExpressRoute private peering, VPN tunnels, and peered virtual networks using private endpoints. Private Link eliminates the need to set up public peering or traverse the Internet to reach the service.
+- You can access services running in Azure from on-premises over Azure ExpressRoute private peering, VPN tunnels, and peered virtual networks using private endpoints. Private Link eliminates the need to set up Microsoft peering or traverse the Internet to reach the service.
 - You can connect privately to services running in other Azure regions.
 
 > [!NOTE]
diff --git a/articles/backup/backup-azure-dpm-introduction.md b/articles/backup/backup-azure-dpm-introduction.md
@@ -46,7 +46,7 @@ Supported file types | These file types can be backed up with Azure Backup:<br>
 Unsupported file types | <li>Servers on case-sensitive file systems<li> hard links (skipped)<li> reparse points (skipped)<li> encrypted and compressed (skipped)<li> encrypted and sparse (skipped)<li> Compressed stream<li> parse stream
 Local storage | Each machine you want to back up must have local free storage that's at least 5% of the size of the data that's being backed up. For example, backing up 100 GB of data requires a minimum of 5 GB of free space in the scratch location.
 Vault storage | There’s no limit to the amount of data you can back up to an Azure Backup vault, but the size of a data source (for example a virtual machine or database) shouldn’t exceed 54,400 GB.
-Azure ExpressRoute | You can back up your data over Azure ExpressRoute with public peering (available for old circuits) and Microsoft peering. Backup over private peering isn't supported.<br/><br/> **With public peering**: Ensure access to the following domains/addresses:<br/><br/> URLs:<br> `www.msftncsi.com` <br> .Microsoft.com <br> .WindowsAzure.com <br> .microsoftonline.com <br> .windows.net <br>`www.msftconnecttest.com`<br><br>IP addresses<br>  20.190.128.0/18 <br>  40.126.0.0/18<br> <br/>**With Microsoft peering**, select the following services/regions and relevant community values:<br/><br/>- Microsoft Entra ID (12076:5060)<br/><br/>- Microsoft Azure Region (according to the location of your Recovery Services vault)<br/><br/>- Azure Storage (according to the location of your Recovery Services vault)<br/><br/>For more information, see [ExpressRoute routing requirements](../expressroute/expressroute-routing.md).<br/><br/>**Note**: Public peering is deprecated for new circuits.
+Azure ExpressRoute | You can back up your data over Azure ExpressRoute with Microsoft peering. Backup over private peering isn't supported.<br/><br/>**With Microsoft peering**, select the following services/regions and relevant community values:<br/><br/>- Microsoft Entra ID (12076:5060)<br/><br/>- Microsoft Azure Region (according to the location of your Recovery Services vault)<br/><br/>- Azure Storage (according to the location of your Recovery Services vault)<br/><br/>For more information, see [ExpressRoute routing requirements](../expressroute/expressroute-routing.md).<br/>
 Azure Backup agent | If DPM is running on System Center 2012 SP1, install Rollup 2 or later for DPM SP1. This is required for agent installation.<br/><br/> This article describes how to deploy the latest version of the Azure Backup agent, also known as the Microsoft Azure Recovery Service (MARS) agent. If you have an earlier version deployed, update to the latest version to ensure that backup works as expected. <br><br> [Ensure your server is running on TLS 1.2](transport-layer-security.md).
 
 Before you start, you need an Azure account with the Azure Backup feature enabled. If you don't have an account, you can create a free trial account in just a couple of minutes. Read about [Azure Backup pricing](https://azure.microsoft.com/pricing/details/backup/).
diff --git a/articles/backup/guidance-best-practices.md b/articles/backup/guidance-best-practices.md
@@ -270,7 +270,7 @@ Azure Backup requires movement of data from your workload to the Recovery Servic
 
 * **SAP HANA databases on Azure VM, SQL Server databases on Azure VM**: Requires connectivity to the Azure Backup service, Azure Storage, and Microsoft Entra ID. This can be achieved by using private endpoints or by allowing access to the required public IP addresses or FQDNs. Not allowing proper connectivity to the required Azure services may lead to failure in operations like database discovery, configuring backup, performing backups, and restoring data. For complete network guidance while using NSG tags, Azure firewall, and HTTP Proxy, refer to these [SQL](backup-sql-server-database-azure-vms.md#establish-network-connectivity) and [SAP HANA](./backup-azure-sap-hana-database.md#establish-network-connectivity) articles.
 
-* **Hybrid**: The MARS (Microsoft Azure Recovery Services) agent requires network access for all critical operations - install, configure, backup, and restore. The MARS agent can connect to the Azure Backup service over [Azure ExpressRoute](install-mars-agent.md#azure-expressroute-support) by using public peering (available for old circuits) and Microsoft peering, using [private endpoints](install-mars-agent.md#private-endpoint-support) or via [proxy/firewall with appropriate access controls](install-mars-agent.md#verify-internet-access).
+* **Hybrid**: The MARS (Microsoft Azure Recovery Services) agent requires network access for all critical operations - install, configure, backup, and restore. The MARS agent can connect to the Azure Backup service over [Azure ExpressRoute](install-mars-agent.md#azure-expressroute-support) by using Microsoft peering, using [private endpoints](install-mars-agent.md#private-endpoint-support) or via [proxy/firewall with appropriate access controls](install-mars-agent.md#verify-internet-access).
 
 ### Private Endpoints for secure access
 
diff --git a/articles/backup/microsoft-azure-backup-server-protection-v3-ur1.md b/articles/backup/microsoft-azure-backup-server-protection-v3-ur1.md
@@ -64,32 +64,16 @@ The following sections details the protection support matrix for MABS:
 
 ## Azure ExpressRoute support
 
-You can back up your data over Azure ExpressRoute with public peering (available for old circuits) and Microsoft peering. Backup over private peering isn't supported.
+You can back up your data over Azure ExpressRoute with Microsoft peering. Backup over private peering isn't supported.
 
-With public peering: Ensure access to the following domains/addresses:
-
-* URLs
-  * `www.msftncsi.com`
-  * `*.Microsoft.com`
-  * `*.WindowsAzure.com`
-  * `*.microsoftonline.com`
-  * `*.windows.net`
-  * `www.msftconnecttest.com`
-* IP addresses
-  * 20.190.128.0/18
-  * 40.126.0.0/18
-
-With Microsoft peering, select the following services/regions and relevant community values:
+Select the following services/regions and relevant community values:
 
 * Microsoft Entra ID (12076:5060)
 * Microsoft Azure Region (according to the location of your Recovery Services vault)
 * Azure Storage (according to the location of your Recovery Services vault)
 
 For more information, see the [ExpressRoute routing requirements](../expressroute/expressroute-routing.md).
 
->[!NOTE]
->Public Peering is deprecated for new circuits.
-
 ## Operating systems and applications at end of support
 
 Support for the following operating systems and applications in MABS are deprecated. We recommended you to upgrade them to continue protecting your data.
diff --git a/articles/backup/microsoft-azure-backup-server-protection-v3.md b/articles/backup/microsoft-azure-backup-server-protection-v3.md
@@ -91,32 +91,16 @@ For on-premises or hosted environments that you can't upgrade or migrate to Azur
 
 ## Azure ExpressRoute support
 
-You can back up your data over Azure ExpressRoute with public peering (available for old circuits) and Microsoft peering. Backup over private peering is not supported.
+You can back up your data over Azure ExpressRoute with Microsoft peering. Backup over private peering is not supported.
 
-With public peering: Ensure access to the following domains/addresses:
-
-* URLs
-  * `www.msftncsi.com`
-  * `*.Microsoft.com`
-  * `*.WindowsAzure.com`
-  * `*.microsoftonline.com`
-  * `*.windows.net`
-  * `www.msftconnecttest.com`
-* IP addresses
-  * 20.190.128.0/18
-  * 40.126.0.0/18
-
-With Microsoft peering, select the following services/regions and relevant community values:
+Select the following services/regions and relevant community values:
 
 * Microsoft Entra ID (12076:5060)
 * Microsoft Azure Region (according to the location of your Recovery Services vault)
 * Azure Storage (according to the location of your Recovery Services vault)
 
 For more details, see the [ExpressRoute routing requirements](../expressroute/expressroute-routing.md).
 
->[!NOTE]
->Public Peering is deprecated for new circuits.
-
 ## Cluster support
 
 Azure Backup Server can protect data in the following clustered applications:
diff --git a/articles/migrate/common-questions-appliance.md b/articles/migrate/common-questions-appliance.md
@@ -45,7 +45,7 @@ The appliance can be deployed using a couple of methods:
 The appliance can connect to Azure using public or private networks or using Azure ExpressRoute.
 
 - Make sure the appliance can connect to these [Azure URLs](./migrate-appliance.md#url-access). 
-- You can use ExpressRoute with Microsoft peering. Public peering is deprecated, and isn't available for new ExpressRoute circuits.
+- You can use ExpressRoute with Microsoft peering.
 
 ## Does appliance analysis affect performance?
 
diff --git a/articles/migrate/replicate-using-expressroute.md b/articles/migrate/replicate-using-expressroute.md
@@ -175,7 +175,7 @@ For proxy bypass, you can add a proxy bypass rule for the cache storage account
 
 ## Replicate data by using an ExpressRoute circuit with Microsoft peering
 
-You can use Microsoft peering or an existing public peering domain (deprecated for new ExpressRoute connections) to route your replication traffic through an ExpressRoute circuit.
+You can use Microsoft peering to route your replication traffic through an ExpressRoute circuit.
 
 ![Diagram that shows replication with Microsoft peering.](./media/replicate-using-expressroute/replication-with-microsoft-peering.png)
 
diff --git a/articles/site-recovery/azure-stack-site-recovery.md b/articles/site-recovery/azure-stack-site-recovery.md
@@ -51,7 +51,7 @@ Replication works as follows:
 5. The configuration server orchestrates replication management with Azure (port HTTPS 443 outbound).
 6. The process server receives data from source machines, optimizes and encrypts it, and sends it to Azure storage (port 443 outbound).
 7. Replicated machines communicate with the configuration server (port HTTPS 443 inbound, for replication management. Machines send replication data to the process server (port HTTPS 9443 inbound - can be modified).
-8. Traffic is replicated to Azure storage public endpoints, over the internet. Alternately, you can use Azure ExpressRoute public peering. Replicating traffic over a site-to-site VPN from an on-premises site to Azure isn't supported.
+8. Traffic is replicated to Azure storage public endpoints, over the internet. Alternately, you can use Azure ExpressRoute Microsoft peering. Replicating traffic over a site-to-site VPN from an on-premises site to Azure isn't supported.
 
 ## Prerequisites
 
diff --git a/articles/site-recovery/concepts-expressroute-with-site-recovery.md b/articles/site-recovery/concepts-expressroute-with-site-recovery.md
@@ -24,7 +24,7 @@ An ExpressRoute circuit has multiple routing domains associated with it. Learn m
 
 Azure Site Recovery enables disaster recovery and migration to Azure for on-premises [Hyper-V virtual machines](hyper-v-azure-architecture.md), [VMware virtual machines](vmware-azure-architecture.md), and [physical servers](physical-azure-architecture.md). For all on-premises to Azure scenarios, replication data is sent to and stored in an Azure Storage account. During replication, you don't pay any virtual machine charges. When you run a failover to Azure, Site Recovery automatically creates Azure IaaS virtual machines.
 
-Site Recovery replicates data to an Azure Storage account or replica Managed Disk on the target Azure region over a public endpoint. To use ExpressRoute for Site Recovery replication traffic, you can utilize [Microsoft peering](../expressroute/expressroute-circuit-peerings.md#microsoftpeering) or an existing [public peering](../expressroute/about-public-peering.md) (deprecated for new creations). Microsoft peering is the recommended routing domain for replication. Note that replication is supported over private peering only when [private ends points are enabled for the vault](hybrid-how-to-enable-replication-private-endpoints.md).
+Site Recovery replicates data to an Azure Storage account or replica Managed Disk on the target Azure region over a public endpoint. To use ExpressRoute for Site Recovery replication traffic, you can utilize [Microsoft peering](../expressroute/expressroute-circuit-peerings.md#microsoftpeering). Note that replication is supported over private peering only when [private ends points are enabled for the vault](hybrid-how-to-enable-replication-private-endpoints.md).
 
 Ensure that the [Networking Requirements](vmware-azure-configuration-server-requirements.md#network-requirements) for Configuration Server are also met. Connectivity to specific URLs is required by Configuration Server for orchestration of Site Recovery replication. ExpressRoute cannot be used for this connectivity. 
 
diff --git a/articles/site-recovery/site-recovery-faq.yml b/articles/site-recovery/site-recovery-faq.yml

Original file line number	Diff line number	Diff line change
`@@ -81,7 +81,7 @@ The combined effect of this configuration is that the subnet-level UDR takes pre`
`81`	`81`	`> [!IMPORTANT]`
`82`	`82`	`> The routes defined in a UDR must be specific enough to take precedence over any routes that are advertised by the ExpressRoute configuration. The example described in the next section uses the broad 0.0.0.0/0 address range. This range can accidentally be overridden by route advertisements that use more specific address ranges.`
`83`	`83`	`>`
`84`		-> App Service Environment isn't supported with ExpressRoute configurations that cross-advertise routes from the public peering path to the private peering path. ExpressRoute configurations that have public peering configured receive route advertisements from Microsoft for a large set of Microsoft Azure IP address ranges. If these address ranges are cross-advertised on the private peering path, all outbound network packets from the App Service Environment subnet are force tunneled to the customer's on-premises network infrastructure. This network flow isn't currently supported with App Service Environment. One solution is to stop cross-advertising routes from the public peering path to the private peering path.
	`84`	+> App Service Environment isn't supported with ExpressRoute configurations that cross-advertise routes from the Microsoft peering path to the private peering path. ExpressRoute configurations that have Microsoft peering configured receive route advertisements from Microsoft for a large set of Microsoft Azure IP address ranges. If these address ranges are cross-advertised on the private peering path, all outbound network packets from the App Service Environment subnet are force tunneled to the customer's on-premises network infrastructure. This network flow isn't currently supported with App Service Environment. One solution is to stop cross-advertising routes from the Microsoft peering path to the private peering path.
`85`	`85`	`>`
`86`	`86`	`>`
`87`	`87`
Original file line number	Diff line number	Diff line change
`@@ -56,7 +56,7 @@ If the network is already routing traffic on premises, then you need to create t`
`56`	`56`	`> [!IMPORTANT]`
`57`	`57`	`> The routes defined in a UDR must be specific enough to take precedence over any routes advertised by the ExpressRoute configuration. The preceding example uses the broad 0.0.0.0/0 address range. It can potentially be accidentally overridden by route advertisements that use more specific address ranges.`
`58`	`58`	`>`
`59`		-> App Service Environments aren't supported with ExpressRoute configurations that cross-advertise routes from the public-peering path to the private-peering path. ExpressRoute configurations with public peering configured receive route advertisements from Microsoft. The advertisements contain a large set of Microsoft Azure address ranges. If the address ranges are cross-advertised on the private-peering path, all outbound network packets from the App Service Environment's subnet are routed to a customer's on-premises network infrastructure. This network flow is not supported by default with App Service Environments. One solution to this problem is to stop cross-advertising routes from the public-peering path to the private-peering path. Another solution is to enable your App Service Environment to work in a forced tunnel configuration.
	`59`	+> App Service Environments aren't supported with ExpressRoute configurations that cross-advertise routes from the Microsoft peering path to the private-peering path. ExpressRoute configurations with Microsoft peering configured receive route advertisements from Microsoft. The advertisements contain a large set of Microsoft Azure address ranges. If the address ranges are cross-advertised on the private-peering path, all outbound network packets from the App Service Environment's subnet are routed to a customer's on-premises network infrastructure. This network flow is not supported by default with App Service Environments. One solution to this problem is to stop cross-advertising routes from the Microsoft peering path to the private-peering path. Another solution is to enable your App Service Environment to work in a forced tunnel configuration.
`60`	`60`
`61`	`61`	`![Direct internet access][1]`
`62`	`62`