Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into us1679050dq

Author: TimShererWithAquent

.openpublishing.redirection.json

@@ -4055,6 +4055,11 @@
       "redirect_url": "/azure/azure-government/documentation-government-welcome",
       "redirect_document_id": false
     },
+    {
+      "source_path": "articles/azure-government/documentation-government-k8.md",
+      "redirect_url": "/azure/azure-government",
+      "redirect_document_id": false
+    },
     {
       "source_path": "articles/azure-portal/resource-group-portal-linked-resources.md",
       "redirect_url": "/azure/azure-portal/azure-portal-dashboards",
@@ -7586,7 +7591,7 @@
     },
     {
       "source_path": "articles/azure-functions/functions-add-output-binding-storage-queue-python.md",
-      "redirect_url": "/azure/azure-functions/functions-add-output-binding-storage-queue-cli.md?pivots=programming-language-python",
+      "redirect_url": "/azure/azure-functions/functions-add-output-binding-storage-queue-cli?pivots=programming-language-python",
       "redirect_document_id": false
     },
     {
@@ -19189,6 +19194,11 @@
       "redirect_url": "/azure/backup/backup-overview",
       "redirect_document_id": false
     },
+    {
+      "source_path": "articles/backup/tutorial-backup-azure-files.md",
+      "redirect_url": "/azure/backup/backup-afs",
+      "redirect_document_id": false
+    },
     {
       "source_path": "articles/backup/backup-azure-backup-ibiza-faq.md",
       "redirect_url": "/azure/backup/backup-azure-backup-faq",

articles/active-directory-b2c/secure-rest-api.md

@@ -268,7 +268,7 @@ To support bearer token authentication in your custom policy, modify the REST AP
 1. Ensure you add the claim used above as an input claim:
 
     ```xml
-    <InputClaim ClaimTyeReferenceId="bearerToken"/>
+    <InputClaim ClaimTypeReferenceId="bearerToken"/>
     ```    
 
 After you add the above snippets, your technical profile should look like the following XML code:
@@ -288,7 +288,7 @@ After you add the above snippets, your technical profile should look like the fo
         <Item Key="AllowInsecureAuthInProduction">false</Item>
       </Metadata>
       <InputClaims>
-        <InputClaim ClaimTyeReferenceId="bearerToken"/>
+        <InputClaim ClaimTypeReferenceId="bearerToken"/>
       </InputClaims>
       ...
     </TechnicalProfile>

articles/active-directory-domain-services/troubleshoot-account-lockout.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: troubleshooting
-ms.date: 10/02/2019
+ms.date: 04/06/2020
 ms.author: iainfou
 
 #Customer intent: As a directory administrator, I want to troubleshoot why user accounts are locked out in an Azure Active Directory Domain Services managed domain.
@@ -31,11 +31,11 @@ The default account lockout thresholds are configured using fine-grained passwor
 
 ### Fine-grained password policy
 
-Fine-grained password policies (FGPPs) let you apply specific restrictions for password and account lockout policies to different users in a domain. FGPP only affects users created in Azure AD DS. Cloud users and domain users synchronized into the Azure AD DS managed domain from Azure AD aren't affected by the password policies.
+Fine-grained password policies (FGPPs) let you apply specific restrictions for password and account lockout policies to different users in a domain. FGPP only affects users within an Azure AD DS managed domain. Cloud users and domain users synchronized into the Azure AD DS managed domain from Azure AD are only affected by the password policies within Azure AD DS. Their accounts in Azure AD or an on-premises directory aren't impacted.
 
 Policies are distributed through group association in the Azure AD DS managed domain, and any changes you make are applied at the next user sign-in. Changing the policy doesn't unlock a user account that's already locked out.
 
-For more information on fine-grained password policies, see [Configure password and account lockout policies][configure-fgpp].
+For more information on fine-grained password policies, and the differences between users created directly in Azure AD DS versus synchronized in from Azure AD, see [Configure password and account lockout policies][configure-fgpp].
 
 ## Common account lockout reasons
 

articles/active-directory-domain-services/tutorial-configure-password-hash-sync.md

@@ -66,7 +66,7 @@ With Azure AD Connect installed and configured to synchronize with Azure AD, now
 
     In this example screenshot, the following connectors are used:
 
-    * The Azure AD connector is named *aaddscontoso.onmicrosoft.com - AAD*
+    * The Azure AD connector is named *contoso.onmicrosoft.com - AAD*
     * The on-premises AD DS connector is named *onprem.contoso.com*
 
 1. Copy and paste the following PowerShell script to the computer with Azure AD Connect installed. The script triggers a full password sync that includes legacy password hashes. Update the `$azureadConnector` and `$adConnector` variables with the connector names from the previous step.

articles/active-directory/authentication/concept-authentication-passwordless.md

@@ -159,7 +159,7 @@ Use the following table to choose which method will support your requirements an
 
 ## Next steps
 
-[Enable FIDO2 security key passwordlesss options in your organization](howto-authentication-passwordless-security-key.md)
+[Enable FIDO2 security key passwordless options in your organization](howto-authentication-passwordless-security-key.md)
 
 [Enable phone-based passwordless options in your organization](howto-authentication-passwordless-phone.md)
 

articles/active-directory/authentication/howto-sspr-deployment.md

@@ -340,7 +340,7 @@ Audit logs for registration and password reset are available for 30 days. If sec
 
 ## Next steps
 
-* To get started deploying SSPR, see [Enable Azure AD self-service password reset](https://docs.microsoft.com/azure/active-directory/authentication/tutorial-enable-sspr.md)
+* To get started deploying SSPR, see [Enable Azure AD self-service password reset](tutorial-enable-sspr.md)
 
 * [Consider implementing Azure AD password protection](https://docs.microsoft.com/azure/active-directory/authentication/concept-password-ban-bad)
 

articles/active-directory/authentication/howto-sspr-windows.md

@@ -40,7 +40,7 @@ For machines running Windows 7, 8, 8.1, and 10 you can enable users to reset the
 - The combination of the following specific three settings can cause this feature to not work.
     - Interactive logon: Do not require CTRL+ALT+DEL = Disabled
     - DisableLockScreenAppNotifications = 1 or Enabled
-    - IsContentDeliveryPolicyEnforced = 1 or True
+    - Windows SKU isn't Home or Professional edition
 
 ## Windows 10 password reset
 

articles/active-directory/conditional-access/concept-conditional-access-users-groups.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 04/02/2020
+ms.date: 04/06/2020
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -32,9 +32,9 @@ The following options are available to include when creating a Conditional Acces
 - All users
    - All users that exist in the directory including B2B guests.
 - Select users and groups
-   - All guest and external users (preview)
+   - All guest and external users
       - This selection includes any B2B guests and external users including any user with the `user type` attribute set to `guest`. This selection also applies to any external user signed-in from a different organization like a Cloud Solution Provider (CSP). 
-   - Directory roles (preview)
+   - Directory roles
       - Allows administrators to select specific Azure AD directory roles used to determine assignment. For example, organizations may create a more restrictive policy on users assigned the global administrator role.
    - Users and groups
       - Allows targeting of specific sets of users. For example, organizations can select a group that contains all members of the HR department when an HR app is selected as the cloud app. A group can be any type of group in Azure AD, including dynamic or assigned security and distribution groups.
@@ -48,9 +48,9 @@ When organizations both include and exclude a user or group the user or group is
 
 The following options are available to exclude when creating a Conditional Access policy.
 
-- All guest and external users (preview)
+- All guest and external users
    - This selection includes any B2B guests and external users including any user with the `user type` attribute set to `guest`. This selection also applies to any external user signed-in from a different organization like a Cloud Solution Provider (CSP). 
-- Directory roles (preview)
+- Directory roles
    - Allows administrators to select specific Azure AD directory roles used to determine assignment. For example, organizations may create a more restrictive policy on users assigned the global administrator role.
 - Users and groups
    - Allows targeting of specific sets of users. For example, organizations can select a group that contains all members of the HR department when an HR app is selected as the cloud app. A group can be any type of group in Azure AD, including dynamic or assigned security and distribution groups.

articles/active-directory/conditional-access/howto-conditional-access-policy-admin-mfa.md

@@ -39,7 +39,7 @@ Conditional Access policies are powerful tools, we recommend excluding the follo
 
 * **Emergency access** or **break-glass** accounts to prevent tenant-wide account lockout. In the unlikely scenario all administrators are locked out of your tenant, your emergency-access administrative account can be used to log into the tenant take steps to recover access.
    * More information can be found in the article, [Manage emergency access accounts in Azure AD](../users-groups-roles/directory-emergency-access.md).
-* **Service accounts** and **service principals**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Service accounts like these should be excluded since MFA can't be completed programmatically.
+* **Service accounts** and **service principals**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Service accounts like these should be excluded since MFA can't be completed programmatically. Calls made by service principals are not blocked by Conditional Access.
    * If your organization has these accounts in use in scripts or code, consider replacing them with [managed identities](../managed-identities-azure-resources/overview.md). As a temporary workaround, you can exclude these specific accounts from the baseline policy.
 
 ## Create a Conditional Access policy

articles/active-directory/conditional-access/howto-conditional-access-policy-all-users-mfa.md

@@ -29,7 +29,7 @@ Conditional Access policies are powerful tools, we recommend excluding the follo
 
 * **Emergency access** or **break-glass** accounts to prevent tenant-wide account lockout. In the unlikely scenario all administrators are locked out of your tenant, your emergency-access administrative account can be used to log into the tenant take steps to recover access.
    * More information can be found in the article, [Manage emergency access accounts in Azure AD](../users-groups-roles/directory-emergency-access.md).
-* **Service accounts** and **service principals**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Service accounts like these should be excluded since MFA can't be completed programmatically.
+* **Service accounts** and **service principals**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Service accounts like these should be excluded since MFA can't be completed programmatically. Calls made by service principals are not blocked by Conditional Access.
    * If your organization has these accounts in use in scripts or code, consider replacing them with [managed identities](../managed-identities-azure-resources/overview.md). As a temporary workaround, you can exclude these specific accounts from the baseline policy.
 
 ## Application exclusions