Merge pull request #186282 from MicrosoftDocs/master

Merge master to live, 4 AM

Author: v-ccolin

articles/active-directory/develop/id-tokens.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 12/28/2021
+ms.date: 01/25/2022
 ms.author: hirsin
 ms.reviewer: hirsin
 ms.custom: aaddev, identityplatformtop40, fasttrack-edit
@@ -77,8 +77,8 @@ The table below shows the claims that are in most ID tokens by default (except w
 | `c_hash`| String |The code hash is included in ID tokens only when the ID token is issued with an OAuth 2.0 authorization code. It can be used to validate the authenticity of an authorization code. To understand how to do this validation, see the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken). |
 |`at_hash`| String |The access token hash is included in ID tokens only when the ID token is issued from the `/authorize` endpoint with an OAuth 2.0 access token. It can be used to validate the authenticity of an access token. To understand how to do this validation, see the [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken). This is not returned on ID tokens from the `/token` endpoint. |
 |`aio` | Opaque String | An internal claim used by Azure AD to record data for token reuse. Should be ignored.|
-|`preferred_username` | String | The primary username that represents the user. It could be an email address, phone number, or a generic username without a specified format. Its value is mutable and might change over time. Since this value can be changed, it must not be used to make authorization decisions. The `profile` scope is required to receive this claim.|
-|`email` | String | The `email` claim is present by default for guest accounts that have an email address.  Your app can request the email claim for managed users (those from the same tenant as the resource) using the `email` [optional claim](active-directory-optional-claims.md).  On the v2.0 endpoint, your app can also request the `email` OpenID Connect scope - you don't need to request both the optional claim and the scope to get the claim.  The email claim only supports addressable mail from the user's profile information. |
+|`preferred_username` | String |The primary username that represents the user. It could be an email address, phone number, or a generic username without a specified format. Its value is mutable and might change over time. Since it is mutable, this value must not be used to make authorization decisions. It can be used for username hints, however, and in human-readable UI as a username. The `profile` scope is required in order to receive this claim. Present only in v2.0 tokens.|
+|`email` | String | The `email` claim is present by default for guest accounts that have an email address.  Your app can request the email claim for managed users (those from the same tenant as the resource) using the `email` [optional claim](active-directory-optional-claims.md).  On the v2.0 endpoint, your app can also request the `email` OpenID Connect scope - you don't need to request both the optional claim and the scope to get the claim.|
 |`name` | String | The `name` claim provides a human-readable value that identifies the subject of the token. The value isn't guaranteed to be unique, it can be changed, and it's designed to be used only for display purposes. The `profile` scope is required to receive this claim. |
 |`nonce`| String | The nonce matches the parameter included in the original /authorize request to the IDP. If it does not match, your application should reject the token. |
 |`oid` | String, a GUID | The immutable identifier for an object in the Microsoft identity system, in this case, a user account. This ID uniquely identifies the user across applications - two different applications signing in the same user will receive the same value in the `oid` claim. The Microsoft Graph will return this ID as the `id` property for a given user account. Because the `oid` allows multiple apps to correlate users, the `profile` scope is required to receive this claim. Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they're considered different accounts, even though the user logs into each account with the same credentials. The `oid` claim is a GUID and cannot be reused. |

articles/aks/dapr.md

@@ -27,7 +27,7 @@ The AKS Dapr extension uses the Azure CLI to provision the Dapr control plane on
 - **dapr-placement**: Used for actors only. Creates mapping tables that map actor instances to pods
 - **dapr-sentry**: Manages mTLS between services and acts as a certificate authority. For more information read the [security overview][dapr-security].
 
-Once Dapr is installed on your AKS cluster, your application services now have the Dapr sidecar running alongside them. This enables you to immediately start using the Dapr building block APIs. For a more in-depth overview of the building block APIs and how to best use them, please see the [Dapr building blocks overview][building-blocks-concepts].
+Once Dapr is installed on your AKS cluster, you can begin to develop using the Dapr building block APIs by [adding a few annotations][dapr-deployment-annotations] to your deployments. For a more in-depth overview of the building block APIs and how to best use them, please see the [Dapr building blocks overview][building-blocks-concepts].
 
 > [!WARNING]
 > If you install Dapr through the AKS extension, our recommendation is to continue using the extension for future management of Dapr instead of the Dapr CLI. Combining the two tools can cause conflicts and result in undesired behavior.
@@ -271,3 +271,4 @@ az k8s-extension delete --resource-group myResourceGroup --cluster-name myAKSClu
 [dapr-configuration-options]: https://github.com/dapr/dapr/blob/master/charts/dapr/README.md#configuration
 [sample-application]: https://github.com/dapr/quickstarts/tree/master/hello-kubernetes#step-2---create-and-configure-a-state-store
 [dapr-security]: https://docs.dapr.io/concepts/security-concept/
+[dapr-deployment-annotations]: https://docs.dapr.io/operations/hosting/kubernetes/kubernetes-overview/#adding-dapr-to-a-kubernetes-deployment

articles/app-service/environment/overview.md

@@ -3,7 +3,7 @@ title: App Service Environment overview
 description: Overview on the App Service Environment
 author: madsd
 ms.topic: overview
-ms.date: 11/15/2021
+ms.date: 01/26/2022
 ms.author: madsd
 ms.custom: references_regions
 ---
@@ -40,32 +40,34 @@ The App Service Environment has many use cases including:
 - Network isolated application hosting
 - Multi-tier applications
 
-There are many networking features that enable apps in the multi-tenant App Service to reach network isolated resources or become network isolated themselves. These features are enabled at the application level. With an App Service Environment, there's no added configuration required for the apps to be in the virtual network. The apps are deployed into a network isolated environment that is already in a virtual network. If you really need a complete isolation story, you can also get your App Service Environment deployed onto dedicated hardware.
+There are many networking features that enable apps in the multi-tenant App Service to reach network isolated resources or become network isolated themselves. These features are enabled at the application level. With an App Service Environment, there's no added configuration required for the apps to be in the virtual network. The apps are deployed into a network-isolated environment that is already in a virtual network. If you really need a complete isolation story, you can also get your App Service Environment deployed onto dedicated hardware.
 
 ## Dedicated environment
 
 The App Service Environment is a single tenant deployment of the Azure App Service that runs in your virtual network. 
 
 Applications are hosted in App Service plans, which are created in an App Service Environment. The App Service plan is essentially a provisioning profile for an application host. As you scale your App Service plan out, you create more application hosts with all of the apps in that App Service plan on each host. A single App Service Environment v3 can have up to 200 total App Service plan instances across all of the App Service plans combined. A single Isolated v2 App Service plan can have up to 100 instances by itself.
 
+When you're deploying on dedicated hardware (hosts), you're limited in scaling across all App Service plans to the amount of cores in this type of environment. An App Service Environment deployed on dedicated hosts has 132 vCores available. I1v2 uses 2 vCores, I2v2 uses 4 vCores, and I3v2 uses 8 vCores per instance.
+
 ## Virtual network support
 
-The App Service Environment feature is a deployment of the Azure App Service into a single subnet in a customer's virtual network. When you deploy an app into an App Service Environment, the app will be exposed on the inbound address assigned to the App Service Environment. If your App Service Environment is deployed with an internal virtual IP (VIP), then the inbound address for all of the apps will be an address in the App Service Environment subnet. If your App Service Environment is deployed with an external VIP, then the inbound address will be an internet addressable address and your apps will be in public DNS.
+The App Service Environment feature is a deployment of the Azure App Service into a single subnet in a customer's virtual network. When you deploy an app into an App Service Environment, the app will be exposed on the inbound address assigned to the App Service Environment. If your App Service Environment is deployed with an internal virtual IP (VIP), then the inbound address for all of the apps will be an address in the App Service Environment subnet. If your App Service Environment is deployed with an external VIP, then the inbound address will be an internet-addressable address and your apps will be in public DNS.
 
 The number of addresses used by an App Service Environment v3 in its subnet will vary based on how many instances you have along with how much traffic. There are infrastructure roles that are automatically scaled depending on the number of App Service plans and the load. The recommended size for your App Service Environment v3 subnet is a `/24` CIDR block with 256 addresses in it as that can host an App Service Environment v3 scaled out to its limit.
 
-The apps in an App Service Environment do not need any features enabled to access resources in the same virtual network that the App Service Environment is in. If the App Service Environment virtual network is connected to another network, then the apps in the App Service Environment can access resources in those extended networks. Traffic can be blocked by user configuration on the network.
+The apps in an App Service Environment don't need any features enabled to access resources in the same virtual network that the App Service Environment is in. If the App Service Environment virtual network is connected to another network, then the apps in the App Service Environment can access resources in those extended networks. Traffic can be blocked by user configuration on the network.
 
-The multi-tenant version of Azure App Service contains numerous features to enable your apps to connect to your various networks. Those networking features enable your apps to act as if they were deployed in a virtual network. The apps in an App Service Environment v3 do not need any configuration to be in the virtual network. A benefit of using an App Service Environment over the multi-tenant service is that any network access controls to the App Service Environment hosted apps is external to the application configuration. With the apps in the multi-tenant service, you must enable the features on an app by app basis and use RBAC or policy to prevent any configuration changes.
+The multi-tenant version of Azure App Service contains numerous features to enable your apps to connect to your various networks. Those networking features enable your apps to act as if they were deployed in a virtual network. The apps in an App Service Environment v3 don't need any configuration to be in the virtual network. A benefit of using an App Service Environment over the multi-tenant service is that any network access controls to the App Service Environment hosted apps is external to the application configuration. With the apps in the multi-tenant service, you must enable the features on an app-by-app basis and use Role-based access control or policy to prevent any configuration changes.
 
 ## Feature differences
 
 Compared to earlier versions of the App Service Environment, there are some differences with App Service Environment v3. With App Service Environment v3:
 
 - There are no networking dependencies in the customer virtual network. You can secure all inbound and outbound as desired. Outbound traffic can be routed also as desired. 
 - You can deploy it enabled for zone redundancy. Zone redundancy can only be set during creation and only in regions where all App Service Environment v3 dependencies are zone redundant. 
-- You can deploy it on a dedicated host group. Host group deployments are not zone redundant. 
-- Scaling is much faster than with App Service Environment v2. While scaling still is not immediate as in the multi-tenant service, it is a lot faster.
+- You can deploy it on a dedicated host group. Host group deployments aren't zone redundant. 
+- Scaling is much faster than with App Service Environment v2. While scaling still isn't immediate as in the multi-tenant service, it's a lot faster.
 - Front end scaling adjustments are no longer required. The App Service Environment v3 front ends automatically scale to meet needs and are deployed on better hosts.
 - Scaling no longer blocks other scale operations within the App Service Environment v3 instance. Only one scale operation can be in effect for a combination of OS and size. For example, while your Windows small App Service plan was scaling, you could kick off a scale operation to run at the same time on a Windows medium or anything else other than Windows small. 
 - Apps in an internal VIP App Service Environment v3 can be reached across global peering. Access across global peering was not possible with previous versions.
@@ -84,9 +86,9 @@ There are a few features that are not available in App Service Environment v3 th
 
 With App Service Environment v3, there is a different pricing model depending on the type of App Service Environment deployment you have. The three pricing models are:
 
-- **App Service Environment v3**: If App Service Environment is empty, there is a charge as if you had one instance of Windows I1v2. The one instance charge is not an additive charge but is only applied if the App Service Environment is empty.
-- **Zone redundant App Service Environment v3**: There is a minimum charge of nine instances. There is no added charge for availability zone support if you have nine or more App Service plan instances. If you have less than nine instances (of any size) across App Service plans in the zone redundant App Service Environment, the difference between nine and the running instance count is charged as additional Windows I1v2 instances.
-- **Dedicated host App Service Environment v3**: With a dedicated host deployment, you are charged for two dedicated hosts per our pricing at App Service Environment v3 creation then a small percentage of the Isolated v2 rate per core charge as you scale.
+- **App Service Environment v3**: If App Service Environment is empty, there is a charge as if you had one instance of Windows I1v2. The one instance charge isn't an additive charge but is only applied if the App Service Environment is empty.
+- **Zone redundant App Service Environment v3**: There's a minimum charge of nine instances. There's no added charge for availability zone support if you have nine or more App Service plan instances. If you've fewer than nine instances (of any size) across App Service plans in the zone redundant App Service Environment, the difference between nine and the running instance count is charged as additional Windows I1v2 instances.
+- **Dedicated host App Service Environment v3**: With a dedicated host deployment, you're charged for two dedicated hosts per our pricing at App Service Environment v3 creation then a small percentage of the Isolated v2 rate per core charge as you scale.
 
 Reserved Instance pricing for Isolated v2 is available and is described in [How reservation discounts apply to Azure App Service](../../cost-management-billing/reservations/reservation-discount-app-service.md). The pricing, along with reserved instance pricing, is available at [App Service pricing](https://azure.microsoft.com/pricing/details/app-service/windows/) under **Isolated v2 plan**.