Merge pull request #228046 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: huypub

articles/active-directory/authentication/concept-certificate-based-authentication.md

@@ -66,7 +66,7 @@ The following scenarios are supported:
 
 The following scenarios aren't supported:
 
-- Certificate Authority hints aren't supported, so the list of certificates that appears for users in the certificate picket UI isn't scoped.
+- Certificate Authority hints aren't supported, so the list of certificates that appears for users in the certificate picker UI isn't scoped.
 - Only one CRL Distribution Point (CDP) for a trusted CA is supported.
 - The CDP can be only HTTP URLs. We don't support Online Certificate Status Protocol (OCSP), or Lightweight Directory Access Protocol (LDAP) URLs.
 - Configuring other certificate-to-user account bindings, such as using the **Subject**, **Subject + Issuer** or **Issuer + Serial Number**, aren’t available in this release.

articles/active-directory/authentication/howto-authentication-methods-activity.md

@@ -112,7 +112,7 @@ The registration details report shows the following information for each user:
 - SSPR Registered (Registered, Not Registered)
 - SSPR Enabled (Enabled, Not Enabled)
 - SSPR Capable (Capable, Not Capable) 
-- Methods registered (Email, Mobile Phone, Alternative Mobile Phone, Office Phone, Microsoft Authenticator Push, Software One Time Passcode, FIDO2, Security Key, Security questions, Hardware OATH token)
+- Methods registered (Alternate Mobile Phone, Email, FIDO2 Security Key, Hardware OATH token, Microsoft Authenticator app, Microsoft Passwordless phone sign-in, Mobile Phone, Office Phone, Security questions, Software OATH token, Temporary Access Pass, Windows Hello for Business)
 
   ![Screenshot of user registration details](media/how-to-authentication-methods-usage-insights/registration-details.png)
 

articles/active-directory/authentication/howto-registration-mfa-sspr-combined.md

@@ -36,6 +36,9 @@ To enable combined registration, complete these steps:
 
    ![Enable the combined security info experience for users](media/howto-registration-mfa-sspr-combined/enable-the-combined-security-info.png)
 
+   > [!IMPORTANT]
+   > If your Azure tenant has already been enabled for combined registration, you might not see the configuration option for **Users can use the combined security information registration experience** or even see it grayed out.
+
 > [!NOTE]
 > After you enable combined registration, users who register or confirm their phone number or mobile app through the new experience can use them for Azure AD Multi-Factor Authentication and SSPR, if those methods are enabled in the Azure AD Multi-Factor Authentication and SSPR policies.
 >

articles/expressroute/expressroute-howto-reset-peering.md

@@ -1,5 +1,5 @@
 ---
-title: 'Azure ExpressRoute: Reset circuit peering'
+title: 'Azure ExpressRoute: Reset circuit peering using Azure PowerShell'
 description: Learn how to enable and disable peerings for an Azure ExpressRoute circuit using Azure PowerShell.
 services: expressroute
 author:  charwen
@@ -10,7 +10,7 @@ ms.date: 12/15/2020
 ms.author: duau
 ---
 
-# Reset ExpressRoute circuit peerings
+# Reset ExpressRoute circuit peerings using Azure PowerShell
 
 This article describes how to enable and disable peerings of an ExpressRoute circuit using PowerShell. Peerings are enabled by default when you create them. When you disable a peering, the BGP session on both the primary and the secondary connection of your ExpressRoute circuit will be shut down. You'll lose connectivity for this peering to Microsoft. When you enable a peering, the BGP session on both the primary and the secondary connection of your ExpressRoute circuit will be established. The connectivity to Microsoft will be restored for this peering. You can enable and disable peering for Microsoft Peering and Azure Private Peering independently on the ExpressRoute circuit.
 

articles/frontdoor/tier-migration.md

@@ -53,7 +53,7 @@ Azure Front Door zero-down time migration happens in three stages. The first sta
 > * Traffic to your Azure Front Door (classic) will continue to be serve until migration has been completed. 
 > * Each Azure Front Door (classic) profile can create one Azure Front Door Standard or Premium profile.
 
-Migration is only available can be completed using the Azure portal. Service charges for Azure Front Door Standard or Premium tier will start once migration is completed.
+Migration is only available and can be completed using the Azure portal. Service charges for Azure Front Door Standard or Premium tier will start once migration is completed.
 
 ## Breaking changes between tiers
 

articles/frontdoor/troubleshoot-issues.md

@@ -17,11 +17,11 @@ This article describes how to troubleshoot common routing problems that you migh
 
 You can request Azure Front Door to return more debugging HTTP response headers. For more information, see [optional response headers](front-door-http-headers-protocol.md#optional-debug-response-headers).
 
-## 503 response from Azure Front Door after a few seconds
+## 503 or 504 response from Azure Front Door after a few seconds
 
 ### Symptom
 
-* Regular requests sent to your backend without going through Azure Front Door are succeeding. Going via Azure Front Door results in 503 error responses.
+* Regular requests sent to your backend without going through Azure Front Door are succeeding. Going via Azure Front Door results in 503 or 504 error responses.
 * The failure from Azure Front Door typically appears after about 30 seconds.
 * Intermittent 503 errors appear with "ErrorInfo: OriginInvalidResponse."