Merge pull request #212041 from MicrosoftDocs/main

9/21 AM Publish

Author: huypub

articles/active-directory/enterprise-users/licensing-service-plan-reference.md

@@ -13,7 +13,7 @@ ms.service: active-directory
 ms.subservice: enterprise-users
 ms.topic: reference
 ms.workload: identity
-ms.date: 09/19/2022
+ms.date: 09/21/2022
 ms.author: nicholak
 ms.reviewer: Nicholak-MS
 ms.custom: "it-pro;seo-update-azuread-jan"
@@ -32,7 +32,7 @@ When managing licenses in [the Azure portal](https://portal.azure.com/#blade/Mic
 - **Service plans included (friendly names)**: A list of service plans (friendly names) in the product that correspond to the string ID and GUID
 
 >[!NOTE]
->This information last updated on September 19th, 2022.<br/>You can also download a CSV version of this table [here](https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv).
+>This information last updated on September 21st, 2022.<br/>You can also download a CSV version of this table [here](https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv).
 ><br/>
 
 | Product name | String ID | GUID | Service plans included | Service plans included (friendly names) |

articles/active-directory/governance/TOC.yml

@@ -245,6 +245,8 @@
     href: workflows-faqs.md  
   - name: Developer API reference Lifecycle Workflows- Azure Active Directory
     href: lifecycle-workflows-developer-reference.md  
+  - name: Set employeeLeaveDateTime for leaver workflows
+    href: set-employee-leave-date-time.md  
   - name: Preparing user accounts for Lifecycle workflows tutorials (Preview)
     href: tutorial-prepare-azure-ad-user-accounts.md 
   - name: Configure a Logic App for Lifecycle Workflow use (Preview)

articles/active-directory/governance/how-to-lifecycle-workflow-sync-attributes.md

@@ -23,10 +23,10 @@ The following table shows the scheduling (trigger) relevant attributes and the m
 |Attribute|Type|Supported in HR Inbound Provisioning|Support in Azure AD Connect Cloud Sync|Support in Azure AD Connect Sync| 
 |-----|-----|-----|-----|-----|
 |employeeHireDate|DateTimeOffset|Yes|Yes|Yes|
-|employeeLeaveDateTime|DateTimeOffset|Not currently(manually setting supported)|Not currently(manually setting supported)|Not currently(manually setting supported)|
+|employeeLeaveDateTime|DateTimeOffset|Yes|Not currently|Not currently|
 
 > [!NOTE]
-> Currently, automatic synchronization of the employeeLeaveDateTime attribute for HR Inbound scenarios is not available. To take advantaged of leaver scenarios, you can set the employeeLeaveDateTime manually. Manually setting the attribute can be done in the portal or with Graph. For more information see [User profile in Azure](../fundamentals/active-directory-users-profile-azure-portal.md) and [Update user](/graph/api/user-update?view=graph-rest-beta&tabs=http).
+> To take advantaged of leaver scenarios, you can set the employeeLeaveDateTime manually for cloud-only users. For more information, see: [Set employeeLeaveDateTime](set-employee-leave-date-time.md)
 
 This document explains how to set up synchronization from on-premises Azure AD Connect cloud sync and Azure AD Connect for the required attributes.
 

articles/active-directory/governance/set-employee-leave-date-time.md

@@ -0,0 +1,70 @@
+---
+title: Set employeeLeaveDateTime
+description: Explains how to manually set employeeLeaveDateTime. 
+author: owinfreyATL
+ms.author: owinfrey
+ms.service: active-directory
+ms.topic: how-to 
+ms.date: 09/07/2022
+ms.custom: template-how-to 
+---
+
+# Set employeeLeaveDateTime
+
+This article describes how to manually set the employeeLeaveDateTime attribute for a user. This attribute can be set as a trigger for leaver workflows created using Lifecycle Workflows.
+
+## Required permission and roles
+
+To set the employeeLeaveDateTime attribute, you must make sure the correct delegated roles and application permissions are set. They are as follows:
+
+### Delegated
+
+In delegated scenarios, the signed-in user needs the Global Administrator role to update the employeeLeaveDateTime attribute. One of the following delegated permissions is also required:
+- User-LifeCycleInfo.ReadWrite.All
+- Directory.AccessAsUser.All
+
+### Application
+
+Updating the employeeLeaveDateTime requires the User-LifeCycleInfo.ReadWrite.All application permission.
+
+>[!NOTE]
+> The User-LifeCycleInfo.ReadWrite.All permissions is currently hidden and cannot be configured in Graph Explorer or the API permission blade of app registrations.
+
+## Set employeeLeaveDateTime via PowerShell
+To set the employeeLeaveDateTime for a user using PowerShell enter the following information:
+
+ ```powershell    
+    Connect-MgGraph -Scopes "User-LifeCycleInfo.ReadWrite.All"
+    Select-MgProfile -Name "beta"
+
+    $UserId = "<Object ID of the user>"
+    $employeeLeaveDateTime = "<Leave date>"
+    
+    $Body = '{"employeeLeaveDateTime": "' + $employeeLeaveDateTime + '"}'
+    Update-MgUser -UserId $UserId -BodyParameter $Body
+
+    $User = Get-MgUser -UserId $UserId -Property employeeLeaveDateTime
+    $User.AdditionalProperties
+ ```
+
+ This script is an example of a user who will leave on September 30, 2022 at 23:59.
+
+ ```powershell
+    Connect-MgGraph -Scopes "User-LifeCycleInfo.ReadWrite.All"
+    Select-MgProfile -Name "beta"
+
+    $UserId = "528492ea-779a-4b59-b9a3-b3773ef6da6d"
+    $employeeLeaveDateTime = "2022-09-30T23:59:59Z"
+    
+    $Body = '{"employeeLeaveDateTime": "' + $employeeLeaveDateTime + '"}'
+    Update-MgUser -UserId $UserId -BodyParameter $Body
+
+    $User = Get-MgUser -UserId $UserId -Property employeeLeaveDateTime
+    $User.AdditionalProperties
+``` 
+
+
+## Next steps
+
+- [How to synchronize attributes for Lifecycle workflows](how-to-lifecycle-workflow-sync-attributes.md)
+- [Lifecycle Workflows templates](lifecycle-workflow-templates.md)

articles/active-directory/hybrid/reference-connect-sync-attributes-synchronized.md

@@ -461,6 +461,7 @@ Device objects are created in Active Directory. These objects can be devices joi
 
 ## Notes
 * When using an Alternate ID, the on-premises attribute userPrincipalName is synchronized with the Azure AD attribute onPremisesUserPrincipalName. The Alternate ID attribute, for example mail, is synchronized with the Azure AD attribute userPrincipalName.
+* Although there is no enforcement of uniqueness on the Azure AD onPremisesUserPrincipalName attribute, it is not supported to sync the same UserPrincipalName value to the Azure AD onPremisesUserPrincipalName attribute for multiple different Azure AD users.
 * In the lists above, the object type **User** also applies to the object type **iNetOrgPerson**.
 
 ## Next steps

articles/azure-app-configuration/howto-best-practices.md

@@ -9,7 +9,7 @@ editor: ''
 ms.assetid: 
 ms.service: azure-app-configuration
 ms.topic: conceptual
-ms.date: 05/02/2019
+ms.date: 09/21/2022
 ms.author: malev
 ms.custom: "devx-track-csharp, mvc"
 ---
@@ -55,7 +55,7 @@ configBuilder.AddAzureAppConfiguration(options => {
 
 ## References to external data
 
-App Configuration is designed to store any configuration data that you would normally save in configuration files or environment variables. However, some types of data may better suited to reside in other sources. For example, store secrets in Key Vault, files in Azure Storage, membership information in Azure AD groups, or customer lists in a database.
+App Configuration is designed to store any configuration data that you would normally save in configuration files or environment variables. However, some types of data may be better suited to reside in other sources. For example, store secrets in Key Vault, files in Azure Storage, membership information in Azure AD groups, or customer lists in a database.
 
 You can still take advantage of App Configuration by saving a reference to external data in a key-value. You can [use content type](./concept-key-value.md#use-content-type) to differentiate each data source. When your application reads a reference, it loads the actual data from the referenced source, assuming it has the necessary permission to the source. If you change the location of your external data, you only need to update the reference in App Configuration instead of updating and redeploying your entire application.
 

articles/azure-arc/data/toc.yml

@@ -284,5 +284,5 @@ items:
       href: preview-testing.md
     - name: Support policy
       href: support-policy.md
-    - name: Automated integration testing
+    - name: Automated validation testing
       href: automated-integration-testing.md

articles/azure-fluid-relay/how-tos/container-recovery.md

@@ -20,11 +20,11 @@ Fluid framework periodically saves state, called summary, without any explicit b
 
 We've added following methods to AzureClient that will enable developers to recover data from corrupted containers. 
 
-[`getContainerVersions(ID, options)`](https://fluidframework.com/docs/apis/azure-client/azureclient#getcontainerversions-Method)
+[`getContainerVersions(ID, options)`](https://fluidframework.com/docs/apis/azure-client/azureclient-class#getcontainerversions-method)
 
 `getContainerVersions` allows developers to view the previously generated versions of the container.
 
-[`copyContainer(ID, containerSchema)`](https://fluidframework.com/docs/apis/azure-client/azureclient#copycontainer-Method)
+[`copyContainer(ID, containerSchema)`](https://fluidframework.com/docs/apis/azure-client/azureclient-class#copycontainer-method)
 
 `copyContainer` allows developers to generate a new detached container from a specific version of another container.
 

articles/azure-fluid-relay/how-tos/test-automation.md

@@ -14,7 +14,7 @@ fluid.url: https://fluidframework.com/docs/testing/testing/
 
 Testing and automation are crucial to maintaining the quality and longevity of your code. Internally, Fluid uses a range of unit and integration tests powered by [Mocha](https://mochajs.org/), [Jest](https://jestjs.io/), [Puppeteer](https://github.com/puppeteer/puppeteer), and [Webpack](https://webpack.js.org/).
 
-You can run tests using the local [@fluidframework/azure-local-service](https://www.npmjs.com/package/@fluidframework/azure-local-service) or using a test tenant in Azure Fluid Relay service. [AzureClient](https://fluidframework.com/docs/apis/azure-client/azureclient) can be configured to connect to both a remote service and a local service, which enables you to use a single client type between tests against live and local service instances. The only difference is the configuration used to create the client.
+You can run tests using the local [@fluidframework/azure-local-service](https://www.npmjs.com/package/@fluidframework/azure-local-service) or using a test tenant in Azure Fluid Relay service. [AzureClient](https://fluidframework.com/docs/apis/azure-client/azureclient-class) can be configured to connect to both a remote service and a local service, which enables you to use a single client type between tests against live and local service instances. The only difference is the configuration used to create the client.
 
 ## Automation against Azure Fluid Relay
 

articles/azure-fluid-relay/how-tos/validate-document-creator.md

@@ -12,11 +12,11 @@ fluid.url: https://fluidframework.com/docs/apis/azure-client/itokenprovider/
 
 # How to: Validate a User Created a Document
 
-When you create a document in Azure Fluid Relay, the JWT provided by the [ITokenProvider](https://fluidframework.com/docs/apis/azure-client/itokenprovider/) for the creation request can only be used once. After creating a document, the client must generate a new JWT that contains the document ID provided by the service at creation time. If an application has an authorization service that manages document access control, it will need to know who created a document with a given ID in order to authorize the generation of a new JWT for access to that document.
+When you create a document in Azure Fluid Relay, the JWT provided by the [ITokenProvider](https://fluidframework.com/docs/apis/azure-client/itokenprovider-interface) for the creation request can only be used once. After creating a document, the client must generate a new JWT that contains the document ID provided by the service at creation time. If an application has an authorization service that manages document access control, it will need to know who created a document with a given ID in order to authorize the generation of a new JWT for access to that document.
 
 ## Inform an Authorization Service when a document is Created
 
-An application can tie into the document creation lifecycle by implementing a public [documentPostCreateCallback()](https://fluidframework.com/docs/apis/azure-client/itokenprovider#documentpostcreatecallback-MethodSignature) method in its `TokenProvider`. This callback will be triggered directly after creating the document, before a client requests the new JWT it needs to gain read/write permissions to the document that was created.
+An application can tie into the document creation lifecycle by implementing a public [documentPostCreateCallback()](https://fluidframework.com/docs/apis/azure-client/itokenprovider-interface#documentpostcreatecallback-methodsignature) method in its `TokenProvider`. This callback will be triggered directly after creating the document, before a client requests the new JWT it needs to gain read/write permissions to the document that was created.
 
 The `documentPostCreateCallback()` receives two parameters: 1) the ID of the document that was created and 2) a JWT signed by the service with no permission scopes. The authorization service can verify the given JWT and use the information in the JWT to grant the correct user permissions for the newly created document.
 
@@ -107,7 +107,7 @@ export default httpTrigger;
 
 ### Implement the `documentPostCreateCallback`
 
-This example implementation below extends the [AzureFunctionTokenProvider](https://fluidframework.com/docs/apis/azure-client/azurefunctiontokenprovider/) and uses the [axios](https://www.npmjs.com/package/axios) library to make a HTTP request to the Azure Function used for generating tokens.
+This example implementation below extends the [AzureFunctionTokenProvider](https://fluidframework.com/docs/apis/azure-client/azurefunctiontokenprovider-class) and uses the [axios](https://www.npmjs.com/package/axios) library to make a HTTP request to the Azure Function used for generating tokens.
 
 ```typescript
 import { AzureFunctionTokenProvider, AzureMember } from "@fluidframework/azure-client";