Merge pull request #186041 from MicrosoftDocs/master

1/24 PM Publish

Author: huypub

articles/active-directory/app-provisioning/sap-successfactors-integration-reference.md

@@ -296,6 +296,20 @@ The SuccessFactors connector supports expansion of the position object. To expan
 | positionNameFR | $.employmentNav.results[0].jobInfoNav.results[0].positionNav.externalName_fr_FR |
 | positionNameDE | $.employmentNav.results[0].jobInfoNav.results[0].positionNav.externalName_de_DE |
 
+### Provisioning users in the Onboarding module
+Inbound user provisioning from SAP SuccessFactors to on-premises Active Directory and Azure AD now supports advance provisioning of pre-hires present in the SAP SuccessFactors Onboarding 2.0 module. Upon encountering a new hire profile with future start date, the Azure AD provisioning service queries SAP SuccessFactors to get new hires with one of the following status codes: `active`, `inactive`, `active_external`. The status code `active_external` corresponds to pre-hires present in the SAP SuccessFactors Onboarding 2.0 module. For a description of these status codes, refer to [SAP support note 2736579](https://launchpad.support.sap.com/#/notes/0002736579).
+
+The default behavior of the provisioning service is to process pre-hires in the Onboarding module. 
+
+If you want to exclude processing of pre-hires in the Onboarding module, update your provisioning job configuration as follows: 
+1. Open the attribute-mapping blade of your SuccessFactors provisioning app.
+1. Under show advanced options, edit the SuccessFactors attribute list to add a new attribute called `userStatus`.
+1. Set the JSONPath API expression for this attribute as: `$.employmentNav.results[0].userNav.status`
+1. Save the schema to return back to the attribute mapping blade. 
+1. Edit the Source Object scope to apply a scoping filter `userStatus NOT EQUALS active_external`
+1. Save the mapping and validate that the scoping filter works using provisioning on demand. 
+
+
 ## Writeback scenarios
 
 This section covers different write-back scenarios. It recommends configuration approaches based on how email and phone number is setup in SuccessFactors.

articles/active-directory/develop/v2-oauth2-client-creds-grant-flow.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 10/20/2021
+ms.date: 01/24/2022
 ms.author: hirsin
 ms.reviewer: marsma
 ms.custom: aaddev, identityplatformtop40
@@ -54,7 +54,7 @@ This type of authorization is common for daemons and service accounts that need
 
 In order to enable this ACL-based authorization pattern, Azure AD doesn't require that applications be authorized to get tokens for another application. Thus, app-only tokens can be issued without a `roles` claim. Applications that expose APIs must implement permission checks in order to accept tokens.
 
-If you'd like to prevent applications from getting role-less app-only access tokens for your application, [ensure that user assignment requirements are enabled for your app](../manage-apps/assign-user-or-group-access-portal.md). This will block users and applications without assigned roles from being able to get a token for this application. 
+If you'd like to prevent applications from getting role-less app-only access tokens for your application, [ensure that user assignment requirements are enabled for your app](../manage-apps/what-is-access-management.md#requiring-user-assignment-for-an-app). This will block users and applications without assigned roles from being able to get a token for this application. 
 
 ### Application permissions
 
@@ -67,7 +67,7 @@ Instead of using ACLs, you can use APIs to expose a set of **application permiss
 
 To use application permissions with your own API (as opposed to Microsoft Graph), you must first [expose the API](howto-add-app-roles-in-azure-ad-apps.md) by defining scopes in the API's app registration in the Azure portal. Then, [configure access to the API](howto-add-app-roles-in-azure-ad-apps.md#assign-app-roles-to-applications) by selecting those permissions in your client application's app registration. If you haven't exposed any scopes in your API's app registration, you won't be able to specify application permissions to that API in your client application's app registration in the Azure portal.
 
-When authenticating as an application (as opposed to with a user), you can't use *delegated permissions* - scopes that are granted by a user - because there is no user for you app to act on behalf of. You must use application permissions, also known as roles, that are granted by an admin for the application or via pre-authorization by the web API.
+When authenticating as an application (as opposed to with a user), you can't use *delegated permissions* - scopes that are granted by a user - because there is no user for your app to act on behalf of. You must use application permissions, also known as roles, that are granted by an admin for the application or via pre-authorization by the web API.
 
 For more information about application permissions, see [Permissions and consent](v2-permissions-and-consent.md#permission-types).
 

articles/active-directory/roles/administrative-units.md

@@ -89,7 +89,8 @@ The following sections describe current support for administrative unit scenario
 
 | Permissions |   Graph/PowerShell   | Azure portal | Microsoft 365 admin center |
 | --- | --- | --- | --- |
-| Administrative unit-scoped management of user properties, passwords, and licenses   |    Supported     |  Supported   |   Supported |
+| Administrative unit-scoped management of user properties, passwords   |    Supported     |  Supported   |   Supported |
+| Administrative unit-scoped management of user licenses | Supported | Not Supported | Supported |
 | Administrative unit-scoped blocking and unblocking of user sign-ins    |   Supported   |    Supported   |    Supported |
 | Administrative unit-scoped management of user multifactor authentication credentials   |    Supported   |   Supported   |   Not supported |
 

articles/aks/TOC.yml

@@ -82,6 +82,8 @@
       href: concepts-scale.md
     - name: Node auto-repair
       href: node-auto-repair.md
+    - name: Multi-instance GPU Node pool (preview)
+      href: gpu-multi-instance.md
     - name: Service meshes
       href: servicemesh-about.md
     - name: Sustainable software engineering

articles/aks/gpu-multi-instance.md

@@ -0,0 +1,189 @@
+---
+title: Multi-instance GPU Node pool (preview)
+description: Learn how to create a Multi-instance GPU Node pool and schedule tasks on it
+services: container-service
+ms.topic: article
+ms.date: 1/24/2022
+ms.author: juda
+---
+
+# Multi-instance GPU Node pool
+
+Nvidia's A100 GPU can be divided in up to seven independent instances. Each instance has their own memory and Stream Multiprocessor (SM). For more information on the Nvidia A100, follow [Nvidia A100 GPU][Nvidia A100 GPU]. 
+
+This article will walk you through how to create a multi-instance GPU node pool on Azure Kubernetes Service clusters and schedule tasks.
+
+[!INCLUDE [preview features callout](./includes/preview/preview-callout.md)]
+
+## GPU Instance Profile 
+
+GPU Instance Profiles define how a GPU will be partitioned. The following table shows the available GPU Instance Profile for the `Standard_ND96asr_v4`, the only instance type that supports the A100 GPU at this time.
+
+
+| Profile Name | Fraction of SM |Fraction of Memory  | Number of Instances created |
+|--|--|--|--|
+| MIG 1g.5gb | 1/7 | 1/8 | 7 |
+| MIG 2g.10gb | 2/7 | 2/8 | 3 |
+| MIG 3g.20gb | 3/7 | 4/8 | 2 |
+| MIG 4g.20gb | 4/7 | 4/8 | 1 |
+| MIG 7g.40gb | 7/7 | 8/8 | 1 |
+
+As an example, the GPU Instance Profile of `MIG 1g.5gb` indicates that each GPU instance will have 1g SM(Computing resource) and 5gb memory. In this case, the GPU will be partitioned into seven instances.
+
+The available GPU Instance Profiles available for this instance size are `MIG1g`, `MIG2g`, `MIG3g`, `MIG4g`, `MIG7g`
+
+> [!IMPORTANT]
+> The applied GPU Instance Profile cannot be changed after node pool creation. 
+
+
+## Create an AKS cluster
+To get started, create a resource group and an AKS cluster. If you already have a cluster, you can skip this step. Follow the example below to the resource group name `myresourcegroup` in the `southcentralus` region:
+
+```azurecli-interactive
+az group create --name myresourcegroup --location southcentralus
+```
+
+```azurecli-interactive
+az aks create \
+    --resource-group myresourcegroup \
+    --name migcluster\
+    --node-count 1
+```
+
+## Create a multi-instance GPU node pool
+
+You can choose to either use the `az` command line or http request to the ARM API to create the node pool
+
+### Azure CLI
+If you're using command line, use the `az aks nodepool add` command to create the node pool and specify the GPU instance profile through `--gpu-instance-profile`
+```
+
+az aks nodepool add \
+    --name mignode \
+    --resourcegroup myresourcegroup \
+    --cluster-name migcluster \
+    --node-size Standard_ND96asr_v4 \
+    --gpu-instance-profile MIG1g
+```
+
+### HTTP request
+
+If you're using http request, you can place GPU instance profile in the request body:
+```
+{
+    "properties": {
+        "count": 1,
+        "vmSize": "Standard_ND96asr_v4",
+        "type": "VirtualMachineScaleSets",
+        "gpuInstanceProfile": "MIG1g"
+    }
+}
+```
+
+
+
+
+## Run tasks using kubectl 
+
+### MIG strategy 
+Before you install the Nvidia plugins, you need to specify which strategy to use for GPU partitioning. 
+
+The two strategies "Single" and "Mixed" won't affect how you execute CPU workloads, but how GPU resources will be displayed.
+
+- Single Strategy
+
+  The single strategy treats every GPU instance as a GPU. If you're using this strategy, the GPU resources will be displayed as:
+
+  ```
+  nvidia.com/gpu: 1
+  ```
+
+- Mixed Strategy
+
+  The mixed strategy will expose the GPU instances and the GPU instance profile. If you use this strategy, the GPU resource will be displayed as:
+
+  ```
+  nvidia.com/mig1g.5gb: 1
+  ```
+
+### Install the NVIDIA device plugin and GPU feature discovery
+
+Set your MIG Strategy
+```
+export MIG_STRATEGY=single
+```
+or
+```
+export MIG_STRATEGY=mixed
+```
+
+Install the Nvidia device plugin and GPU feature discovery using helm  
+
+```
+helm repo add nvdp https://nvidia.github.io/k8s-device-plugin
+helm repo add nvgfd https://nvidia.github.io/gpu-feature-discovery
+helm repo update #do not forget to update the helm repo
+```
+
+```
+helm install \
+--version=0.7.0 \
+--generate-name \
+--set migStrategy=${MIG_STRATEGY} \
+nvdp/nvidia-device-plugin
+```
+
+```
+helm install \
+--version=0.2.0 \
+--generate-name \
+--set migStrategy=${MIG_STRATEGY} \
+nvgfd/gpu-feature-discovery
+```
+
+
+### Confirm multi-instance GPU capability
+As an example, if you used MIG1g as the GPU instance profile, confirm the node has multi-instance GPU capability by running:
+```
+kubectl describe mignode
+```
+If you're using single strategy, you'll see:
+```
+Allocable:
+    nvidia.com/gpu: 56
+```
+If you're using mixed strategy, you'll see:
+```
+Allocable:
+    nvidia.com/mig-1g.5gb: 56
+```
+
+### Schedule work
+Use the `kubectl` run command to schedule work using single strategy:
+```
+kubectl run -it --rm \
+--image=nvidia/cuda:11.0-base \
+--restart=Never \
+--limits=nvidia.com/mig-1g.5gb=1 \
+mixed-strategy-example -- nvidia-smi -L
+```
+
+Use the `kubectl` run command to schedule work using mixed strategy:
+```
+kubectl run -it --rm \
+--image=nvidia/cuda:11.0-base \
+--restart=Never \
+--limits=nvidia.com/gpu=1 \
+single-strategy-example -- nvidia-smi -L
+```
+
+
+## Troubleshooting
+- If you do not see multi-instance GPU capability after the node pool has been created, confirm the API version is not older than 2021-08-01.
+
+<!-- LINKS - internal -->
+
+
+<!-- LINKS - external-->
+[Nvidia A100 GPU]:https://www.nvidia.com/en-us/data-center/a100/
+

articles/application-gateway/how-to-troubleshoot-application-gateway-session-affinity-issues.md

@@ -3,11 +3,11 @@ title: Troubleshoot session affinity issues
 titleSuffix: Azure Application Gateway
 description: This article provides information on how to troubleshoot session affinity issues in Azure Application Gateway
 services: application-gateway
-author: KumudD
+author: vhorne
 ms.service: application-gateway
 ms.topic: troubleshooting
-ms.date: 11/14/2019
-ms.author: kumud
+ms.date: 01/24/2022
+ms.author: victorh
 ---
 
 # Troubleshoot Azure Application Gateway session affinity issues
@@ -44,9 +44,9 @@ Sometimes the session affinity issues might occur when you forget to enable “C
 
    ![Screenshot shows SETTINGS with H T T P settings selected.](./media/how-to-troubleshoot-application-gateway-session-affinity-issues/troubleshoot-session-affinity-issues-1.png)
 
-4. Click **appGatewayBackendHttpSettings** on the right side to check whether you have selected **Enabled** for Cookie based affinity.
+4. Select the HTTP setting, and on the **Add HTTP setting** page, check if **Cookie based affinity** is enabled.
 
-   ![Screenshot shows the gateway settings for an app gateway, inlcuidng whether Cookie based affinity is selected.](./media/how-to-troubleshoot-application-gateway-session-affinity-issues/troubleshoot-session-affinity-issues-2.jpg)
+   ![Screenshot shows the gateway settings for an app gateway, including whether Cookie based affinity is selected.](./media/how-to-troubleshoot-application-gateway-session-affinity-issues/troubleshoot-session-affinity-issues-2.png)
 
 
 
@@ -105,53 +105,24 @@ You can collect additional logs and analyze them to troubleshoot the issues rela
 
 To collect the Application Gateway logs, follow the instructions:
 
-Enable logging through the Azure portal
+Enable logging using the Azure portal.
 
-1. In the [Azure portal](https://portal.azure.com/), find your resource and then click **Diagnostic logs**.
+1. In the [Azure portal](https://portal.azure.com/), find your resource and then select **Diagnostic setting**.
 
-   For Application Gateway, three logs are available: Access log, Performance log, Firewall log
+   For Application Gateway, three logs are available: Access log, Performance log, and Firewall log.
 
-2. To start to collect data, click **Turn on diagnostics**.
+2. To start to collect data, select **Add diagnostic setting**.
 
-   ![Screenshot shows an application gateway with Diagnostics logs selected.](./media/how-to-troubleshoot-application-gateway-session-affinity-issues/troubleshoot-session-affinity-issues-5.png)
+   ![Screenshot shows an application gateway with Diagnostics settings selected.](./media/how-to-troubleshoot-application-gateway-session-affinity-issues/troubleshoot-session-affinity-issues-5.png)
 
-3. The **Diagnostics settings** blade provides the settings for the diagnostic logs. In this example, Log Analytics stores the logs. Click **Configure** under **Log Analytics** to set your workspace. You can also use event hubs and a storage account to save the diagnostic logs.
+3. The **Diagnostic setting** page provides the settings for the diagnostic logs. In this example, Log Analytics stores the logs. You can also use event hubs and a storage account to save the diagnostic logs.
 
    ![Screenshot shows the Diagnostics settings pane with Log Analytics Configure selected.](./media/how-to-troubleshoot-application-gateway-session-affinity-issues/troubleshoot-session-affinity-issues-6.png)
 
-4. Confirm the settings and then click **Save**.
+4. Confirm the settings and then select **Save**.
 
-   ![Screenshot shows the Diagnostics settings pane with Save selected.](./media/how-to-troubleshoot-application-gateway-session-affinity-issues/troubleshoot-session-affinity-issues-7.png)
 
-#### View and analyze the Application Gateway access logs
 
-1. In the Azure portal under the Application Gateway resource view, select **Diagnostics logs** in the **MONITORING** section .
-
-   ![Screenshot shows MONITORING with Diagnostics logs selected.](./media/how-to-troubleshoot-application-gateway-session-affinity-issues/troubleshoot-session-affinity-issues-8.png)
-
-2. On the right side, select “**ApplicationGatewayAccessLog**“ in the drop-down list under **Log categories.**  
-
-   ![Screenshot shows the Log categories dropdown list with ApplicationGatewayAccessLog selected.](./media/how-to-troubleshoot-application-gateway-session-affinity-issues/troubleshoot-session-affinity-issues-9.png)
-
-3. In the Application Gateway Access Log list, click the log you want to analyze and export, and then export the JSON file.
-
-4. Convert the JSON file that you exported in step 3 to CSV file and view them in Excel, Power BI, or any other data-visualization tool.
-
-5. Check the following data:
-
-- **ClientIP**– This is the client IP address from the connecting client.
-- **ClientPort** - This is the source port from the connecting client for the request.
-- **RequestQuery** – This indicates the destination server that the request is received.
-- **Server-Routed**: Back-end pool instance that the request is received.
-- **X-AzureApplicationGateway-LOG-ID**: Correlation ID used for the request. It can be used to troubleshoot traffic issues on the back-end servers. For example: X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.0.2.4.
-
-  - **SERVER-STATUS**: HTTP response code that Application Gateway received from the back end.
-
-  ![Screenshot shows server status in plain text, mostly obscured, with clientPort and SERVER-ROUTED highlighted.](./media/how-to-troubleshoot-application-gateway-session-affinity-issues/troubleshoot-session-affinity-issues-11.png)
-
-If you see two items are coming from the same ClientIP and Client Port, and they are sent to the same back-end server, that means the Application Gateway configured correctly.
-
-If you see two items are coming from the same ClientIP and Client Port, and they are sent to the different back-end servers, that means the request is bouncing between backend servers, select “**Application is using cookie-based affinity but requests still bouncing between back-end servers**” at the bottom to troubleshoot it.
 
 ### Use web debugger to capture and analyze the HTTP or HTTPS traffics