Merging changes synced from https://github.com/MicrosoftDocs/azure-docs-pr (branch live)

Author: Banani-Rath

.openpublishing.redirection.json

@@ -5286,6 +5286,16 @@
       "redirect_url": "/azure/app-service-mobile",
       "redirect_document_id": false
     },
+    {
+      "source_path": "articles/application-gateway/configure-waf-custom-rules.md",
+      "redirect_url": "/azure/web-application-firewall/ag/configure-waf-custom-rules",
+      "redirect_document_id": false
+    },
+    {
+      "source_path": "articles/application-gateway/create-custom-waf-rules.md",
+      "redirect_url": "/azure/web-application-firewall/ag/create-custom-waf-rules",
+      "redirect_document_id": false
+    },
     {
       "source_path": "articles/application-gateway/application-gateway-customize-waf-rules-portal.md",
       "redirect_url": "/azure/web-application-firewall/ag/application-gateway-customize-waf-rules-portal",

articles/active-directory/develop/app-registrations-training-guide.md

@@ -54,7 +54,7 @@ Here's where you can find the equivalent functionality in the new experience:
 - The functionality controlled by the **Multi-tenant** toggle in the legacy experience has been replaced by **Supported account types** on the **Authentication** page. For more information about how multi-tenant maps to the supported account type options, see [this quickstart](quickstart-modify-supported-accounts.md).
 - **Logout URL** is now on the **Authentication** page.
 - **Application type** is no longer a valid field. Instead, redirect URIs (which you can find on the **Authentication** page) determine which app types are supported.
-- **App ID URI** is now called **Application ID URI** and you can find this on the **Expose an API** blade. In the legacy experience, this property was auto-registered using the following format: `https://{tenantdomain}/{appID}` (for example, `https://microsoft.onmicrosoft.com/aeb4be67-a634-4f20-9a46-e0d4d4f1f96d`). In the new format, it's auto-generated as `api://{appID}`, but it needs to be explicitly saved. In Azure AD B2C tenants, the `https://{tenantdomain}/{appID}` format is still used.
+- **App ID URI** is now called **Application ID URI** and you can find this on the **Expose an API** blade. In the legacy experience, this property was auto-registered using the following format: `https://{tenantdomain}/{appID}` (for example, `https://microsoft.onmicrosoft.com/aeb4be67-a634-4f20-9a46-e0d4d4f1f96d`). In the new experience, it's auto-generated as `api://{appID}`, but it needs to be explicitly saved. In Azure AD B2C tenants, the `https://{tenantdomain}/{appID}` format is still used.
 
 ## Reply URLs/redirect URls
 

articles/aks/use-multiple-node-pools.md

@@ -29,19 +29,20 @@ The following limitations apply when you create and manage AKS clusters that sup
 
 * You can't delete the default (first) node pool.
 * The HTTP application routing add-on can't be used.
+* The AKS cluster must use the Standard SKU load balancer to use multiple node pools, the feature is not supported with Basic SKU load balancers.
+* The AKS cluster must use virtual machine scale sets for the nodes.
 * You can't add or delete node pools using an existing Resource Manager template as with most operations. Instead, [use a separate Resource Manager template](#manage-node-pools-using-a-resource-manager-template) to make changes to node pools in an AKS cluster.
 * The name of a node pool must start with a lowercase letter and can only contain alphanumeric characters. For Linux node pools the length must be between 1 and 12 characters, for Windows node pools the length must be between 1 and 6 characters.
 * The AKS cluster can have a maximum of eight node pools.
 * The AKS cluster can have a maximum of 400 nodes across those eight node pools.
 * All node pools must reside in the same subnet.
-* The AKS cluster must use virtual machine scale sets for the nodes.
 
 ## Create an AKS cluster
 
 To get started, create an AKS cluster with a single node pool. The following example uses the [az group create][az-group-create] command to create a resource group named *myResourceGroup* in the *eastus* region. An AKS cluster named *myAKSCluster* is then created using the [az aks create][az-aks-create] command. A *--kubernetes-version* of *1.13.10* is used to show how to update a node pool in a following step. You can specify any [supported Kubernetes version][supported-versions].
 
 > [!NOTE]
-> The *Basic* load balanacer SKU is not supported when using multiple node pools. By default, AKS clusters are created with the *Standard* loadbalacer SKU.
+> The *Basic* load balanacer SKU is not supported when using multiple node pools. By default, AKS clusters are created with the *Standard* load balancer SKU from Azure CLI and Azure portal.
 
 ```azurecli-interactive
 # Create a resource group in East US

articles/app-service/containers/configure-custom-container.md

@@ -162,6 +162,10 @@ The following lists show supported and unsupported Docker Compose configuration
 > [!NOTE]
 > Any other options not explicitly called out are ignored in Public Preview.
 
+## Configure VNet integration
+
+Using a custom container with VNet integration may require additional container configuration. See [Integrate your app with an Azure Virtual Network](../web-sites-integrate-with-vnet.md).
+
 ## Next steps
 
 > [!div class="nextstepaction"]

articles/app-service/deploy-staging-slots.md

@@ -215,7 +215,7 @@ You can also customize the warm-up behavior with one or both of the following [a
 - `WEBSITE_SWAP_WARMUP_PING_STATUSES`: Valid HTTP response codes for the warm-up operation. Add this app setting with a comma-separated list of HTTP codes. An example is `200,202` . If the returned status code isn't in the list, the warmup and swap operations are stopped. By default, all response codes are valid.
 
 > [!NOTE]
-> `<applicationInitialization>` is part each app start-up, where as these two app settings apply only to slot swaps.
+> The `<applicationInitialization>` configuration element is part of each app start-up, whereas the two warm-up behavior app settings apply only to slot swaps.
 
 If you have any problems, see [Troubleshoot swaps](#troubleshoot-swaps).
 
@@ -330,7 +330,7 @@ Remove-AzResource -ResourceGroupName [resource group name] -ResourceType Microso
 
 ## Automate with ARM templates
 
-[ARM Templates](https://docs.microsoft.com/en-us/azure/azure-resource-manager/template-deployment-overview) are declarative JSON files used to automate the deployment and configuration of Azure resources. To swap slots using ARM templates, you will set two properties on the *Microsoft.Web/sites/slots* and *Microsoft.Web/sites* resources:
+[ARM Templates](https://docs.microsoft.com/azure/azure-resource-manager/template-deployment-overview) are declarative JSON files used to automate the deployment and configuration of Azure resources. To swap slots using ARM templates, you will set two properties on the *Microsoft.Web/sites/slots* and *Microsoft.Web/sites* resources:
 
 - `buildVersion`: this is a string property which represents the current version of the app deployed in the slot. For example: "v1", "1.0.0.1", or "2019-09-20T11:53:25.2887393-07:00".
 - `targetBuildVersion`: this is a string property that specifies what `buildVersion` the slot should have. If the targetBuildVersion does not equal the current `buildVersion`, then this will trigger the swap operation by finding the slot which has the specified `buildVersion`.