Merge pull request #233294 from MicrosoftDocs/main

Publish to live, Tuesday 4 AM PST, 4/4

Author: ttorble

.openpublishing.redirection.active-directory.json

@@ -134,6 +134,11 @@
       "source_path_from_root": "/articles/active-directory/saas-apps/headerf5-tutorial.md",
       "redirect_url": "/azure/active-directory/saas-apps/f5-big-ip-headers-easy-button",
       "redirect_document_id": false
+    },
+	{
+      "source_path_from_root": "/articles/active-directory/saas-apps/tripactions-tutorial.md",
+      "redirect_url": "/azure/active-directory/saas-apps/navan-tutorial",
+      "redirect_document_id": false
     },
     {
       "source_path_from_root": "/articles/active-directory/saas-apps/oracle-peoplesoft-protected-by-f5-big-ip-apm-tutorial.md",
@@ -170,6 +175,11 @@
       "redirect_url": "/azure/active-directory/develop/workload-identity-federation-create-trust",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/active-directory/workload-identities/workload-identity-federation-create-trust-gcp.md",
+      "redirect_url": "/azure/active-directory/workload-identities/workload-identity-federation",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/active-directory/develop/workload-identities-overview.md",
       "redirect_url": "/azure/active-directory/workload-identities/workload-identities-overview",

.openpublishing.redirection.healthcare-apis.json

@@ -594,7 +594,11 @@
           "redirect_document_id": false
       },
       {   "source_path_from_root": "/articles/healthcare-apis/iot/how-to-use-device-mappings.md",
-          "redirect_url": "/azure/healthcare-apis/iot/how-to-configure-device-mappings",
+          "redirect_url": "/azure/healthcare-apis/iot/overview-of-device-mapping",
+          "redirect_document_id": false
+      },
+      {   "source_path_from_root": "/articles/healthcare-apis/iot/how-to-configure-device-mappings.md",
+          "redirect_url": "/azure/healthcare-apis/iot/overview-of-device-mapping",
           "redirect_document_id": false
       },
       {   "source_path_from_root": "/articles/healthcare-apis/iot/how-to-use-fhir-mappings.md",

articles/active-directory-b2c/billing.md

@@ -61,7 +61,7 @@ Your Azure AD B2C tenant must also be linked to the appropriate Azure pricing ti
 
 ## About Go-Local add-on 
 
-Azure AD B2C's [Go-Local add-on](data-residency.md#go-local-add-on) enables you to create Azure AD B2C tenant within the country you choose when you [create your Azure AD B2C](tutorial-create-tenant.md). *Go-Local* refers to Microsoft’s commitment to allow some customers to configure some services to store their data at rest in the Geo of the customer’s choice, typically a country. This feature isn't available in all countries. 
+Azure AD B2C's [Go-Local add-on](data-residency.md#go-local-add-on) enables you to create Azure AD B2C tenant within the country/region you choose when you [create your Azure AD B2C](tutorial-create-tenant.md). *Go-Local* refers to Microsoft’s commitment to allow some customers to configure some services to store their data at rest in the Geo of the customer’s choice, typically a country/region. This feature isn't available in all countries/regions. 
 
 > [!NOTE]
 > If you enable  Go-Local add-on , the 50,000 free MAUs per month given by your AD B2C subscription doesn't apply for  Go-Local add-on . You'll incur a charge per MAU, on the Go-Local add-on from the first MAU. However, you'll continue to enjoy free 50,000 MAUs per month on the other features available on your Azure AD B2C [Premium P1 or P2 pricing](https://azure.microsoft.com/pricing/details/active-directory-b2c/). 

articles/active-directory-b2c/custom-policy-developer-notes.md

@@ -177,7 +177,7 @@ The following table summarizes the Security Assertion Markup Language (SAML) app
 
 | Feature | Status | Notes |
 | ------- | :--: | ----- |
-| [Go-Local add-on](data-residency.md#go-local-add-on) | Preview | Azure AD B2C's [Go-Local add-on](data-residency.md#go-local-add-on) enables you to create Azure AD B2C tenant within the country you choose when you [create your Azure AD B2C](tutorial-create-tenant.md).  |
+| [Go-Local add-on](data-residency.md#go-local-add-on) | Preview | Azure AD B2C's [Go-Local add-on](data-residency.md#go-local-add-on) enables you to create Azure AD B2C tenant within the country/region you choose when you [create your Azure AD B2C](tutorial-create-tenant.md).  |
 
 ## Responsibilities of custom policy feature-set developers
 

articles/active-directory-b2c/data-residency.md

@@ -26,7 +26,7 @@ Azure AD B2C is **generally available worldwide** with the option for **data res
 
 [Region availability](#region-availability) refers to where a service is available for use. [Data residency](#data-residency) refers to where customer data is stored. For customers in the EU and EFTA, see [EU Data Boundary](#eu-data-boundary).
 
-If you enable [Go-Local add-on](#go-local-add-on), you can store your data exclusively in a specific country.
+If you enable [Go-Local add-on](#go-local-add-on), you can store your data exclusively in a specific country/region.
 
 
 ## Region availability
@@ -61,16 +61,16 @@ The following locations are in the process of being added to the list. For now,
 
 > Argentina, Brazil, Chile, Colombia, Ecuador, Iraq, Paraguay, Peru, Uruguay, and Venezuela
 
-To find the exact location where your data is located per region or country, refer to [where Azure Active Directory data is located](https://aka.ms/aaddatamap)service.   
+To find the exact location where your data is located per country/country, refer to [where Azure Active Directory data is located](https://aka.ms/aaddatamap)service.   
 
 
 ### Go-Local add-on
 
-*Go-Local* refers to Microsoft’s commitment to allow some customers to configure some services to store their data at rest in the Geo of the customer’s choice, typically a country. Go-Local is as way fulfilling corporate policies and compliance requirements. You choose the country where you want to store your data when you [create your Azure AD B2C](tutorial-create-tenant.md).  
+*Go-Local* refers to Microsoft’s commitment to allow some customers to configure some services to store their data at rest in the Geo of the customer’s choice, typically a country/region. Go-Local is as way fulfilling corporate policies and compliance requirements. You choose the country/region where you want to store your data when you [create your Azure AD B2C](tutorial-create-tenant.md).  
 
 The Go-Local add-on is a paid add-on, but it's optional. If you choose to use it, you'll incur an extra charge in addition to your Azure AD B2C Premium P1 or P2 licenses. See more information in [Billing model](billing.md). 
 
-At the moment, the following countries have the local data residence option:
+At the moment, the following countries/regions have the local data residence option:
 
 - Japan 
 

articles/active-directory-b2c/faq.yml

@@ -164,7 +164,7 @@ sections:
           If the TOTP authenticator app codes aren't working with your Android or iPhone mobile phone or device, your device's clock time might be incorrect. In your device's settings, select the option to use the network-provided time or to set the time automatically.
           
       - question: |
-          How do I know that the Go-Local add-on available in my country? 
+          How do I know that the Go-Local add-on available in my country/region? 
         answer: |
           While [creating your Azure AD B2C tenant](tutorial-create-tenant.md), if the Go-Local add-on is available in your country, you're asked to enable it if you need it. 
       

articles/active-directory-b2c/tutorial-create-tenant.md

@@ -77,7 +77,7 @@ Before you create your Azure AD B2C tenant, you need to take the following consi
 
    - For **Organization name**, enter a name for your Azure AD B2C tenant.
    - For **Initial domain name**, enter a domain name for your Azure AD B2C tenant.
-   - For **Location**, select your country from the list. If the country you select has a [Go-Local add-on](data-residency.md#go-local-add-on) option, such as Japan or Australia, and you want to store your data exclusively within that country, select the **Store Azure AD Core Store data, components and service data in the location selected above** checkbox. Go-Local add-on is a paid add-on whose charge is added to your Azure AD B2C Premium P1 or P2 licenses charges, see [Billing model](billing.md#about-go-local-add-on). You can't change the data residency region after you create your Azure AD B2C tenant. 
+   - For **Location**, select your country/region from the list. If the country/region you select has a [Go-Local add-on](data-residency.md#go-local-add-on) option, such as Japan or Australia, and you want to store your data exclusively within that country/region, select the **Store Azure AD Core Store data, components and service data in the location selected above** checkbox. Go-Local add-on is a paid add-on whose charge is added to your Azure AD B2C Premium P1 or P2 licenses charges, see [Billing model](billing.md#about-go-local-add-on). You can't change the data residency region after you create your Azure AD B2C tenant. 
    - For **Subscription**, select your subscription from the list.
    - For **Resource group**, select or search for the resource group that will contain the tenant.
 

articles/active-directory/app-provisioning/plan-cloud-hr-provision.md

@@ -207,7 +207,7 @@ The cloud HR app to Active Directory user provisioning solution requires that yo
 To prepare the on-premises environment, the Azure AD Connect provisioning agent configuration wizard registers the agent with your Azure AD tenant, [opens ports](../app-proxy/application-proxy-add-on-premises-application.md#open-ports), [allows access to URLs](../app-proxy/application-proxy-add-on-premises-application.md#allow-access-to-urls), and supports [outbound HTTPS proxy configuration](../saas-apps/workday-inbound-tutorial.md#how-do-i-configure-the-provisioning-agent-to-use-a-proxy-server-for-outbound-http-communication).
 
 The provisioning agent configures a [Global Managed Service Account (GMSA)](../cloud-sync/how-to-prerequisites.md#group-managed-service-accounts)
-to communicate with the Active Directory domains. If you want to use a non-GMSA service account for provisioning, you can [skip GMSA configuration](../cloud-sync/how-to-manage-registry-options.md#skip-gmsa-configuration) and specify your service account during configuration. 
+to communicate with the Active Directory domains.
 
 You can select domain controllers that should handle provisioning requests. If you have several geographically distributed domain controllers, install the provisioning agent in the same site as your preferred domain controllers. This positioning improves the reliability and performance of the end-to-end solution.
 
@@ -249,7 +249,7 @@ This topology supports business requirements where attribute mapping and provisi
 
 Use this topology to manage multiple independent child AD domains belonging to the same forest, if managers always exist in the same domain as the user and your unique ID generation rules for attributes like *userPrincipalName*, *samAccountName* and *mail* does not require a forest-wide lookup. It also offers the flexibility of delegating the administration of each provisioning job by domain boundary. 
 
-For example: In the diagram below, the provisioning apps are setup for each geographic region: North America (NA), Europe, Middle East and Africa (EMEA) and Asia Pacific (APAC). Depending on the location, users are provisioned to the respective AD domain. Delegated administration of the provisioning app is possible so that *EMEA administrators* can independently manage the provisioning configuration of users belonging to the EMEA region.  
+For example: In the diagram below, the provisioning apps are set up for each geographic region: North America (NA), Europe, Middle East and Africa (EMEA) and Asia Pacific (APAC). Depending on the location, users are provisioned to the respective AD domain. Delegated administration of the provisioning app is possible so that *EMEA administrators* can independently manage the provisioning configuration of users belonging to the EMEA region.  
 
 :::image type="content" source="media/plan-cloud-hr-provision/topology-3-separate-apps-with-multiple-ad-domains-no-cross-domain.png" alt-text="Screenshot of separate apps to provision users from Cloud HR to multiple AD domains" lightbox="media/plan-cloud-hr-provision/topology-3-separate-apps-with-multiple-ad-domains-no-cross-domain.png":::
 
@@ -266,7 +266,7 @@ For example: In the diagram below, the provisioning apps are setup for each geog
 
 Use this topology to manage multiple independent child AD domains belonging to the same forest, if a user's manager may exist in the different domain and your unique ID generation rules for attributes like *userPrincipalName*, *samAccountName* and *mail* requires a forest-wide lookup. 
 
-For example: In the diagram below, the provisioning apps are setup for each geographic region: North America (NA), Europe, Middle East and Africa (EMEA) and Asia Pacific (APAC). Depending on the location, users are provisioned to the respective AD domain. Cross-domain manager references and forest-wide lookup is handled by enabling referral chasing on the provisioning agent. 
+For example: In the diagram below, the provisioning apps are set up for each geographic region: North America (NA), Europe, Middle East and Africa (EMEA) and Asia Pacific (APAC). Depending on the location, users are provisioned to the respective AD domain. Cross-domain manager references and forest-wide lookup are handled by enabling referral chasing on the provisioning agent. 
 
 :::image type="content" source="media/plan-cloud-hr-provision/topology-4-separate-apps-with-multiple-ad-domains-cross-domain.png" alt-text="Screenshot of separate apps to provision users from Cloud HR to multiple AD domains with cross domain support" lightbox="media/plan-cloud-hr-provision/topology-4-separate-apps-with-multiple-ad-domains-cross-domain.png":::
 
@@ -285,7 +285,7 @@ For example: In the diagram below, the provisioning apps are setup for each geog
 
 Use this topology if you want to use a single provisioning app to manage users belonging to all your parent and child AD domains. This topology is recommended if provisioning rules are consistent across all domains and there is no requirement for delegated administration of provisioning jobs. This topology supports resolving cross-domain manager references and can perform forest-wide uniqueness check. 
 
-For example: In the diagram below, a single provisioning app manages users present in three different child domains grouped by region: North America (NA), Europe, Middle East and Africa (EMEA) and Asia Pacific (APAC). The attribute mapping for *parentDistinguishedName* is used to dynamically create a user in the appropriate child domain. Cross-domain manager references and forest-wide lookup is handled by enabling referral chasing on the provisioning agent. 
+For example: In the diagram below, a single provisioning app manages users present in three different child domains grouped by region: North America (NA), Europe, Middle East and Africa (EMEA) and Asia Pacific (APAC). The attribute mapping for *parentDistinguishedName* is used to dynamically create a user in the appropriate child domain. Cross-domain manager references and forest-wide lookup are handled by enabling referral chasing on the provisioning agent. 
 
 :::image type="content" source="media/plan-cloud-hr-provision/topology-5-single-app-with-multiple-ad-domains-cross-domain.png" alt-text="Screenshot of single app to provision users from Cloud HR to multiple AD domains with cross domain support" lightbox="media/plan-cloud-hr-provision/topology-5-single-app-with-multiple-ad-domains-cross-domain.png":::
 

articles/active-directory/cloud-sync/how-to-manage-registry-options.md

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.topic: how-to
 ms.tgt_pltfrm: na
 ms.workload: identity
-ms.date: 01/11/2023
+ms.date: 04/03/2023
 ms.subservice: hybrid
 ms.reviewer: chmutali
 ms.author: billmath
@@ -62,29 +62,6 @@ Use the following steps to turn on referral chasing:
 1. Restart the Azure AD Connect Provisioning Service from the *Services* console.
 1. If you have deployed multiple provisioning agents, apply this registry change to all agents for consistency.
 
-## Skip GMSA configuration
-With agent version 1.1.281.0+, by default, when you run the agent configuration wizard, you are prompted to setup [Group Managed Service Account (GMSA)](/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview). The GMSA setup by the wizard is used at runtime for all sync and provisioning operations. 
-
-If you are upgrading from a prior version of the agent and have setup a custom service account with delegated OU-level permissions specific to your Active Directory topology, you may want to skip/postpone GMSA configuration and plan for this change. 
-
-> [!NOTE]
-> This guidance specifically applies to customers who have configured HR (Workday/SuccessFactors) inbound provisioning with agent versions prior to 1.1.281.0 and have setup a custom service account for agent operations. In the long run, we recommend switching to GMSA as a best practice.  
-
-In this scenario, you can still upgrade the agent binaries and skip the GMSA configuration using the following steps: 
-
-1. Log on as Administrator on the Windows server running the Azure AD Connect Provisioning Agent.
-1. Run the agent installer to install the new agent binaries. Close the agent configuration wizard which opens up automatically after the installation is successful. 
-1. Use the *Run* menu item to open the registry editor (regedit.exe) 
-1. Locate the key folder **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure AD Connect Agents\Azure AD Connect Provisioning Agent**
-1. Right-click and select "New -> DWORD Value"
-1. Provide the name: 
-  `UseCredentials`
-1. Double-click on the **Value Name** and enter the value data as `1`.  
-    > [!div class="mx-imgBorder"]
-    > ![Use Credentials](media/how-to-manage-registry-options/use-credentials.png)
-1. Restart the Azure AD Connect Provisioning Service from the *Services* console.
-1. If you have deployed multiple provisioning agents, apply this registry change to all agents for consistency.
-1. From the desktop short cut, run the agent configuration wizard. The wizard will skip the GMSA configuration. 
 
 
 > [!NOTE]

articles/active-directory/conditional-access/howto-conditional-access-policy-authentication-strength-external.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: how-to
-ms.date: 10/12/2022
+ms.date: 04/03/2023
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -65,7 +65,7 @@ Use the following steps to create a Conditional Access policy that applies an au
 
    <!---![Screenshot showing where to select guest and external user types.](media/howto-conditional-access-policy-authentication-strength-external/assignments-external-user-types.png)--->
 
-1. Select the types of [guest or external users](../external-identities/authentication-conditional-access.md#assigning-conditional-access-policies-to-external-user-types-preview) you want to apply the policy to.
+1. Select the types of [guest or external users](../external-identities/authentication-conditional-access.md#assigning-conditional-access-policies-to-external-user-types) you want to apply the policy to.
 
 1. Under **Exclude**, select **Users and groups** and choose your organization's emergency access or break-glass accounts.
 1. Under **Cloud apps or actions**, under **Include** or **Exclude**, select any applications you want to include in or exclude from the authentication strength requirements.