Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into Sept-11-2022-SmartTier

Author: AbhishekMallick-MS

.openpublishing.redirection.virtual-desktop.json

@@ -19,6 +19,16 @@
             "source_path_from_root": "/articles/virtual-desktop/create-profile-container-adds.md",
             "redirect_url": "/azure/virtual-desktop/fslogix-profile-container-configure-azure-files-active-directory",
             "redirect_document_id": true
+        },
+        {
+            "source_path_from_root": "/articles/virtual-desktop/shortpath.md",
+            "redirect_url": "/azure/virtual-desktop/rdp-shortpath",
+            "redirect_document_id": true
+        },
+        {
+            "source_path_from_root": "/articles/virtual-desktop/shortpath-public.md",
+            "redirect_url": "/azure/virtual-desktop/rdp-shortpath",
+            "redirect_document_id": false
         }
     ]
 }

articles/active-directory/develop/includes/desktop-app/quickstart-windows-desktop.md

@@ -8,14 +8,14 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: include
 ms.workload: identity
-ms.date: 05/19/2022
+ms.date: 09/09/2022
 ms.author: jmprieur
 ms.custom: aaddev, identityplatformtop40, mode-api
 #Customer intent: As an application developer, I want to learn how my Windows Presentation Foundation (WPF) application can get an access token and call an API that's protected by the Microsoft identity platform.
 ---
 
 
-In this quickstart, you download and run a code sample that demonstrates how a Windows Presentation Foundation (WPF) application can sign in users and get an access token to call the Microsoft Graph API. 
+In this quickstart, you download and run a code sample that demonstrates how a Windows Presentation Foundation (WPF) application can sign in users and get an access token to call the Microsoft Graph API. The desktop app you build uses the authorization code flow paired with the Proof Key for Code Exchange (PKCE) standard. 
 
 See [How the sample works](#how-the-sample-works) for an illustration.
 

articles/active-directory/governance/TOC.yml

@@ -89,6 +89,8 @@
       href: lifecycle-workflow-extensibility.md
     - name: Versioning (Preview)
       href: lifecycle-workflow-versioning.md 
+    - name: Workflow Audit logs
+      href: lifecycle-workflow-audits.md
     - name: Workflow History (Preview)
       href: lifecycle-workflow-history.md     
 - name: How-to guides

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

@@ -25,8 +25,6 @@ The following table shows the scheduling (trigger) relevant attributes and the m
 |employeeHireDate|DateTimeOffset|Yes|Yes|Yes|
 |employeeLeaveDateTime|DateTimeOffset|Not currently(manually setting supported)|Not currently(manually setting supported)|Not currently(manually setting supported)|
 
-These attributes **are not** automatically populated using such synchronization methods such as Azure AD Connect or Azure AD Connect cloud sync.
-
 > [!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).
 

articles/active-directory/governance/lifecycle-workflow-audits.md

@@ -0,0 +1,48 @@
+---
+title: Auditing Lifecycle Workflows
+description: Information about audit logs with Lifecycle Workflows
+author: owinfreyATL
+ms.author: owinfrey
+manager: amycolannino
+ms.service: active-directory
+ms.workload: identity
+ms.topic: conceptual 
+ms.date: 08/01/2022
+ms.custom: template-concept 
+---
+
+# Auditing Lifecycle Workflows
+
+Workflows created using Lifecycle Workflows allow for the automation of lifecycle task for users no matter where they fall in the Joiner-Mover-Leaver (JML) model of their identity lifecycle in your organization. Making sure workflows are processed correctly is an important part of an organization's lifecycle management process. Workflows that aren't processed correctly can lead to many issues in terms of security and compliance. With audit logs, every action that Lifecycle Workflows complete over a time-frame up to 30 days are recorded.
+
+## Audit Logs
+
+Every time a workflow is processed, an event is logged. These events are stored in the **Audit Logs** section, and can be used to gain information about workflows for historical, and auditing, purposes. 
+
+:::image type="content" source="media/lifecycle-workflow-audits/audit-logs-concept.png" alt-text="Screenshot of a workflow audit log.":::
+
+On the **Audit Log** page you're presented a sequential list, by date, of every action Lifecycle Workflows has taken. From this information you're able to filter based on the following parameters:
+
+|Filter  |Description  |
+|---------|---------|
+|Date     | You can filter a specific range for the audit logs from as short as 24 hours up to 30 days.        |
+|Date option     | You can filter by your tenant's local time, or by UTC.        |
+|Service     | The Lifecycle Workflow service.        |
+|Category     | Categories of the event being logged. Separated into <br><br>  **All**- All events logged by Lifecycle Workflows.<br><br>  **TaskManagement**- Task specific related events logged by Lifecycle Workflows. <br><br> **WorkflowManagement**- Events dealing with the workflow itself.       |
+|Activity     |  You can filter based on specific activities, which are based on categories.       |
+
+After filtering this information, you're also able to see other information in the log such as:
+
+- **Status**: Whether or not the logged event was successful or not.
+- **Status Reason**: If the event failed, a reason is given why.
+- **Target(s)**: Who the logged event ran for. Information given as their Azure Active Directory object ID.
+- **Initiated by (actor)**: Who did the event being logged. Information given by the user name. 
+
+
+
+## Next steps
+
+- [Lifecycle Workflow History](lifecycle-workflow-history.md)
+- [Check the status of a workflow (Preview)](check-status-workflow.md)
+
+

articles/active-directory/governance/lifecycle-workflow-history.md

@@ -16,37 +16,11 @@ ms.custom: template-concept
 
 
 
-Workflows created using Lifecycle Workflows allow for the automation of lifecycle task for users no matter where they fall in the Joiner-Mover-Leaver (JML) model of their identity lifecycle in your organization. Making sure workflows are processed correctly is an important part of an organization's lifecycle management process. Workflows that aren't processed correctly can lead to many issues in terms of security and compliance. With Audit logs every action that Lifecycle Workflows complete are recorded. With history features, Lifecycle Workflows allow you to specify workflow events based on user, runs, or task summaries. This reporting feature allows you to quickly see what ran for who, and rather or not it was successful. In this article you'll learn the difference between auditing logs and 3 different type of history summaries you can query with Lifecycle Workflows. You'll also learn when you would use each when getting more information about how your workflows were utilized for users in your organization.
-
-
-
-## Audit Logs
-
-Every time a workflow is processed, an event is logged. These events are stored in the **Audit Logs** section, and can be used to gain information about workflows for historical, and auditing, purposes. 
-
-:::image type="content" source="media/lifecycle-workflow-history/audit-logs-concept.png" alt-text="Screenshot of a workflow audit log.":::
-
-On the **Audit Log** page you're presented a sequential list, by date, of every action Lifecycle Workflows has taken. From this information you're able to filter based on the following parameters:
-
-
-|Filter  |Description  |
-|---------|---------|
-|Date     | You can filter a specific range for the audit logs from as short as 24 hours up to 30 days.        |
-|Date option     | You can filter by your tenant's local time, or by UTC.        |
-|Service     | The Lifecycle Workflow service.        |
-|Category     | Categories of the event being logged. Separated into <br><br>  **All**- All events logged by Lifecycle Workflows.<br><br>  **TaskManagement**- Task specific related events logged by Lifecycle Workflows. <br><br> **WorkflowManagement**- Events dealing with the workflow itself.       |
-|Activity     |  You can filter based on specific activities, which are based on categories.       |
-
-After filtering this information, you're also able to see other information in the log such as:
-
-- **Status**: Whether or not the logged event was successful or not.
-- **Status Reason**: If the event failed, a reason is given why.
-- **Target(s)**: Who the logged event ran for. Information given as their Azure Active Directory object ID.
-- **Initiated by (actor)**: Who did the event being logged. Information given by the user name. 
+Workflows created using Lifecycle Workflows allow for the automation of lifecycle task for users no matter where they fall in the Joiner-Mover-Leaver (JML) model of their identity lifecycle in your organization. Making sure workflows are processed correctly is an important part of an organization's lifecycle management process. Workflows that aren't processed correctly can lead to many issues in terms of security and compliance. With Lifecycle Workflow's history features, you can specify which workflow events you want to view a history of based on user, runs, or task summaries. This reporting feature allows you to quickly see what ran for who, and rather or not it was successful. Along with the summaries in these specific areas, you're also able to view detailed information about each specific event recorded in their respective summary section. In this article you'll learn the difference between the three different type of history summaries, and details, you can query with Lifecycle Workflows. You'll also learn when you would use each when getting more information about how your workflows were utilized for users in your organization. For detailed information about every action Lifecycle Workflows take, see: [Auditing Lifecycle Workflows](lifecycle-workflow-audits.md).
 
 ## Lifecycle Workflow History Summaries
 
-While the large set of information contained in audit logs can be useful for compliance reasons, for regular administration use it might be too much information. To make this large set of information processed easier to read, Lifecycle Workflows provide summaries for quick use. You can view these history summaries in three ways:
+Lifecycle Workflows introduce a history feature based on summaries and details. These history summaries allow you to quickly get information about for who a workflow ran, and whether or not this run was successful or not. This is valuable because the large set of information given by audit logs might become too numerous to be efficiently used. To make a large set of information processed easier to read, Lifecycle Workflows provide summaries for quick use. You can view these history summaries in three ways:
 
 - **Users summary**: Shows a summary of users processed by a workflow, and which tasks failed, successfully, and totally ran for each specific user. 
 - **Runs summary**: Shows a summary of workflow runs in terms of the workflow. Successful, failed, and total task information when workflow runs are noted.
@@ -61,7 +35,7 @@ User summaries allow you to view workflow information through the lens of users
 :::image type="content" source="media/lifecycle-workflow-history/users-summary-concept.png" alt-text="Screenshot of a workflow user summary.":::
 
 
-Within the user summary you're able to find the following information:
+Within the user summary, you're able to find the following information:
 
 
 |Parameter  |Description  |
@@ -72,8 +46,9 @@ Within the user summary you're able to find the following information:
 |Total tasks     | The total number of tasks processed for users in a workflow during the selected time frame.        |
 |Failed tasks     |  The total number of failed tasks processed for users in a workflow during the selected time frame.       |
 
+### User history details
 
-User summaries allow you to filter based on:
+User detailed history information allows you to filter for specific information based on:
 
 - **Date**: You can filter a specific range from as short as 24 hours up to 30 days of when workflow ran.
 - **Status**: You can filter a specific status of the user processed. The supported statuses are: **Completed**, **In Progress**, **Queued**, **Canceled**, **Completed with errors**, and **Failed**. 
@@ -89,7 +64,7 @@ Runs summaries allow you to view workflow information through the lens of its ru
 
 :::image type="content" source="media/lifecycle-workflow-history/runs-status-concept.png" alt-text="Screenshot of a workflow runs summary.":::
 
-Within the runs summary you're able to find the following information:
+Within the runs summary, you're able to find the following information:
 
 
 |Parameter  |Description  |
@@ -99,7 +74,9 @@ Within the runs summary you're able to find the following information:
 |Failed     | Workflows that failed to run.        |
 |Failed tasks     | Workflows that ran with failed tasks.        |
 
-Runs summaries allow you to filter based on:
+### Runs history details
+
+Runs detailed history information allows you to filter for specific information based on:
 
 - **Date**: You can filter a specific range from as short as 24 hours up to 30 days of when workflow ran.
 - **Status**: You can filter a specific status of the workflow run. The supported statuses are: **Completed**, **In Progress**, **Queued**, **Canceled**, **Completed with errors**, and **Failed**. 
@@ -115,7 +92,7 @@ Task summaries allow you to view workflow information through the lens of its ta
 
 :::image type="content" source="media/lifecycle-workflow-history/task-summary-concept.png" alt-text="Screenshot of a workflow task summary.":::
 
-Within the tasks summary you're able to find the following information:
+Within the tasks summary, you're able to find the following information:
 
 
 |Parameter  |Description  |
@@ -125,7 +102,10 @@ Within the tasks summary you're able to find the following information:
 |Failed     | The number of failed processed tasks by a workflow.         |
 |Unprocessed     | The number of unprocessed tasks by a workflow.        |
 
-Task summaries allow you to filter based on:
+
+### Task history details
+
+Task detailed history information allows you to filter for specific information based on:
 
 - **Date**: You can filter a specific range from as short as 24 hours up to 30 days of when workflow ran.
 - **Status**: You can filter a specific status of the workflow run. The supported statuses are: **Completed**, **In Progress**, **Queued**, **Canceled**, **Completed with errors**, and **Failed**. 

articles/active-directory/governance/media/lifecycle-workflow-history/audit-logs-concept.png renamed to articles/active-directory/governance/media/lifecycle-workflow-audits/audit-logs-concept.png

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: saas-app-tutorial
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 06/09/2021
+ms.date: 09/12/2022
 ms.author: jeedes
 ---
 # Tutorial: Azure Active Directory integration with ClearCompany
@@ -70,11 +70,14 @@ Follow these steps to enable Azure AD SSO in the Azure portal.
 
    ![Edit Basic SAML Configuration](common/edit-urls.png)
 
-4. On the **Basic SAML Configuration** section, If you wish to configure the application in **IDP** initiated mode, perform the following step:
+4. On the **Basic SAML Configuration** section, If you wish to configure the application in **IDP** initiated mode, perform the following steps:
 
-    In the **Identifier** text box, type the URL:
+    a. In the **Identifier** text box, type the URL:
     `https://api.clearcompany.com`
 
+    b. In the **Reply URL** text box, type the URL:
+    `https://api.clearcompany.com/v1/auth/sso/saml`
+
 5. Click **Set additional URLs** and perform the following step if you wish to configure the application in **SP** initiated mode:
 
     In the **Sign-on URL** text box, type a URL using the following pattern:
@@ -129,15 +132,15 @@ In this section, you test your Azure AD single sign-on configuration with follow
 
 #### SP initiated:
 
-* Click on **Test this application** in Azure portal. This will redirect to ClearCompany Sign on URL where you can initiate the login flow.  
+* Click on **Test this application** in Azure portal. This will redirect to ClearCompany Sign-on URL where you can initiate the login flow.  
 
-* Go to ClearCompany Sign-on URL directly and initiate the login flow from there.
+* Go to ClearCompany Sign on URL directly and initiate the login flow from there.
 
 #### IDP initiated:
 
 * Click on **Test this application** in Azure portal and you should be automatically signed in to the ClearCompany for which you set up the SSO. 
 
-You can also use Microsoft My Apps to test the application in any mode. When you click the ClearCompany tile in the My Apps, if configured in SP mode you would be redirected to the application sign on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the ClearCompany for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).
+You can also use Microsoft My Apps to test the application in any mode. When you click the ClearCompany tile in the My Apps, if configured in SP mode you would be redirected to the application sign-on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the ClearCompany for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).
 
 ## Next steps