Merge branch 'MicrosoftDocs:main' into patch-1

Author: kcpitt

.openpublishing.redirection.azure-monitor.json

@@ -211,6 +211,11 @@
             "redirect_url": "/troubleshoot/azure/azure-monitor/app-insights/troubleshoot-portal-connectivity",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/azure-monitor/app/javascript-sdk-load-failure.md",
+            "redirect_url": "https://learn.microsoft.com/troubleshoot/azure/azure-monitor/app-insights/javascript-sdk-troubleshooting",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/azure-monitor/app/java-2x-troubleshoot.md",
             "redirect_url": "/troubleshoot/azure/azure-monitor/app-insights/java-2x-troubleshoot",

.openpublishing.redirection.json

@@ -59,7 +59,7 @@ In the legacy experience, apps were always created as customer-facing applicatio
 > [!NOTE]
 > This option is required to be able to run Azure AD B2C user flows to authenticate users for this application. Learn [how to register an application for use with user flows.](tutorial-register-applications.md)
 
-You can also use this option  to use Azure AD B2C as a SAML service provider. [Learn more](identity-provider-adfs.md).
+You can also use this option  to use Azure AD B2C as a SAML service provider. [Learn more](saml-service-provider.md).
 
 ## Applications for DevOps scenarios
 

articles/active-directory-b2c/app-registrations-training-guide.md

@@ -75,16 +75,16 @@ A job can go into quarantine regardless of failure counts for issues such as adm
 
 The logic documented here may be different for certain connectors to ensure best customer experience, but we generally have the below retry cycles after a failure:
 
-After the first failure, the first retry happens within the next 2 hours (usually in the next sync cycle).
-- The second retry happens 6 hours after the first failure.
-- The third retry happens 12 hours after the first failure.
-- The fourth retry happens 24 hours after the first failure.
-- The fifth retry happens 48 hours after the first failure.
-- The sixth retry happens 72 hours after the first failure.
-- The seventh retry happens 96 hours after the first failure.
-- The eighth retry happens 120 hours after the first failure.
-
-This cycle is repeated every 24 hours until the 30th day when retries are stopped and the job is disabled. 
+After the failure, the first retry will happen in 6 hours.
+- The second retry happens 12 hours after the first failure.
+- The third retry happens 24 hours after the first failure.
+- The fourth retry happens 48 hours after the first failure.
+- The fifth retry happens 96 hours after the first failure.
+- The sixth retry happens 192 hours after the first failure.
+- The seventh retry happens 384 hours after the first failure.
+- The eighth retry happens 768 hours after the first failure.
+
+The retries are stopped after the 8th retry and the escrow entry is removed. The job will continue unless it hits the escrow thresholds from the section above 
 
 
 ## How do I get my application out of quarantine?

articles/active-directory/app-provisioning/application-provisioning-quarantine-status.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 02/22/2023
+ms.date: 02/23/2023
 ms.author: kenwith
 ms.reviewer: arvinh
 ---
@@ -218,7 +218,7 @@ Use the general guidelines when implementing a SCIM endpoint to ensure compatibi
 ### /Schemas (Schema discovery):
 
 * [Sample request/response](#schema-discovery)
-* Schema discovery isn't currently supported on the custom non-gallery SCIM application, but it's being used on certain gallery applications. Going forward, schema discovery will be used as the sole method to add more attributes to the schema of an existing gallery SCIM application. 
+* Schema discovery is being used on certain gallery applications. Schema discovery is the sole method to add more attributes to the schema of an existing gallery SCIM application. Schema discovery isn't currently supported on custom non-gallery SCIM application.
 * If a value isn't present, don't send null values.
 * Property values should be camel cased (for example, readWrite).
 * Must return a list response.
@@ -1373,8 +1373,8 @@ The SCIM spec doesn't define a SCIM-specific scheme for authentication and autho
 |--|--|--|--|
 |Username and password (not recommended or supported by Azure AD)|Easy to implement|Insecure - [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/your-pa-word-doesn-t-matter/ba-p/731984)|Not supported for new gallery or non-gallery apps.|
 |Long-lived bearer token|Long-lived tokens don't require a user to be present. They're easy for admins to use when setting up provisioning.|Long-lived tokens can be hard to share with an admin without using insecure methods such as email. |Supported for gallery and non-gallery apps. |
-|OAuth authorization code grant|Access tokens are much shorter-lived than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have.  A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid, and authorization will need to be completed again.|Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth code grant on non-gallery is in our backlog, in addition to support for configurable auth / token URLs on the gallery app.|
-|OAuth client credentials grant|Access tokens are much shorter-lived than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Both the authorization code grant and the client credentials grant create the same type of access token, so moving between these methods is transparent to the API.  Provisioning can be automated, and new tokens can be silently requested without user interaction. ||Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth client credentials grant on non-gallery is in our backlog.|
+|OAuth authorization code grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have.  A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid, and authorization will need to be completed again.|Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth code grant on non-gallery is in our backlog, in addition to support for configurable auth / token URLs on the gallery app.|
+|OAuth client credentials grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Both the authorization code grant and the client credentials grant create the same type of access token, so moving between these methods is transparent to the API.  Provisioning can be automated, and new tokens can be silently requested without user interaction. ||Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth client credentials grant on non-gallery is in our backlog.|
 
 > [!NOTE]
 > It's not recommended to leave the token field blank in the Azure AD provisioning configuration custom app UI. The token generated is primarily available for testing purposes.

articles/active-directory/app-provisioning/use-scim-to-provision-users-and-groups.md

@@ -31,7 +31,7 @@ Microsoft verified partners can help you onboard Microsoft Entra Permissions Man
 * **Onboarding and Deployment Support**
 
     Partners can guide you through the entire onboarding and deployment process for 
-    ermissions Management across AWS, Azure, and GCP.
+    Permissions Management across AWS, Azure, and GCP.
 
 
 ## Partner list

articles/active-directory/cloud-infrastructure-entitlement-management/partner-list.md

@@ -37,9 +37,6 @@ There are multiple scenarios that organizations can now enable using filter for
 
 Filter for devices is an option when creating a Conditional Access policy in the Azure portal or using the Microsoft Graph API.
 
-> [!IMPORTANT]
-> Device state and filter for devices cannot be used together in Conditional Access policy.
-
 The following steps will help create two Conditional Access policies to support the first scenario under [Common scenarios](#common-scenarios). 
 
 Policy 1: All users with the directory role of Global Administrator, accessing the Microsoft Azure Management cloud app, and for Access controls, Grant access, but require multifactor authentication and require device to be marked as compliant.

articles/active-directory/conditional-access/concept-condition-filters-for-devices.md

@@ -94,7 +94,6 @@ To apply this grant control, the device must be registered in Azure AD, which re
 The following client apps support this setting, this list isn't exhaustive and is subject to change::
 
 - Microsoft Azure Information Protection
-- Microsoft Bookings
 - Microsoft Cortana
 - Microsoft Dynamics 365
 - Microsoft Edge
@@ -114,7 +113,6 @@ The following client apps support this setting, this list isn't exhaustive and i
 - Microsoft PowerPoint
 - Microsoft SharePoint
 - Microsoft Skype for Business
-- Microsoft StaffHub
 - Microsoft Stream
 - Microsoft Teams
 - Microsoft To-Do
@@ -194,7 +192,7 @@ When user risk is detected, administrators can employ the user risk policy condi
 When a user is prompted to change a password, they'll first be required to complete multifactor authentication. Make sure all users have registered for multifactor authentication, so they're prepared in case risk is detected for their account.  
 
 > [!WARNING]
-> Users must have previously registered for self-service password reset before triggering the user risk policy.
+> Users must have previously registered for multifactor authentication before triggering the user risk policy.
 
 The following restrictions apply when you configure a policy by using the password change control:  
 

articles/active-directory/conditional-access/concept-conditional-access-grant.md

@@ -83,10 +83,6 @@ The software the user is employing to access the cloud app. For example, 'Browse
 
 The behavior of the client apps condition was updated in August 2020. If you have existing Conditional Access policies, they'll remain unchanged. However, if you select on an existing policy, the configure toggle has been removed and the client apps the policy applies to are selected.
 
-#### Device state
-
-This control is used to exclude devices that are hybrid Azure AD joined, or marked a compliant in Intune. This exclusion can be done to block unmanaged devices. 
-
 #### Filter for devices
 
 This control allows targeting specific devices based on their attributes in a policy.

articles/active-directory/conditional-access/concept-conditional-access-policies.md

@@ -206,7 +206,7 @@ Networks and network services used by clients connecting to identity and resourc
 
 ### Supported location policies
 
-CAE only has insight into [IP-based named locations](../conditional-access/location-condition.md#ip-address-ranges). CAE doesn't have insight into other location conditions like [MFA trusted IPs](../authentication/howto-mfa-mfasettings.md#trusted-ips) or country-based locations. When a user comes from an MFA trusted IP, trusted location that includes MFA Trusted IPs, or country location, CAE won't be enforced after that user moves to a different location. In those cases, Azure AD will issue a one-hour access token without instant IP enforcement check. 
+CAE only has insight into [IP-based named locations](../conditional-access/location-condition.md#ipv4-and-ipv6-address-ranges). CAE doesn't have insight into other location conditions like [MFA trusted IPs](../authentication/howto-mfa-mfasettings.md#trusted-ips) or country-based locations. When a user comes from an MFA trusted IP, trusted location that includes MFA Trusted IPs, or country location, CAE won't be enforced after that user moves to a different location. In those cases, Azure AD will issue a one-hour access token without instant IP enforcement check. 
 
 > [!IMPORTANT]
 > If you want your location policies to be enforced in real time by continuous access evaluation, use only the [IP based Conditional Access location condition](../conditional-access/location-condition.md) and configure all IP addresses, **including both IPv4 and IPv6**, that can be seen by your identity provider and resources provider. Do not use country location conditions or the trusted ips feature that is available in Azure AD Multi-Factor Authentication's service settings page.