Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into vnettitleseofeb2020

Author: KumudD

articles/active-directory/index.yml

@@ -55,6 +55,21 @@ conceptualContent:
         url: ./manage-apps/index.yml
         text: See more
 
+    - title: Application and HR provisioning 
+      links: 
+        - url: ./app-provisioning/user-provisioning.md
+          itemType: overview
+          text: What is application provisioning? 
+        - url: ./app-provisioning/how-provisioning-works.md
+          itemType: concept
+          text: How application provisioning works 
+        - url: ./app-provisioning/plan-cloud-hr-provision.md
+          itemType: how-to-guide
+          text: Plan a cloud HR provisioning deployment
+      footerLink: 
+        url: ./app-provisioning/index.yml
+        text: See more
+
     - title: Authentication
       links: 
         - url: ./authentication/concept-mfa-howitworks.md

articles/azure-functions/set-runtime-version.md

@@ -14,7 +14,7 @@ A function app runs on a specific version of the Azure Functions runtime. There
 
 Azure Functions lets you target a specific version of the runtime by using the `FUNCTIONS_EXTENSION_VERSION` application setting in a function app. The function app is kept on the specified major version until you explicitly choose to move to a new version.
 
-If you specify only the major version, the function app is automatically updated to new minor versions of the runtime when they become available. New minor versions do not introduce breaking changes. If you specify a minor version (for example, "2.0.12345"), the function app is pinned to that specific version until you explicitly change it.
+If you specify only the major version, the function app is automatically updated to new minor versions of the runtime when they become available. New minor versions shouldn't introduce breaking changes. If you specify a minor version (for example, "2.0.12345"), the function app is pinned to that specific version until you explicitly change it.
 
 > [!NOTE]
 > If you pin to a specific version of Azure Functions, and then try to publish to Azure using Visual Studio, a dialog window will pop up prompting you to update to the latest version or cancel the publish. To avoid this, add the `<DisableFunctionExtensionVersionUpdate>true</DisableFunctionExtensionVersionUpdate>` property in your `.csproj` file.

articles/cosmos-db/media/performance-tips-async-java/rntbdtransportclient.png

@@ -3,6 +3,7 @@ title: Plan and manage costs for Azure Cosmos DB
 description: Learn how to plan for and manage costs for Azure Cosmos DB by using cost analysis in Azure portal.
 author: SnehaGunda
 ms.author: sngun
+ms.custom: subject-cost-optimization
 ms.service: cosmos-db
 ms.topic: conceptual
 ms.date: 02/02/2020

articles/cosmos-db/performance-tips-async-java.md

@@ -5,17 +5,17 @@ author: hrasheed-msft
 ms.author: hrasheed
 ms.reviewer: jasonh
 ms.service: hdinsight
-ms.custom: hdinsightactive
 ms.topic: conceptual
-ms.date: 10/22/2019
+ms.custom: hdinsightactive
+ms.date: 02/11/2020
 ---
 
 # Automatically scale Azure HDInsight clusters
 
 > [!Important]
-> The Autoscale feature only works for Spark, Hive, LLAP and HBase clusters created after May 8th 2019. 
+> The Autoscale feature only works for Apache Spark, ApacheHive, LLAP and Apache HBase clusters created after May 8th 2019.
 
-Azure HDInsight’s cluster Autoscale feature automatically scales the number of worker nodes in a cluster up and down. Other types of nodes in the cluster can't be scaled currently.  During the creation of a new HDInsight cluster, a minimum and maximum number of worker nodes can be set. Autoscale then monitors the resource requirements of the analytics load and scales the number of worker nodes up or down. There's no additional charge for this feature.
+Azure HDInsight's cluster Autoscale feature automatically scales the number of worker nodes in a cluster up and down. Other types of nodes in the cluster can't be scaled currently.  During the creation of a new HDInsight cluster, a minimum and maximum number of worker nodes can be set. Autoscale then monitors the resource requirements of the analytics load and scales the number of worker nodes up or down. There's no additional charge for this feature.
 
 ## Cluster compatibility
 
@@ -40,12 +40,14 @@ Schedule-based scaling changes the number of nodes in your cluster based on cond
 
 Autoscale continuously monitors the cluster and collects the following metrics:
 
-* **Total Pending CPU**: The total number of cores required to start execution of all pending containers.
-* **Total Pending Memory**: The total memory (in MB) required to start execution of all pending containers.
-* **Total Free CPU**: The sum of all unused cores on the active worker nodes.
-* **Total Free Memory**: The sum of unused memory (in MB) on the active worker nodes.
-* **Used Memory per Node**: The load on a worker node. A worker node on which 10 GB of memory is used, is considered under more load than a worker with 2 GB of used memory.
-* **Number of Application Masters per Node**: The number of Application Master (AM) containers running on a worker node. A worker node that is hosting two AM containers, is considered more important than a worker node that is hosting zero AM containers.
+|Metric|Description|
+|---|---|
+|Total Pending CPU|The total number of cores required to start execution of all pending containers.|
+|Total Pending Memory|The total memory (in MB) required to start execution of all pending containers.|
+|Total Free CPU|The sum of all unused cores on the active worker nodes.|
+|Total Free Memory|The sum of unused memory (in MB) on the active worker nodes.|
+|Used Memory per Node|The load on a worker node. A worker node on which 10 GB of memory is used, is considered under more load than a worker with 2 GB of used memory.|
+|Number of Application Masters per Node|The number of Application Master (AM) containers running on a worker node. A worker node that is hosting two AM containers, is considered more important than a worker node that is hosting zero AM containers.|
 
 The above metrics are checked every 60 seconds. Autoscale makes scale-up and scale-down decisions based on these metrics.
 
@@ -71,11 +73,9 @@ Based on the number of AM containers per node and the current CPU and memory req
 
 ### Create a cluster with load-based Autoscaling
 
-To use Autoscale on a cluster, the **Enable autoscale** option must be enabled when the cluster is created. 
-
-To enable the Autoscale feature with load-based scaling, complete the following steps as part of the normal cluster creation process:
+To use Autoscale on a cluster, the **Enable autoscale** option must be enabled when the cluster is created. To enable the Autoscale feature with load-based scaling, complete the following steps as part of the normal cluster creation process:
 
-1. On the **Configuration + pricing** tab, check the **Enable autoscale** checkbox.
+1. On the **Configuration + pricing** tab, select the **Enable autoscale** checkbox.
 1. Select **Load-based** under **Autoscale type**.
 1. Enter the desired values for the following properties:  
 
@@ -85,7 +85,7 @@ To enable the Autoscale feature with load-based scaling, complete the following
 
     ![Enable worker node load-based autoscale](./media/hdinsight-autoscale-clusters/azure-portal-cluster-configuration-pricing-autoscale.png)
 
-The initial number of worker nodes must fall between the minimum and maximum, inclusive. This value defines the initial size of the cluster when it's created. The minimum number of worker nodes should be set to three or more. . Scaling your cluster to fewer than three nodes can result in it getting stuck in safe mode because of insufficient file replication. See [Getting stuck in safe mode]( https://docs.microsoft.com/ azure/hdinsight/hdinsight-scaling-best-practices#getting-stuck-in-safe-mode) for more information.
+The initial number of worker nodes must fall between the minimum and maximum, inclusive. This value defines the initial size of the cluster when it's created. The minimum number of worker nodes should be set to three or more. Scaling your cluster to fewer than three nodes can result in it getting stuck in safe mode because of insufficient file replication.  For more information, see [Getting stuck in safe mode](./hdinsight-scaling-best-practices.md#getting-stuck-in-safe-mode).
 
 ### Create a cluster with schedule-based Autoscaling
 
@@ -94,7 +94,7 @@ To enable the Autoscale feature with schedule-based scaling, complete the follow
 1. On the **Configuration + pricing** tab, check the **Enable  autoscale** checkbox.
 1. Enter the **Number of nodes** for **Worker node**, which controls the limit for scaling up the cluster.
 1. Select the option **Schedule-based** under **Autoscale type**.
-1. Click **Configure** to open the **Autoscale configuration** window.
+1. Select **Configure** to open the **Autoscale configuration** window.
 1. Select your timezone and then click **+ Add condition**
 1. Select the days of the week that the new condition should apply to.
 1. Edit the time the condition should take effect and the number of nodes that the cluster should be scaled to.
@@ -185,7 +185,7 @@ You can create an HDInsight cluster with schedule-based Autoscaling an Azure Res
 
 #### Using the Azure portal
 
-To enable Autoscale on a running cluster, select **Cluster size** under **Settings**. Then click **Enable autoscale**. Select the type of Autoscale that you want and enter the options for load-based or schedule-based scaling. Finally, click **Save**.
+To enable Autoscale on a running cluster, select **Cluster size** under **Settings**. Then select **Enable autoscale**. Select the type of Autoscale that you want and enter the options for load-based or schedule-based scaling. Finally, select **Save**.
 
 ![Enable worker node schedule-based autoscale running cluster](./media/hdinsight-autoscale-clusters/azure-portal-settings-autoscale.png)
 
@@ -214,7 +214,7 @@ Consider the following factors before making a decision on which mode to choose:
 * Enable Autoscale during cluster creation.
 * The minimum number of nodes should be at least three.
 * Load variance: does the load of the cluster follow a consistent pattern at specific times, on specific days. If not, load based scheduling is a better option.
-* SLA requirements: Autoscale scaling is reactive instead of predictive. Will there be a sufficient delay between when the load starts to increase and when the cluster needs to be at its target size? If there are strict SLA requirements and the load is a fixed known pattern, ‘schedule based’ is a better option.
+* SLA requirements: Autoscale scaling is reactive instead of predictive. Will there be a sufficient delay between when the load starts to increase and when the cluster needs to be at its target size? If there are strict SLA requirements and the load is a fixed known pattern, 'schedule based' is a better option.
 
 ### Consider the latency of scale up or scale down operations
 
@@ -228,7 +228,7 @@ The running jobs will continue to run and finish. The pending jobs will wait to
 
 ### Minimum cluster size
 
-Do not scale your cluster down to fewer than three nodes. Scaling your cluster to fewer than three nodes can result in it getting stuck in safe mode because of insufficient file replication. See [Getting stuck in safe mode]( https://docs.microsoft.com/ azure/hdinsight/hdinsight-scaling-best-practices#getting-stuck-in-safe-mode) for more information.
+Don't scale your cluster down to fewer than three nodes. Scaling your cluster to fewer than three nodes can result in it getting stuck in safe mode because of insufficient file replication.  For more information, see [Getting stuck in safe mode](./hdinsight-scaling-best-practices.md#getting-stuck-in-safe-mode).
 
 ## Monitoring
 
@@ -240,24 +240,24 @@ The cluster status listed in the Azure portal can help you monitor Autoscale act
 
 All of the cluster status messages that you might see are explained in the list below.
 
-| Cluster status | Explanation |
+| Cluster status | Description |
 |---|---|
 | Running | The cluster is operating normally. All of the previous Autoscale activities have completed successfully. |
 | Updating  | The cluster Autoscale configuration is being updated.  |
 | HDInsight configuration  | A cluster scale up or scale down operation is in progress.  |
 | Updating Error  | HDInsight encountered issues during the Autoscale configuration update. Customers can choose to either retry the update or disable autoscale.  |
 | Error  | Something is wrong with the cluster, and it isn't usable. Delete this cluster and create a new one.  |
 
-To view the current number of nodes in your cluster, go to the **Cluster size** chart on the **Overview** page for your cluster, or click **Cluster size** under **Settings**.
+To view the current number of nodes in your cluster, go to the **Cluster size** chart on the **Overview** page for your cluster, or select **Cluster size** under **Settings**.
 
 ### Operation history
 
 You can view the cluster scale-up and scale-down history as part of the cluster metrics. You can also list all scaling actions over the past day, week, or other period of time.
 
-Select **Metrics** under **Monitoring**. Then click **Add metric** and **Number of Active Workers** from the **Metric** dropdown box. Click the button in the upper right to change the time range.
+Select **Metrics** under **Monitoring**. Then select **Add metric** and **Number of Active Workers** from the **Metric** dropdown box. Select the button in the upper right to change the time range.
 
 ![Enable worker node schedule-based autoscale metric](./media/hdinsight-autoscale-clusters/hdinsight-autoscale-clusters-chart-metric.png)
 
 ## Next steps
 
-* Read about best practices for scaling clusters manually in [Scaling best practices](hdinsight-scaling-best-practices.md)
+Read about best practices for scaling clusters manually in [Scaling best practices](hdinsight-scaling-best-practices.md)

articles/cosmos-db/plan-manage-costs.md

@@ -38,7 +38,7 @@ Azure Load Balancer and related resources are explicitly defined when you're usi
 | SKUs | Scenario | Method | IP protocols | Description |
 | --- | --- | --- | --- | --- |
 | Standard, Basic | [1. VM with Public IP address (with or without Load Balancer)](#ilpip) | SNAT, port masquerading not used | TCP, UDP, ICMP, ESP | Azure uses the public IP assigned to the IP configuration of the instance's NIC. The instance has all ephemeral ports available. When using Standard Load Balancer, you should use [outbound rules](load-balancer-outbound-rules-overview.md) to explicitly define outbound connectivity |
-| Standard, Basic | [2. Public Load Balancer associated with a VM (no Public IP address on the instance)](#lb) | SNAT with port masquerading (PAT) using the Load Balancer frontends | TCP, UDP |Azure shares the public IP address of the public Load Balancer frontends with multiple private IP addresses. Azure uses ephemeral ports of the frontends to PAT. |
+| Standard, Basic | [1. VM with an Instance Level Public IP address (with or without Load Balancer)](#ilpip) | SNAT, port masquerading not used | TCP, UDP, ICMP, ESP | Azure uses the public IP assigned to the IP configuration of the instance's NIC. The instance has all ephemeral ports available. When using Standard Load Balancer, [outbound rules](load-balancer-outbound-rules-overview.md) are not supported if a public IP is assigned to the Virtual Machine |
 | none or Basic | [3. Standalone VM (no Load Balancer, no Public IP address)](#defaultsnat) | SNAT with port masquerading (PAT) | TCP, UDP | Azure automatically designates a public IP address for SNAT, shares this public IP address with multiple private IP addresses of the availability set, and uses ephemeral ports of this public IP address. This scenario is a fallback for the preceding scenarios. We don't recommend it if you need visibility and control. |
 
 If you don't want a VM to communicate with endpoints outside Azure in public IP address space, you can use network security groups (NSGs) to block access as needed. The section [Preventing outbound connectivity](#preventoutbound) discusses NSGs in more detail. Guidance on designing, implementing, and managing a virtual network without any outbound access is outside the scope of this article.

articles/hdinsight/hdinsight-autoscale-clusters.md

@@ -83,7 +83,7 @@ To help you plan your deployment for each of the stages, below are the results o
 | Number of objects | 25 million objects |
 | Dataset Size| ~4.7 TiB |
 | Average File Size | ~200 KiB (Largest File: 100 GiB) |
-| Upload Throughput | 20 objects per second |
+| Upload Throughput | 20 objects per second per sync group |
 | Namespace Download Throughput* | 400 objects per second |
 
 *When a new server endpoint is created, the Azure File Sync agent does not download any of the file content. It first syncs the full namespace and then triggers background recall to download the files, either in their entirety or, if cloud tiering is enabled, to the cloud tiering policy set on the server endpoint.
@@ -93,7 +93,7 @@ To help you plan your deployment for each of the stages, below are the results o
 | Number of objects synced| 125,000 objects (~1% churn) |
 | Dataset Size| 50 GiB |
 | Average File Size | ~500 KiB |
-| Upload Throughput | 20 objects per second |
+| Upload Throughput | 20 objects per second per sync group |
 | Full Download Throughput* | 60 objects per second |
 
 *If cloud tiering is enabled, you are likely to observe better performance as only some of the file data is downloaded. Azure File Sync only downloads the data of cached files when they are changed on any of the endpoints. For any tiered or newly created files, the agent does not download the file data, and instead only syncs the namespace to all the server endpoints. The agent also supports partial downloads of tiered files as they are accessed by the user. 

articles/load-balancer/load-balancer-outbound-connections.md

@@ -41,7 +41,6 @@ You can generate client configuration files using PowerShell, or by using the Az
 
 ### <a name="zipps"></a>Generate files using PowerShell
 
-[!INCLUDE [updated-for-az](../../includes/updated-for-az.md)]
 
 1. When generating VPN client configuration files, the value for '-AuthenticationMethod' is 'EapTls'. Generate the VPN client configuration files using the following command:
 

articles/storage/files/storage-files-scale-targets.md

@@ -34,7 +34,6 @@ The configuration workflow for P2S RADIUS authentication is as follows:
 
 To use the sections in this article, first decide which type of authentication you want to use: username/password, certificate, or other types of authentication. Each section has steps for Windows, Mac OS X, and Linux (limited steps available at this time).
 
-[!INCLUDE [updated-for-az](../../includes/updated-for-az.md)]
 
 ## <a name="adeap"></a>Username/password authentication