updates

MicrosoftDocs · Sep 14, 2023 · 0bbb5e0 · 0bbb5e0
1 parent 9a0769b
commit 0bbb5e0
Show file tree

Hide file tree

Showing 31 changed files with 82 additions and 75 deletions.
diff --git a/docs/id-governance/access-reviews-application-preparation.md b/docs/id-governance/access-reviews-application-preparation.md
@@ -62,14 +62,16 @@ In order to permit a wide variety of applications and IT requirements to be addr
 The integration patterns listed above are applicable to third party SaaS applications, or applications that have been developed by or for your organization.
 
 * Some Microsoft Online Services, such as Exchange Online, use licenses.  While user's licenses can't be reviewed directly, if you're using group-based license assignments, with groups with assigned users, you can review the memberships of those groups instead.
-* Some applications may use delegated user consent to control access to Microsoft Graph or other resources.  As consents by each user aren't controlled by an approval process, consents aren't reviewable in Azure AD. Instead, you can review who is able to connect to the application through Conditional Access policies, that could be based on application role assignments or group memberships.
+* Some applications may use delegated user consent to control access to Microsoft Graph or other resources.  As consents by each user aren't controlled by an approval process, consents aren't reviewable in. Instead, you can review who is able to connect to the application through Conditional Access policies, that could be based on application role assignments or group memberships.
 * If the application doesn't support federation or provisioning protocols, then you'll need a process for manually applying the results when a review completes. For an application that only supports password SSO integration, if an application assignment is removed when a review completes, then the application won't show up on the *myapps* page for the user, but it won't prevent a user who already knows the password from being able to continue to sign into the application. For your on-premises applications, see [govern the users of an application that does not support provisioning](identity-governance-applications-not-provisioned-users.md). For SaaS applications, please [ask the SaaS vendor to onboard to the app gallery](../manage-apps/v2-howto-app-gallery-listing.md) for federation or provisioning by updating their application to support a standard protocol.
 
 ## Check the application is ready for the review
 
-Now that you have identified the integration pattern for the application, check the application as represented in Azure AD is ready for review.
+Now that you have identified the integration pattern for the application, check the application as represented in Microsoft Entra ID is ready for review.
 
-1. In the Azure portal, click **Azure Active Directory**, click **Enterprise Applications**, and check whether your application is on the [list of enterprise applications](../manage-apps/view-applications-portal.md) in your Azure AD tenant.
+1. Sign in to the [Microsoft Entra admin Center](https://entra.microsoft.com) as at least a [Identity Governance Administrator](../roles/permissions-reference.md#identity-governance-administrator).
+1. Browse to > **Identity** > **Applications** > **Enterprise Applications**. 
+1. Here you can check to see whether your application is on the [list of enterprise applications](../manage-apps/view-applications-portal.md) in your tenant.
 1. If the application is not already listed, then check if the application is available the [application gallery](../manage-apps/overview-application-gallery.md) for applications that can be integrated for federated SSO or provisioning. If it is in the gallery, then use the [tutorials](../saas-apps/tutorial-list.md) to configure the application for federation, and if it supports provisioning, also [configure the application](../app-provisioning/configure-automatic-user-provisioning-portal.md) for provisioning.  
 1. If the application is not already listed, but uses AD security groups and is a web application, [add the application for remote access through Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md) and [configure group writeback to AD](../hybrid/connect/how-to-connect-group-writeback-v2.md).
 1. If the application is not already listed, uses AD security groups and is not a web application, then [configure group writeback to AD](../hybrid/connect/how-to-connect-group-writeback-v2.md) and continue at the next section.
@@ -104,7 +106,9 @@ Now that you have identified the integration pattern for the application, check
 
 Next, if the application integration also requires one or more groups to be reviewed, as described in pattern B, then check each group is ready for review.
 
-1. In the Azure portal experience for Azure AD, click **Groups**, and then search for and select each group from the list.
+1. Sign in to the [Microsoft Entra admin Center](https://entra.microsoft.com) as at least a [Identity Governance Administrator](../roles/permissions-reference.md#identity-governance-administrator).
+1. Browse to > **Groups**. 
+1. Search for and select each group from the list.
 1. On the **Overview** tab, verify that the **Membership type** is **Assigned**, and the **Source** is **Cloud**.  If the application uses a dynamic group, or a group synchronized from on-premises, then those group memberships can't be changed in Azure AD.  We recommend converting the application to groups created in Azure AD with assigned memberships, then copy the member users to that new group.
 1. Change to the **Roles and administrators** tab. This tab displays the administrative roles, that give rights to control the representation of the group in Azure AD, not the access rights in the application.  For each administrative role that allows changing group membership and has users in that administrative role, ensure that only authorized users are in that role.
 1. Change to the **Members** tab.  Verify that the members of the group are users, and that there are no non-user members or nested groups. If there are no members of a group when the review starts, the review of that group will complete immediately.

diff --git a/docs/id-governance/access-reviews-overview.md b/docs/id-governance/access-reviews-overview.md
@@ -57,8 +57,8 @@ Depending on what you want to review, you'll either create your access review in
 | --- | --- | --- | --- |
 | Security group members</br>Office group members | Specified reviewers</br>Group owners</br>Self-review | access reviews</br>Azure AD groups | Access panel |
 | Assigned to a connected app | Specified reviewers</br>Self-review | access reviews</br>Azure AD enterprise apps (in preview) | Access panel |
-| Azure AD role | Specified reviewers</br>Self-review | [PIM](../privileged-identity-management/pim-create-roles-and-resource-roles-review.md?toc=/azure/active-directory/governance/toc.json) | Azure portal |
-| Azure resource role | Specified reviewers</br>Self-review | [PIM](../privileged-identity-management/pim-create-roles-and-resource-roles-review.md?toc=/azure/active-directory/governance/toc.json) | Azure portal |
+| Azure AD role | Specified reviewers</br>Self-review | [PIM](../privileged-identity-management/pim-create-roles-and-resource-roles-review.md?toc=/azure/active-directory/governance/toc.json) | Microsoft Entra Admin Center |
+| Azure resource role | Specified reviewers</br>Self-review | [PIM](../privileged-identity-management/pim-create-roles-and-resource-roles-review.md?toc=/azure/active-directory/governance/toc.json) | Microsoft Entra Admin Center |
 | Access package assignments | Specified reviewers</br>Group members</br>Self-review | entitlement management | Access panel |
 
 ## License requirements

diff --git a/docs/id-governance/check-status-workflow.md b/docs/id-governance/check-status-workflow.md
@@ -18,11 +18,11 @@ ms.custom: template-how-to
 When a workflow is created, it's important to check its status, and run history to make sure it ran properly for the users it processed both by schedule and by on-demand. To get information about the status of workflows, Lifecycle Workflows allows you to check run and user processing history. This history also gives you summaries to see how often a workflow has run, and who it ran successfully for. You're also able to check the status of both the workflow, and its tasks. Checking the status of workflows and their tasks allows you to troubleshoot potential problems that could come up during their execution.
 
 
-## Run workflow history using the Azure portal
+## Run workflow history using the Microsoft Entra admin center
 
 [!INCLUDE [portal updates](~/articles/active-directory/includes/portal-update.md)]
 
-You're able to retrieve run information of a workflow using Lifecycle Workflows. To check the runs of a workflow using the Azure portal, you would do the following steps:
+You're able to retrieve run information of a workflow using Lifecycle Workflows. To check the runs of a workflow using the Microsoft Entra Admin center, you would do the following steps:
 
 1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Lifecycle Workflows Administrator](../roles/permissions-reference.md#lifecycle-workflows-administrator).
 
@@ -38,10 +38,9 @@ You're able to retrieve run information of a workflow using Lifecycle Workflows.
     :::image type="content" source="media/check-status-workflow/run-list.png" alt-text="Screenshot of a workflow Runs list.":::
 1. The runs summary cards include the total number of processed runs, the number of successful runs, the number of failed runs, and the total number of failed tasks.   
 
-## User workflow history using the Azure portal
-
-To get further information than just the runs summary for a workflow, you're also able to get information about users processed by a workflow. To check the status of users a workflow has processed using the Azure portal, you would do the following steps:
+## User workflow history using the Microsoft Entra admin center
 
+To get further information than just the runs summary for a workflow, you're also able to get information about users processed by a workflow. To check the status of users a workflow has processed using the Microsoft Entra admin center, you would do the following steps:
 
 1. In the left menu, select **Lifecycle Workflows**.
 

diff --git a/docs/id-governance/check-workflow-execution-scope.md b/docs/id-governance/check-workflow-execution-scope.md
@@ -19,7 +19,7 @@ ms.collection: M365-identity-device-management
 
 Workflow scheduling will automatically process the workflow for users meeting the workflows execution conditions. This article walks you through the steps to check the users who fall into the execution scope of a workflow. For more information about execution conditions, see: [workflow basics](../governance/understanding-lifecycle-workflows.md#workflow-basics).
 
-## Check execution user scope of a workflow using the Azure portal
+## Check execution user scope of a workflow using the Microsoft Entra admin center
 
 [!INCLUDE [portal updates](~/articles/active-directory/includes/portal-update.md)]
 

diff --git a/docs/id-governance/configure-logic-app-lifecycle-workflows.md b/docs/id-governance/configure-logic-app-lifecycle-workflows.md
@@ -221,7 +221,7 @@ To configure those you follow these steps:
 ## Configure authorization policy for custom task extension with POP security token type
 If the security token type is **Proof of Possession (POP)** for your custom task extension, you'd set the authorization policy by following these steps:
 
-1. For Logic Apps authorization policy, we need the managed identities **Application ID**. Since the Azure portal only shows the Object ID, we need to look up the Application ID. You can search for the managed identity by Object ID under **Enterprise Applications in the Azure AD Portal** to find the required Application ID.
+1. For Logic Apps authorization policy, we need the managed identities **Application ID**. Since the Microsoft Entra admin center only shows the Object ID, we need to look up the Application ID. You can search for the managed identity by Object ID under **Enterprise Applications in the Azure AD Portal** to find the required Application ID.
 
 1. Go back to the logic app you created, and select **Authorization**.
 
@@ -252,7 +252,7 @@ If the security token type is **Proof of Possession (POP)** for your custom task
 
 If the security token type is **Normal** for your custom task extension, you'd set the authorization policy by following these steps:
 
-1. For Logic Apps authorization policy, we need the managed identities **Application ID**. Since the Azure portal only shows the Object ID, we need to look up the Application ID. You can search for the managed identity by Object ID under **Enterprise Applications in the Azure AD Portal** to find the required Application ID.
+1. For Logic Apps authorization policy, we need the managed identities **Application ID**. Since the Microsoft Entra admin center only shows the Object ID, we need to look up the Application ID. You can search for the managed identity by Object ID under **Enterprise Applications in the Azure AD Portal** to find the required Application ID.
 
 1. Go back to the logic app you created, and select **Authorization**.
 

diff --git a/docs/id-governance/customize-workflow-email.md b/docs/id-governance/customize-workflow-email.md
@@ -32,11 +32,11 @@ For more information on these customizable parameters, see [Common email task pa
 
 [!INCLUDE [Microsoft Entra ID Governance license](../../../includes/active-directory-entra-governance-license.md)]
 
-## Customize email by using the Azure portal
+## Customize email by using the Microsoft Entra admin center
 
 [!INCLUDE [portal updates](~/articles/active-directory/includes/portal-update.md)]
 
-When you're customizing an email sent via lifecycle workflows, you can choose to customize either a new task or an existing task. You do these customizations the same way whether the task is new or existing, but the following steps walk you through updating an existing task. To customize emails sent from tasks within workflows by using the Azure portal:
+When you're customizing an email sent via lifecycle workflows, you can choose to customize either a new task or an existing task. You do these customizations the same way whether the task is new or existing, but the following steps walk you through updating an existing task. To customize emails sent from tasks within workflows by using the Microsoft Entra admin center:
 
 1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Lifecycle Workflows Administrator](../roles/permissions-reference.md#lifecycle-workflows-administrator).
 

diff --git a/docs/id-governance/customize-workflow-schedule.md b/docs/id-governance/customize-workflow-schedule.md
@@ -18,7 +18,7 @@ ms.collection: M365-identity-device-management
 
 When you create workflows by using lifecycle workflows, you can fully customize them to match the schedule that fits your organization's needs. By default, workflows are scheduled to run every 3 hours. But you can set the interval to be as frequent as 1 hour or as infrequent as 24 hours.
 
-## Customize the schedule of workflows by using the Azure portal
+## Customize the schedule of workflows by using the Microsoft Entra admin center
 
 [!INCLUDE [portal updates](~/articles/active-directory/includes/portal-update.md)]
 

diff --git a/docs/id-governance/delete-lifecycle-workflow.md b/docs/id-governance/delete-lifecycle-workflow.md
@@ -25,7 +25,7 @@ When a workflow is deleted, it enters a soft-delete state. During this period, y
 [!INCLUDE [Microsoft Entra ID Governance license](../../../includes/active-directory-entra-governance-license.md)]
 
 
-## Delete a workflow by using the Azure portal
+## Delete a workflow by using the Microsoft Entra admin center
 
 [!INCLUDE [portal updates](~/articles/active-directory/includes/portal-update.md)]
 
@@ -41,7 +41,7 @@ When a workflow is deleted, it enters a soft-delete state. During this period, y
 
     :::image type="content" source="media/delete-lifecycle-workflow/delete-workflow.png" alt-text="Screenshot of confirming the deletion of a workflow.":::
 
-## View deleted workflows in the Azure portal
+## View deleted workflows in the Microsoft Entra admin center
 
 After you delete workflows, you can view them on the **Deleted workflows** page.
 

diff --git a/docs/id-governance/deploy-access-reviews.md b/docs/id-governance/deploy-access-reviews.md
@@ -277,7 +277,7 @@ Group owners review membership because they're best qualified to know who needs
 
    For example, Microsoft Teams uses Microsoft 365 Groups as the underlying authorization model to grant users access to resources that are in SharePoint, Exchange, OneNote, or other Microsoft 365 services. The creator of the team automatically becomes an owner and should be responsible for attesting to the membership of that group.
 
-* Groups created manually in the Azure portal or via scripting through Microsoft Graph might not necessarily have owners defined. Define them either through the Azure portal in the group's **Owners** section or via Microsoft Graph.
+* Groups created manually in the Microsoft Entra admin center or via scripting through Microsoft Graph might not necessarily have owners defined. Define them either through the Microsoft Entra admin center in the group's **Owners** section or via Microsoft Graph.
 
 * Groups that are synchronized from on-premises Active Directory can't have an owner in Azure AD. When you create an access review for them, select individuals who are best suited to decide on membership in them.
 

diff --git a/docs/id-governance/entitlement-management-access-package-manage-lifecycle.md b/docs/id-governance/entitlement-management-access-package-manage-lifecycle.md
@@ -34,7 +34,7 @@ Entitlement management allows you to gain visibility into the state of a guest u
 
 You can directly convert ungoverned users to be governed by using the **Mark Guests as Governed (preview)** functionality in the top menu bar.
 
-## Manage guest user lifecycle in the Azure portal
+## Manage guest user lifecycle in the Microsoft Entra admin center
 
 [!INCLUDE [portal updates](~/articles/active-directory/includes/portal-update.md)]
 

diff --git a/docs/id-governance/entitlement-management-logic-apps-integration.md b/docs/id-governance/entitlement-management-logic-apps-integration.md
@@ -155,7 +155,7 @@ For newly created Logic Apps linked to custom extensions, these Logic Apps begin
 
 1. Select the Logic App under the Logic app column for the associated custom extension row. This allows you to edit or create the workflow in Logic App designer.  
 
-For more information on creating logic app workflows, see [Quickstart: Create an example Consumption workflow in multi-tenant Azure Logic Apps with the Azure portal](../../logic-apps/quickstart-create-example-consumption-workflow.md).
+For more information on creating logic app workflows, see [Quickstart: Create an example Consumption workflow in multi-tenant Azure Logic Apps](../../logic-apps/quickstart-create-example-consumption-workflow.md).
 
 
 ## Configuring custom extensions that pause entitlement management processes

diff --git a/docs/id-governance/entitlement-management-logs-and-reporting.md b/docs/id-governance/entitlement-management-logs-and-reporting.md
@@ -163,7 +163,7 @@ $subs | ft
 
 You can reauthenticate and associate your PowerShell session to that subscription using a command such as `Connect-AzAccount –Subscription $subs[0].id`. To learn more about how to authenticate to Azure from PowerShell, including non-interactively, see [Sign in with Azure PowerShell](/powershell/azure/authenticate-azureps).
 
-If you have multiple Log Analytics workspaces in that subscription, then the cmdlet [Get-AzOperationalInsightsWorkspace](/powershell/module/Az.OperationalInsights/Get-AzOperationalInsightsWorkspace) returns the list of workspaces. Then you can find the one that has the Azure AD logs. The `CustomerId` field returned by this cmdlet is the same as the value of the "Workspace ID" displayed in the Azure portal in the Log Analytics workspace overview.
+If you have multiple Log Analytics workspaces in that subscription, then the cmdlet [Get-AzOperationalInsightsWorkspace](/powershell/module/Az.OperationalInsights/Get-AzOperationalInsightsWorkspace) returns the list of workspaces. Then you can find the one that has the Azure AD logs. The `CustomerId` field returned by this cmdlet is the same as the value of the "Workspace ID" displayed in the Microsoft Entra admin center in the Log Analytics workspace overview.
 
 ```powershell
 $wks = Get-AzOperationalInsightsWorkspace