resolve merge conflicts

Author: mumian

.openpublishing.redirection.json

@@ -4020,10 +4020,35 @@
       "redirect_url": "/azure/managed-grafana/overview",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/managed-grafana/concept-whats-new.md",
+      "redirect_url": "/azure/managed-grafana/overview",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/managed-grafana/how-to-transition-domain.md",
       "redirect_url": "/azure/managed-grafana/overview",
       "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/load-balancer/move-across-regions-external-load-balancer-portal.md",
+      "redirect_url": "/azure/load-balancer/move-across-regions-azure-load-balancer",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/load-balancer/move-across-regions-external-load-balancer-powershell.md",
+      "redirect_url": "/azure/load-balancer/move-across-regions-azure-load-balancer",
+      "redirect_document_id": false
+    },    
+    {
+      "source_path_from_root": "/articles/load-balancer/move-across-regions-internal-load-balancer-portal.md",
+      "redirect_url": "/azure/load-balancer/move-across-regions-azure-load-balancer",
+      "redirect_document_id": false
+    },    
+    {
+      "source_path_from_root": "/articles/load-balancer/move-across-regions-internal-load-balancer-powershell.md",
+      "redirect_url": "/azure/load-balancer/move-across-regions-azure-load-balancer",
+      "redirect_document_id": false
     }
   ]
 }

articles/api-center/index.yml

@@ -61,7 +61,7 @@ landingContent:
       - linkListType: how-to-guide
         links:
           - text: Analyze APIs using linting rules
-            url: enable-api-analysis-linting.md
+            url: enable-managed-api-analysis-linting.md
       - linkListType: concept
         links:
           - text: Use metadata for governance

articles/api-management/inject-vnet-v2.md

@@ -68,9 +68,11 @@ The subnet needs to be delegated to the **Microsoft.Web/hostingEnvironments** se
 
 For more information about configuring subnet delegation, see [Add or remove a subnet delegation](../virtual-network/manage-subnet-delegation.md).
 
+[!INCLUDE [api-management-virtual-network-address-prefix](../../includes/api-management-virtual-network-address-prefix.md)]
+
 ### Permissions
 
-You must have at least the following role-based access control permissions on the subnet or at a higher level to configure virtual network integration:
+You must have at least the following role-based access control permissions on the subnet or at a higher level to configure virtual network injection:
 
 | Action | Description |
 |-|-|
@@ -86,13 +88,11 @@ When you [create](get-started-create-service-instance.md) a Premium v2 instance
 
 1. In the **Create API Management service** wizard, select the **Networking** tab.
 1. In **Connectivity type**, select **Virtual network**.
-1. In **Type**, select **Internal**. 
-1. In **Configure virtual networks**, select the virtual network and the delegated subnet that you want to integrate. 
-
-    Optionally, provide a public IP address resource if you want to own and control an IP address that's used only for outbound connection to the internet.
+1. In **Type**, select **Injection**. 
+1. In **Configure virtual networks**, select the virtual network and the delegated subnet that you want to inject. 
 1. Complete the wizard to create the API Management instance.
 
-## DNS settings for integration with private IP address
+## DNS settings for access to private IP address
 
 When a Premium v2 API Management instance is injected in a virtual network, you have to manage your own DNS to enable inbound access to API Management. 
 

articles/app-service/configure-ssl-certificate.md

@@ -341,6 +341,9 @@ This is only supported for Windows container apps in multi-tenant App Service. I
 ### Can I load a private CA certificate in my App Service Trusted Root Store?
 You can load your own CA certificate into the Trusted Root Store in [App Service Environment version 3](./environment/overview-certificates.md). You can't modify the list of Trusted Root Certificates in App Service (multi-tenant). For more information on App Service multi-tenant vs. single-tenant, see [App Service Environment v3 and App Service public multitenant comparison](./environment/ase-multi-tenant-comparison.md).
 
+### Can App Service Certificate be used for other services?
+Yes, certificates purchased via App Service Certificate can be exported and used with Application Gateway or other services. Refer to the following blog article for more information: [Creating a local PFX copy of App Service Certificate](https://azure.github.io/AppService/2017/02/24/Creating-a-local-PFX-copy-of-App-Service-Certificate.html).
+
 ## More resources
 
 * [Secure a custom DNS name with a TLS/SSL binding in Azure App Service](configure-ssl-bindings.md)

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.
 >
 >
 

articles/app-service/environment/auto-migration.md

@@ -74,7 +74,7 @@ The following errors might be displayed in the portal if you're ineligible for a
 
 ## What to do if your App Service Environment is suspended
 
-If your App Service Environment is suspended, you have two options.
+If your App Service Environment is suspended, you have three options.
 
 ### Unsuspend and self-migrate
 
@@ -88,6 +88,14 @@ If you want to expedite migration, you can resume/unsuspend your environment as
 
 :::image type="content" source="./media/migration/resume-as-asev3.png" alt-text="Screenshot that shows the button on the Migration page where you can resume as an App Service Environment v3.":::
 
+### Delete your App Service Environment
+
+If you no longer need your App Service Environment, you can delete your environment using the following CLI command. Replace the placeholders for the subscription id, environment name, and resource group with your values for the App Service Environment that you want to delete. The Azure CLI is the only available method for deleting your environment. If you haven't previously used the Azure CLI, [install the Azure CLI](/cli/azure/install-azure-cli) or use [Azure Cloud Shell](https://shell.azure.com/) and use a Bash shell. Deleting your environment will also delete the associated apps and App Service plans. This action is irreversible.
+
+```azurecli
+az rest --method delete --url "https://management.azure.com/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP>/providers/Microsoft.Web/hostingEnvironments/<ASE-NAME>?api-version=2020-12-01" --url-parameters forceDelete=true --verbose
+```
+
 ## Features to limit the effects of auto-migrations
 
 To limit the effect of auto-migrations, we implemented the following features to the auto-migration feature.

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]