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

Author: Tyler Whitney

articles/active-directory/develop/about-microsoft-identity-platform.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: overview
 ms.workload: identity
-ms.date: 06/03/2019
+ms.date: 12/09/2019
 ms.author: ryanwi
 ms.reviewer: agirling, saeeda, benv
 ms.custom: aaddev
@@ -23,13 +23,13 @@ Microsoft identity platform is an evolution of the Azure Active Directory (Azure
 
 Up until now, most developers have worked with the Azure AD v1.0 platform to authenticate work and school accounts (provisioned by Azure AD) by requesting tokens from the Azure AD v1.0 endpoint, using Azure AD Authentication Library (ADAL), Azure portal for application registration and configuration, and Azure AD Graph API for programmatic application configuration.
 
-With Microsoft identity platform (v2.0), expand your reach to these kinds of users:
+With the unified Microsoft identity platform (v2.0), you can write code once and authenticate any Microsoft identity into your application. For several platforms, the fully supported open-source Microsoft Authentication Library (MSAL) is recommended for use against the identity platform endpoints. MSAL is simple to use, provides great single sign-on (SSO) experiences for your users, helps you achieve high reliability and performance, and is developed using Microsoft Secure Development Lifecycle (SDL). When calling APIs, you can configure your application to take advantage of incremental consent, which allows you to delay the request for consent for more invasive scopes until the application’s usage warrants this at runtime.  MSAL also supports Azure Active Directory B2C, so your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs.
+
+With Microsoft identity platform, expand your reach to these kinds of users:
 
 - Work and school accounts (Azure AD provisioned accounts)
 - Personal accounts (such as Outlook.com or Hotmail.com)
-- Your customers who bring their own email or social identity (such as LinkedIn, Facebook, Google) via the Azure AD B2C offering
-
-With the unified Microsoft identity platform, you can write code once and authenticate any Microsoft identity into your application. For several platforms, there’s a fully supported open-source library called Microsoft Authentication Library (MSAL). MSAL is simple to use, provides great single sign-on (SSO) experiences for your users, helps you achieve high reliability and performance, and is developed using Microsoft Secure Development Lifecycle (SDL). When calling APIs, you can configure your application to take advantage of incremental consent, which allows you to delay the request for consent for more invasive scopes until the application’s usage warrants this at runtime.
+- Your customers who bring their own email or social identity (such as LinkedIn, Facebook, Google) via MSAL and Azure AD B2C
 
 You can use the Azure portal to register and configure your application, and use the Microsoft Graph API for programmatic application configuration.
 

articles/active-directory/develop/tutorial-v2-aspnet-daemon-web-app.md

@@ -13,14 +13,13 @@ ms.devlang: na
 ms.topic: conceptual
 ms.tgt_pltfrm: na
 ms.workload: identity
-ms.date: 04/16/2018
+ms.date: 12/10/2019
 ms.author: markvi
 ms.collection: M365-identity-device-management
 ---
 
 # Create, list and delete a user-assigned managed identity using Azure Resource Manager
 
-[!INCLUDE [preview-notice](~/includes/active-directory-msi-preview-notice-ua.md)]
 
 Managed identities for Azure resources provides Azure services with a managed identity in Azure Active Directory. You can use this identity to authenticate to services that support Azure AD authentication, without needing credentials in your code. 
 

articles/active-directory/managed-identities-azure-resources/how-to-manage-ua-identity-arm.md

@@ -13,7 +13,7 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: article
-ms.date: 01/26/2018
+ms.date: 12/10/2019
 ms.author: jeedes
 
 ms.collection: M365-identity-device-management
@@ -95,7 +95,7 @@ For more information on how to configure automatic provisioning, see [https://de
 You can now create a test account. Wait for up to 20 minutes to verify that the account has been synchronized to Workplace by Facebook.
 
 > [!NOTE]
-> We are working closely with the Workplace by Facebook team to ensure that the Azure AD application is approved and meets their new guidelines. The Workplace by Facebook deadlines is December 16th and we expect to meet that. No work is expected of customers at that time. By 28-February-2020, customers will need to transition to the new integration. We will post here as soon as the migration path is available.    
+> The Azure AD third party application in Workplace by Facebook has been approved. Customers will not have an interruption of service on December 16th. You will see a note in the Workplace by Facebook Admin console indicating a deadline of 28-February-2020 by when you will need to transition to the new application. We are working to keep the transition as simple as possible and will provide an update here on the transition by end of month.
 
 ## Additional resources
 

articles/active-directory/saas-apps/workplacebyfacebook-provisioning-tutorial.md

@@ -65,6 +65,7 @@ sections:
     - html: <a href="/azure/aks/tutorial-kubernetes-scale">Scale an application and Kubernetes infrastructure</a>
     - html: <a href="/azure/aks/tutorial-kubernetes-app-update">Update an application running in Kubernetes</a>
     - html: <a href="/azure/aks/tutorial-kubernetes-upgrade-cluster">Upgrade AKS cluster</a>
+    - html: <a href="/azure/architecture/reference-architectures/microservices/aks">Learn and implement the microservices reference architecture</a>
 - title: Build your skills with Microsoft Learn
   items:
   - type: list

articles/aks/index.yml

@@ -6,7 +6,7 @@ author: sauryadas
 
 ms.service: container-service
 ms.topic: article
-ms.date: 05/20/2019
+ms.date: 12/09/2019
 ms.author: saudas
 ---
 
@@ -17,8 +17,7 @@ improvements. Patch releases are more frequent (sometimes weekly) and are only i
 minor version. These patch releases include fixes for security vulnerabilities or major bugs impacting a large number
 of customers and products running in production based on Kubernetes.
 
-AKS aims to certify and release new Kubernetes versions within 30 days of an upstream release, subject to the stability
-of the release.
+AKS aims to certify and release new Kubernetes versions within 30 days of an upstream release, subject to the stability of the release.
 
 ## Kubernetes versions
 
@@ -39,75 +38,62 @@ Each number in the version indicates general compatibility with the previous ver
 * Minor versions change when functionality changes are made that are backwards compatible to the other minor releases.
 * Patch versions change when backwards-compatible bug fixes are made.
 
-In general, users should endeavor to run the latest patch release of the minor version they are running, for example if
-your production cluster is on *1.12.14* and *1.12.15* is the latest available patch version available for the *1.12*
-series, you should upgrade to *1.12.15* as soon as you are able to ensure your cluster is fully patched and supported.
+Users should aim to run the latest patch release of the minor version they are running, for example if
+your production cluster is on *1.12.14* and *1.12.15* is the latest available patch version available for the *1.12* series, you should upgrade to *1.12.15* as soon as you are able to ensure your cluster is fully patched and supported.
 
 ## Kubernetes version support policy
 
-> [!NOTE]
-> Starting December 9th, 2019 AKS will move to supporting latest (N) - 2 versions of Kubernetes. This change is to conform to the upstream window of support for Kubernetes versions and ensure the latest and most secure versions are being used. To learn more read the [announcement here](https://azure.microsoft.com/updates/azure-kubernetes-service-will-be-retiring-support-for-kubernetes-versions-1-11-and-1-12/).
-
-AKS supports four minor versions of Kubernetes:
+AKS supports three minor versions of Kubernetes:
 
 * The current minor version that is released in AKS (N)
-* Three previous minor versions. Each supported minor version also supports two stable patches.
+* Two previous minor versions. Each supported minor version also supports two stable patches.
 
-This is known as "N-3" - (N (Latest release) - 3 (minor versions)).
+This is known as "N-2": (N (Latest release) - 2 (minor versions)).
 
-For example, if AKS introduces *1.13.a* today, support is provided for the following versions:
+For example, if AKS introduces *1.15.a* today, support is provided for the following versions:
 
 New minor version    |    Supported Version List
 -----------------    |    ----------------------
-1.13.a               |    1.12.a, 1.12.b, 1.11.a, 1.11.b, 1.10.a, 1.10.b
+1.15.a               |    1.15.a, 1.15.b, 1.14.c, 1.14.d, 1.13.e, 1.13.f
 
-Where ".a" and ".b" are representative patch versions."a" from 1.13.a can be different from 1.12.a. For example, 1.13.9 and 1.12.8.
+Where ".letter" is representative of patch versions.
 
 For details on communications regarding version changes and expectations, see "Communications" below.
 
-When a new minor version is introduced, the oldest minor version and patch releases supported are deprecated and
-removed. For example if the current supported version list is:
+When a new minor version is introduced, the oldest minor version and patch releases supported are deprecated and removed. For example, if the current supported version list is:
 
 ```
-1.12.a
-1.12.b
-1.11.a
-1.11.b
-1.10.a
-1.10.b
-1.9.a
-1.9.b
+1.15.a
+1.15.b
+1.14.c
+1.14.d
+1.13.e
+1.13.f
 ```
 
-And AKS releases 1.13.*, this means that the 1.9.* versions (all 1.9 versions) will be removed and out of support.
+And AKS releases 1.16.*, this means that the 1.13.* versions (all 1.13 versions) will be removed and out of support.
 
 > [!NOTE]
 > Please note, that if customers are running an unsupported Kubernetes version, they will be asked to upgrade when
 > requesting support for the cluster. Clusters running unsupported Kubernetes releases are not covered by the
 > [AKS support policies](https://docs.microsoft.com/azure/aks/support-policies).
 
-
-In addition to the above on minor versions, AKS supports the two latest *patch** releases of a given minor version. For
-example, given the following supported versions:
+In addition to the above on minor versions, AKS supports the two latest **patch** releases of a given minor version. For example, given the following supported versions:
 
 ```
 Current Supported Version List
 ------------------------------
-1.12.1, 1.12.2, 1.11.4, 1.11.5
+1.15.2, 1.15.1, 1.14.5, 1.14.4
 ```
 
-If upstream Kubernetes released 1.12.3 and 1.11.6 and AKS releases those patch versions, the oldest patch versions
-are deprecated and removed, and the supported version list becomes:
+If upstream Kubernetes released 1.15.3 and 1.14.6 and AKS releases those patch versions, the oldest patch versions are deprecated and removed, and the supported version list becomes:
 
 ```
 New Supported Version List
 ----------------------
-1.12.*2*, 1.12.*3*, 1.11.*5*, 1.11.*6*
+1.15.*3*, 1.15.*2*, 1.14.*6*, 1.14.*5*
 ```
 
-> [!NOTE]
-> Customers should not pin cluster creation, CI or other automated jobs to specific patch releases. 
-
 ### Communications
 
 * For new **minor** versions of Kubernetes
@@ -119,17 +105,11 @@ New Supported Version List
   * Users have **30 days** to upgrade to a newer, supported patch release. Users have **30 days** to upgrade to
     a supported patch release before the oldest is removed.
 
-AKS defines "released" as general availability, enabled in all SLO / Quality of Service measurements and
-available in all regions.
-
-> [!NOTE]
-> Customers are notified of Kubernetes version releases and deprecations, when a minor version is
-> deprecated/removed users are given 60 days to upgrade to a supported release. In the case of patch releases,
-> customers are given 30 days to upgrade to a supported release.
+AKS defines a "released version" as the generally available versions, enabled in all SLO / Quality of Service measurements and available in all regions. AKS may also support preview versions which are explicitly labeled and subject to Preview terms and conditions.
 
 #### Notification channels for AKS changes
 
-AKS releases a weekly service update which summarizes new Kubernetes versions, service changes, and component updates that have been released on the service on [github](https://github.com/Azure/AKS/releases).
+AKS publishes regular service updates which summarize new Kubernetes versions, service changes, and component updates that have been released on the service on [GitHub](https://github.com/Azure/AKS/releases).
 
 These changes are rolled to all customers as part of regular maintenance that is offered as part of the managed service, some require explicit upgrades while others require no action.
 
@@ -139,62 +119,37 @@ Notifications are also sent via:
 * Azure portal notifications
 * [Azure update channel][azure-update-channel]
 
-### Policy Exceptions
+### Supported Versions Policy Exceptions
 
-AKS reserves the right to add or remove new/existing versions that have been identified to have one or more critical
-production impacting bugs or security issues without advance notice.
+AKS reserves the right to add or remove new/existing versions that have been identified to have one or more critical production impacting bugs or security issues without advance notice.
 
 Specific patch releases may be skipped, or rollout accelerated depending on the severity of the bug or security issue.
 
 ### Azure portal and CLI default versions
 
-When you deploy an AKS cluster in the portal or with the Azure CLI, the cluster is always set to the N-1 minor version
-and latest patch. For example, if AKS supports *1.13.a*, *1.12.a* + *1.12.b*, *1.11.a* + *1.11.b*, *1.10.a* + *1.10b*,
-the default version for new clusters is *1.12.b*.
+When you deploy an AKS cluster in the portal or with the Azure CLI, the cluster is defaulted to the N-1 minor version and latest patch. For example, if AKS supports *1.15.a*, *1.15.b*, *1.14.c*, *1.14.d*,  *1.13.e*, and *1.13.f*, the default version selected is *1.14.c*.
 
-AKS defaults to N-1 (minor.latestPatch, eg 1.12.b) to provide customers a known, stable and patched version by default.
+AKS chooses the default of N-1 to provide customers a known, stable, and patched version by default.
 
 ## List currently supported versions
 
 To find out what versions are currently available for your subscription and region, use the
-[az aks get-versions][az-aks-get-versions] command. The following example lists the available Kubernetes versions for
-the *EastUS* region:
+[az aks get-versions][az-aks-get-versions] command. The following example lists the available Kubernetes versions for the *EastUS* region:
 
 ```azurecli-interactive
 az aks get-versions --location eastus --output table
 ```
 
-The output is similar to the following example, which shows that Kubernetes version *1.14.6* is the most recent version
-available:
-
-```
-KubernetesVersion    Upgrades
--------------------  ------------------------
-1.14.6               None available
-1.14.5               1.14.6
-1.13.10              1.14.5, 1.14.6
-1.13.9               1.13.10, 1.14.5, 1.14.6
-1.12.8               1.13.9, 1.13.10
-1.12.7               1.12.8, 1.13.9, 1.13.10
-1.11.10              1.12.7, 1.12.8
-1.11.9               1.11.10, 1.12.7, 1.12.8
-1.10.13              1.11.9, 1.11.10
-1.10.12              1.10.13, 1.11.9, 1.11.10
-```
-
 ## FAQ
 
 **What happens when a customer upgrades a Kubernetes cluster with a minor version that is not supported?**
 
-If you are on the *n-4* version, you are outside of support and will be asked to upgrade. If your upgrade from version
-n-4 to n-3 succeeds, you are now within our support policies. For example:
+If you are on the *n-3* version, you are outside of support and will be asked to upgrade. If your upgrade from version n-3 to n-2 succeeds, you are now within our support policies. For example:
 
-- If the supported AKS versions are *1.13.a*, *1.12.b* + *1.12.c*, *1.11.d* + *1.11.e*, and *1.10.f* + *1.10.g* and you
-  are on *1.9.h* or *1.9.i*, you are outside of support.
-- If the upgrade from *1.9.h* or *1.9.i* to *1.10.f* or *1.10.g* succeeds, you are back in the within our support policies.
+- If the oldest supported AKS version is are *1.13.a* and you are on *1.12.b* or older, you are outside of support.
+- If the upgrade from *1.12.b* to *1.13.a* or higher succeeds, you are back in the within our support policies.
 
-Upgrades to versions older than *n-4* are not supported. In such cases, we recommend customers create new AKS clusters
-and redeploy their workloads.
+Upgrades to versions older than the supported window of *N-2* are not supported. In such cases, we recommend customers create new AKS clusters and redeploy their workloads with versions in the supported window.
 
 **What does 'Out of Support' mean**
 
@@ -204,16 +159,16 @@ runtime or other guarantees for clusters outside of the supported versions list.
 
 **What happens when a customer scales a Kubernetes cluster with a minor version that is not supported?**
 
-For minor versions not supported by AKS, scaling in or out continues to work without any issues.
+For minor versions not supported by AKS, scaling in or out should continue to work but it is highly recommended to upgrade to bring your cluster back into support.
 
 **Can a customer stay on a Kubernetes version forever?**
 
 Yes. However, if the cluster is not on one of the versions supported by AKS, the cluster is out of the AKS support
 policies. Azure does not automatically upgrade your cluster or delete it.
 
-**What version does the master support if the agent cluster is not in one of the supported AKS versions?**
+**What version does the control plane support if the node pool is not in one of the supported AKS versions?**
 
-The master is automatically updated to the latest supported version.
+The control plane must be within a window of versions from all node pools. For details on upgrading the control plane or node pools, visit documentation on [upgrading node pools](use-multiple-node-pools.md#upgrade-a-cluster-control-plane-with-multiple-node-pools).
 
 ## Next steps
 

articles/aks/supported-kubernetes-versions.md

@@ -34,7 +34,7 @@ The following limitations apply when you create and manage AKS clusters that sup
 * 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 may only contain lowercase alphanumeric characters and must begin with a lowercase letter. 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.
+* The AKS cluster can have a maximum of 800 nodes across those eight node pools.
 * All node pools must reside in the same subnet.
 
 ## Create an AKS cluster

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

@@ -123,7 +123,7 @@ No. Instances are distributed across upgrade domains and fault domains.
 
 ### Does Application Gateway support connection draining?
 
-Yes. You can set up connection draining to change members within a backend pool without disruption. This setup allows you to continue to send existing connections to their previous destination until either that connection closes or a configurable timeout expires. Connection draining waits for only current in-flight connections to finish. Application Gateway isn't aware of the application session state.
+Yes. You can set up connection draining to change members within a backend pool without disruption. For more information, see [connection draining section of Application Gateway](overview.md#connection-draining).
 
 ### Can I change instance size from medium to large without disruption?