Merge pull request #179010 from MicrosoftDocs/master

11/08 8AM OOB Publish

Author: huypub

articles/active-directory-b2c/identity-provider-azure-ad-single-tenant.md

@@ -76,7 +76,7 @@ If you want to get the `family_name` and `given_name` claims from Azure AD, you
 1. Select **Add optional claim**.
 1. For the **Token type**, select **ID**.
 1. Select the optional claims to add, `family_name` and `given_name`.
-1. Click **Add**.
+1. Select **Add**. If **Turn on the Microsoft Graph email permission (required for claims to appear in token)** appears, enable it, and then select **Add** again.
 
 ## [Optional] Verify your app authenticity
 
@@ -97,8 +97,7 @@ If you want to get the `family_name` and `given_name` claims from Azure AD, you
     https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration
     ```
 
-    For example, `https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration`.
-    For example, `https://login.microsoftonline.com/contoso.com/v2.0/.well-known/openid-configuration`.
+ For example, `https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration`. If you use a custom domain, replace `contoso.com` with your custom domain in `https://login.microsoftonline.com/contoso.com/v2.0/.well-known/openid-configuration`.
 
 1. For **Client ID**, enter the application ID that you previously recorded.
 1. For **Client secret**, enter the client secret that you previously recorded.
@@ -121,7 +120,8 @@ At this point, the Azure AD identity provider has been set up, but it's not yet
 
 1. In your Azure AD B2C tenant, select **User flows**.
 1. Click the user flow that you want to add the Azure AD identity provider.
-1. Under the **Social identity providers**, select **Contoso Azure AD**.
+1. Under **Settings**, select **Identity providers**
+1. Under **Custom identity providers**, select **Contoso Azure AD**.
 1. Select **Save**.
 1. To test your policy, select **Run user flow**.
 1. For **Application**, select a web application that you [previously registered](tutorial-register-applications.md). The **Reply URL** should show `https://jwt.ms`. 

articles/active-directory/conditional-access/concept-condition-filters-for-devices.md

@@ -4,7 +4,7 @@ description: Use filter for devices in Conditional Access to enhance security po
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 10/26/2021
+ms.date: 11/08/2021
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -19,7 +19,6 @@ When creating Conditional Access policies, administrators have asked for the abi
 
 :::image type="content" source="media/concept-condition-filters-for-devices/create-filter-for-devices-condition.png" alt-text="Creating a filter for device in Conditional Access policy conditions":::
 
-
 ## Common scenarios
 
 There are multiple scenarios that organizations can now enable using filter for devices condition. Below are some core scenarios with examples of how to use this new condition.
@@ -84,6 +83,10 @@ Policy 2: All users with the directory role of Global administrator, accessing t
 1. Confirm your settings and set **Enable policy** to **On**.
 1. Select **Create** to create to enable your policy.
 
+### Setting attribute values
+
+Setting extension attributes is made possible through the Graph API. For more information about setting device attributes, see the article [Update device](/graph/api/device-update?view=graph-rest-1.0&tabs=http#example-2--write-extensionattributes-on-a-device).
+
 ### Filter for devices Graph API
 
 The filter for devices API is available in Microsoft Graph v1.0 endpoint and can be accessed using https://graph.microsoft.com/v1.0/identity/conditionalaccess/policies/. You can configure a filter for devices when creating a new Conditional Access policy or you can update an existing policy to configure the filter for devices condition. To update an existing policy, you can do a patch call on the Microsoft Graph v1.0 endpoint mentioned above by appending the policy ID of an existing policy and executing the following request body. The example here shows configuring a filter for devices condition excluding device that are not marked as SAW devices. The rule syntax can consist of more than one single expression. To learn more about the syntax, see [dynamic membership rules for groups in Azure Active Directory](../enterprise-users/groups-dynamic-membership.md). 
@@ -139,6 +142,7 @@ The filter for devices condition in Conditional Access evaluates policy based on
 
 ## Next steps
 
+- [Update device Graph API](/graph/api/device-update?view=graph-rest-1.0&tabs=http)
 - [Conditional Access: Conditions](concept-conditional-access-conditions.md)
 - [Common Conditional Access policies](concept-conditional-access-policy-common.md)
 - [Securing devices as part of the privileged access story](/security/compass/privileged-access-devices)

articles/active-directory/verifiable-credentials/decentralized-identifier-overview.md

@@ -122,6 +122,6 @@ The roles in this scenario are:
 
 Now that you know about DIDs and verifiable credentials try them yourself by following our get started article or one of our articles providing more detail on verifiable credential concepts.
 
-- [Get started with verifiable credentials](get-started-verifiable-credentials.md)
+- [Get started with verifiable credentials](verifiable-credentials-configure-tenant.md)
 - [How to customize your credentials](credential-design.md)
 - [Verifiable credentials FAQ](verifiable-credentials-faq.md)

articles/aks/availability-zones.md

@@ -27,15 +27,20 @@ AKS clusters can currently be created using availability zones in the following
 * Australia East
 * Brazil South
 * Canada Central
+* Central India
 * Central US
+* East Asia
 * East US 
 * East US 2
 * France Central
 * Germany West Central
 * Japan East
+* Korea Central
 * North Europe
+* Norway East
 * Southeast Asia
 * South Central US
+* Sweden Central
 * UK South
 * US Gov Virginia
 * West Europe

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

@@ -213,7 +213,7 @@ For more information on customizing the `applicationInitialization` element, see
 
 You can also customize the warm-up behavior with one or both of the following [app settings](configure-common.md):
 
-- `WEBSITE_SWAP_WARMUP_PING_PATH`: The path to ping to warm up your site. Add this app setting by specifying a custom path that begins with a slash as the value. An example is `/statuscheck`. The default value is `/`. 
+- `WEBSITE_SWAP_WARMUP_PING_PATH`: The path to ping over HTTP to warm up your site. Add this app setting by specifying a custom path that begins with a slash as the value. An example is `/statuscheck`. The default value is `/`. 
 - `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.
 - `WEBSITE_WARMUP_PATH`: A relative path on the site that should be pinged whenever the site restarts (not only during slot swaps). Example values include `/statuscheck` or the root path, `/`.
 

articles/app-service/reference-app-settings.md

@@ -293,7 +293,7 @@ For more information on deployment slots, see [Set up staging environments in Az
 |`WEBSITE_SLOT_NAME`| Read-only. Name of the current deployment slot. The name of the production slot is `Production`. ||
 |`WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS`| By default, the versions for site extensions are specific to each slot. This prevents unanticipated application behavior due to changing extension versions after a swap. If you want the extension versions to swap as well, set to `1` on *all slots*. ||
 |`WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS`| Designates certain settings as [sticky or not swappable by default](deploy-staging-slots.md#which-settings-are-swapped). Default is `true`. Set this setting to `false` or `0` for *all deployment slots* to make them swappable instead. There's no fine-grain control for specific setting types. ||
-|`WEBSITE_SWAP_WARMUP_PING_PATH`| Path to ping to warm up the target slot in a swap, beginning with a slash. The default is `/`, which pings the root path. | `/statuscheck` |
+|`WEBSITE_SWAP_WARMUP_PING_PATH`| Path to ping to warm up the target slot in a swap, beginning with a slash. The default is `/`, which pings the root path over HTTP. | `/statuscheck` |
 |`WEBSITE_SWAP_WARMUP_PING_STATUSES`| Valid HTTP response codes for the warm-up operation during a swap. If the returned status code isn't in the list, the warmup and swap operations are stopped. By default, all response codes are valid. | `200,202` |
 | `WEBSITE_SLOT_NUMBER_OF_TIMEOUTS_BEFORE_RESTART` | During a slot swap, maximum number of timeouts after which we force restart the site on a specific VM instance. The default is `3`. ||
 | `WEBSITE_SLOT_MAX_NUMBER_OF_TIMEOUTS` | During a slot swap, maximum number of timeout requests for a single URL to make before giving up. The default is `5`. ||

articles/azure-arc/servers/manage-automatic-vm-extension-upgrade.md

@@ -0,0 +1,98 @@
+---
+title: Automatic Extension Upgrade (preview) for Azure Arc-enabled servers
+description: Learn how to enable the Automatic Extension Upgrade (preview) for your Azure Arc-enabled servers.
+ms.topic: conceptual
+ms.date: 11/06/2021
+---
+
+# Automatic Extension Upgrade (preview) for Azure Arc-enabled servers
+
+Automatic Extension Upgrade (preview) is available for Azure Arc-enabled servers that have supported VM extensions installed. When Automatic Extension Upgrade (preview) is enabled on a machine, the extension is upgraded automatically whenever the extension publisher releases a new version for that extension.
+
+ Automatic Extension Upgrade has the following features:
+
+- You can opt in and out of automatic upgrades at any time.
+- Each supported extension is enrolled individually, and you can choose which extensions to upgrade automatically.
+- Supported in all public cloud regions.
+
+> [!NOTE]
+> In this release, only the Azure CLI is supported to configure Automatic Extension Upgrade.
+
+## How does Automatic Extension Upgrade work?
+
+The extension upgrade process replaces the existing Azure VM extension version supported by Azure Arc-enabled servers with a new version of the same extension when published by the extension publisher.
+
+A failed extension update is automatically retried. A retry is attempted every few days automatically without user intervention.
+
+### Availability-first updates
+
+The availability-first model for platform orchestrated updates ensures that availability configurations in Azure are respected across multiple availability levels.
+
+For a group of Arc-enabled servers undergoing an update, the Azure platform will orchestrate updates following the model described in the [Automation Extension Upgrade](../../virtual-machines/automatic-extension-upgrade.md#availability-first-updates). However, there are some notable differences between Arc-enabled servers and Azure VMs:
+
+**Across regions:**
+
+- Geo-paired regions are not applicable.
+
+**Within a region:**
+
+- Availability Zones are not applicable.
+- Machines are batched on a best effort basis to avoid concurrent updates for all machines registered with Arc-enabled servers in a subscription.  
+
+## Supported extensions
+
+Automatic Extension Upgrade (preview) supports the following extensions (and more are added periodically):
+
+- Azure Monitor Agent - Linux and Windows
+- Azure Security agent - Linux and Windows
+- Dependency agent – Linux and Windows
+- Key Vault Extension - Linux only
+- Log Analytics agent (OMS agent) - Linux only
+
+## Enabling Automatic Extension Upgrade (preview)
+
+To enable Automatic Extension Upgrade (preview) for an extension, you must ensure the property `enable-auto-upgrade` is set to `true` and added to every extension definition individually.
+
+Use the [az connectedmachine extension](/cli/azure/connectedmachine/extension) cmdlet with the `--name`, `--machine-name`, `--enable-auto-upgrade`, and `--resource-group` parameters.
+
+```azurecli
+az connectedmachine extension update \
+    --resource-group resourceGroupName \
+    --machine-name machineName \
+    --name DependencyAgentLinux \
+    --enable-auto-upgrade true
+```
+
+To check the status of Automatic Extension Upgrade (preview) for all extensions on an Arc-enabled server, run the following command:
+
+```azurecli
+az connectedmachine extension list --resource-group resourceGroupName --machine-name machineName --query "[].{Name:name, AutoUpgrade:properties.enableAutoUpgrade}" --output table
+```
+
+## Extension upgrades with multiple extensions
+
+A machine managed by Arc-enabled servers can have multiple extensions with automatic extension upgrade enabled. The same machine can also have other extensions without automatic extension upgrade enabled.
+
+If multiple extension upgrades are available for a machine, the upgrades may be batched together, but each extension upgrade is applied individually on a machine. A failure on one extension does not impact the other extension(s) to be upgraded. For example, if two extensions are scheduled for an upgrade, and the first extension upgrade fails, the second extension will still be upgraded.
+
+## Disable Automatic Extension Upgrade
+
+To disable Automatic Extension Upgrade (preview) for an extension, you must ensure the property `enable-auto-upgrade` is set to `false` and added to every extension definition individually.
+
+### Using the Azure CLI
+
+Use the [az connectedmachine extension ](/cli/azure/connectedmachine/extension) cmdlet with the `--name`, `--machine-name`, `--enable-auto-upgrade`, and `--resource-group` parameters.
+
+```azurecli
+az connectedmachine extension update \
+    --resource-group resourceGroupName \
+    --machine-name machineName \
+    --name DependencyAgentLinux \
+    --enable-auto-upgrade false
+```
+
+## Next steps
+
+- You can deploy, manage, and remove VM extensions using the [Azure CLI](manage-vm-extensions-cli.md), [PowerShell](manage-vm-extensions-powershell.md), or [Azure Resource Manager templates](manage-vm-extensions-template.md).
+
+- Troubleshooting information can be found in the [Troubleshoot VM extensions guide](troubleshoot-vm-extensions.md).

articles/azure-arc/servers/toc.yml

@@ -73,6 +73,8 @@
         href: manage-vm-extensions-powershell.md
       - name: Deploy extensions using ARM template
         href: manage-vm-extensions-template.md
+      - name: Automatic extension upgrade
+        href: manage-automatic-vm-extension-upgrade.md
     - name: Use managed identities on server
       href: managed-identity-authentication.md
     - name: Manage agent

articles/azure-functions/create-first-function-cli-csharp.md

@@ -8,31 +8,22 @@ adobe-target: true
 adobe-target-activity: DocsExp–386541–A/B–Enhanced-Readability-Quickstarts–2.19.2021
 adobe-target-experience: Experience B
 adobe-target-content: ./create-first-function-cli-csharp-ieux
-zone_pivot_groups: runtime-version-programming-functions
 ---
 
 # Quickstart: Create a C# function in Azure from the command line
 
-[!INCLUDE [functions-runtime-version-dotnet](../../includes/functions-runtime-version-dotnet.md)]
-
 In this article, you use command-line tools to create a C# function that responds to HTTP requests. After testing the code locally, you deploy it to the serverless environment of Azure Functions.
 
 [!INCLUDE [functions-dotnet-execution-model](../../includes/functions-dotnet-execution-model.md)]
 
-Completing this quickstart incurs a small cost of a few USD cents or less in your Azure account.
+This article creates an HTTP triggered function that runs on .NET 6.0. There is also a [Visual Studio Code-based version](create-first-function-vs-code-csharp.md) of this article.
 
-There is also a [Visual Studio Code-based version](create-first-function-vs-code-csharp.md) of this article.
+Completing this quickstart incurs a small cost of a few USD cents or less in your Azure account.
 
 ## Configure your local environment
 
 Before you begin, you must have the following:
 
-::: zone pivot="programming-runtime-functions-v3"
-[!INCLUDE [functions-cli-dotnet-prerequisites](../../includes/functions-cli-dotnet-prerequisites.md)]
-::: zone-end
-::: zone pivot="programming-runtime-functions-v4"
-# [In-process](#tab/in-process)
-
 + [.NET 6.0 SDK](https://dotnet.microsoft.com/download)
 
 + [Azure Functions Core Tools](./functions-run-local.md#v2) version 4.x.
@@ -43,22 +34,6 @@ Before you begin, you must have the following:
 
     + The Azure [Az PowerShell module](/powershell/azure/install-az-ps) version 5.9.0 or later.
 
-# [Isolated process](#tab/isolated-process)
-
-+ [.NET 6.0 SDK](https://dotnet.microsoft.com/download/dotnet/6.0)
-
-+ [.NET Core 3.1 SDK](https://dotnet.microsoft.com/download). Required by the build process.
-
-+ [Azure Functions Core Tools](./functions-run-local.md#v2) version 4.x.
-
-+ One of the following tools for creating Azure resources:
-
-    + [Azure CLI](/cli/azure/install-azure-cli) version 2.4 or later.
-
-    + The Azure [Az PowerShell module](/powershell/azure/install-az-ps) version 5.9.0 or later.
----
-::: zone-end
-
 You also need an Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?ref=microsoft.com&utm_source=microsoft.com&utm_medium=docs&utm_campaign=visualstudio).
 
 ### Prerequisite check
@@ -67,7 +42,7 @@ Verify your prerequisites, which depend on whether you are using Azure CLI or Az
 
 # [Azure CLI](#tab/azure-cli)
 
-+ In a terminal or command window, run `func --version` to check that the Azure Functions Core Tools are version 3.x.
++ In a terminal or command window, run `func --version` to check that the Azure Functions Core Tools are version 4.x.
 
 + Run `dotnet --list-sdks` to check that the required versions are installed.
 
@@ -77,7 +52,7 @@ Verify your prerequisites, which depend on whether you are using Azure CLI or Az
 
 # [Azure PowerShell](#tab/azure-powershell)
 
-+ In a terminal or command window, run `func --version` to check that the Azure Functions Core Tools are version 3.x.
++ In a terminal or command window, run `func --version` to check that the Azure Functions Core Tools are version 4.x.
 
 + Run `dotnet --list-sdks` to check that the required versions are installed.
 
@@ -227,10 +202,8 @@ To learn more, see [Azure Functions HTTP triggers and bindings](./functions-bind
 
     ---
 
-    ::: zone pivot="programming-runtime-functions-v4"
     > [!NOTE]
     > This command creates a function app using the 3.x version of the Azure Functions runtime. The `func azure functionapp publish` command that you'll run later updates the app to version 4.x.
-    ::: zone-end
 
     In the previous example, replace `<STORAGE_NAME>` with the name of the account you used in the previous step, and replace `<APP_NAME>` with a globally unique name appropriate to you. The `<APP_NAME>` is also the default DNS domain for the function app.
 

articles/azure-functions/create-first-function-cli-java.md

@@ -29,7 +29,7 @@ Before you begin, you must have the following:
 
 + An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?ref=microsoft.com&utm_source=microsoft.com&utm_medium=docs&utm_campaign=visualstudio).
 
-+ The [Azure Functions Core Tools](functions-run-local.md#v2) version 3.x..
++ The [Azure Functions Core Tools](functions-run-local.md#v2) version 4.x.
 
 + The [Azure CLI](/cli/azure/install-azure-cli) version 2.4 or later.
 
@@ -39,7 +39,7 @@ Before you begin, you must have the following:
 
 ### Prerequisite check
 
-+ In a terminal or command window, run `func --version` to check that the Azure Functions Core Tools are version 3.x.
++ In a terminal or command window, run `func --version` to check that the Azure Functions Core Tools are version 4.x.
 
 + Run `az --version` to check that the Azure CLI version is 2.4 or later.