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

davidsmatlak · davidsmatlak · commit f5a835f0050c · 2020-02-14T10:48:33.000-08:00
diff --git a/articles/active-directory/hybrid/how-to-connect-sso.md b/articles/active-directory/hybrid/how-to-connect-sso.md
@@ -30,7 +30,7 @@ Seamless SSO can be combined with either the [Password Hash Synchronization](how
 ![Seamless Single Sign-On](./media/how-to-connect-sso/sso1.png)
 
 >[!IMPORTANT]
->Seamless SSO needs the user's device to be **domain-joined**, but doesn't need for the device to be [Azure AD Joined](../active-directory-azureadjoin-overview.md).
+>Seamless SSO needs the user's device to be **domain-joined** only, but it is not used on [Azure AD Joined](../active-directory-azureadjoin-overview.md) or [Hybrid Azure AD joined] (../active-directory-azureadjoin-overview.md) devices. SSO pn Azure AD joined and Hybrid Azure AD joined works based on the [Primary refresh token] (../active-directory/devices/concept-primary-refresh-token.md)
 
 ## Key benefits
 
diff --git a/articles/active-directory/saas-apps/alibaba-cloud-service-role-based-sso-tutorial.md b/articles/active-directory/saas-apps/alibaba-cloud-service-role-based-sso-tutorial.md
@@ -164,7 +164,7 @@ the **Note** field, click **Upload** to upload the federation metadata file you
 7. Associate the Alibaba Cloud RAM role (AADrole) with the Azure AD user (u2):
 To associate the RAM role with the Azure AD user, you must create a role in Azure AD by following these steps:
 
-	a. Sign on to the [Azure AD Graph Explorer](https://developer.microsoft.com/graph/graph-explorer?spm=a2c63.p38356.879954.9.7d904e167h6Yg9).
+	a. Sign on to the [Microsoft Graph Explorer](https://developer.microsoft.com/graph/graph-explorer).
 
 	b. Click **modify permissions** to obtain required permissions for creating a role.
 
diff --git a/articles/active-directory/saas-apps/aws-multi-accounts-tutorial.md b/articles/active-directory/saas-apps/aws-multi-accounts-tutorial.md
@@ -38,7 +38,7 @@ If you want to know more details about SaaS app integration with Azure AD, see [
 
 **Please note that we do not recommend to use this approach for following reasons:**
 
-* You have to use the Graph Explorer approach to patch all the roles to the app. We don’t recommend using the manifest file approach.
+* You have to use the Microsoft Graph Explorer approach to patch all the roles to the app. We don’t recommend using the manifest file approach.
 
 * We have seen customers reporting that after adding ~1200 app roles for a single AWS app, any operation on the app started throwing the errors related to size. There is a hard limit of size on the application object.
 
@@ -243,7 +243,7 @@ In this section, you enable Azure AD single sign-on in the Azure portal and conf
 
 16. Perform the above step for all the roles in all the accounts and store all of them in format **Role ARN,Trusted entities** in a notepad.
 
-17. Open [Azure AD Graph Explorer](https://developer.microsoft.com/graph/graph-explorer) in another window.
+17. Open [Microsoft Graph Explorer](https://developer.microsoft.com/graph/graph-explorer) in another window.
 
 	a. Sign in to the Graph Explorer site using the Global Admin/Co-admin credentials for your tenant.
 
@@ -322,9 +322,9 @@ In this section, you enable Azure AD single sign-on in the Azure portal and conf
 	> [!Note]
 	> You can only add new roles after the **msiam_access** for the patch operation. Also, you can add as many roles as you want per your Organization need. Azure AD will send the **value** of these roles as the claim value in SAML response.
 
-	j. Go back to your Graph Explorer and change the method from **GET** to **PATCH**. Patch the Service Principal object to have desired roles by updating appRoles property similar to the one shown above in the example. Click **Run Query** to execute the patch operation. A success message confirms the creation of the role for your Amazon Web Services application.
+	j. Go back to Microsoft Graph Explorer and change the method from **GET** to **PATCH**. Patch the Service Principal object to have desired roles by updating appRoles property similar to the one shown above in the example. Click **Run Query** to execute the patch operation. A success message confirms the creation of the role for your Amazon Web Services application.
 
-	![Graph explorer dialog box](./media/aws-multi-accounts-tutorial/graph-explorer-new11.png)
+	![Microsoft Graph explorer dialog box](./media/aws-multi-accounts-tutorial/graph-explorer-new11.png)
 
 18. After the Service Principal is patched with more roles, you can assign Users/Groups to the respective roles. This can be done by going to portal and navigating to the Amazon Web Services application. Click on the **Users and Groups** tab on the top.
 
@@ -360,7 +360,7 @@ For more information about the Access Panel, see [Introduction to the Access
 
 ## Additional resources
 
-* [How to configure provisioning using MS Graph APIs](https://docs.microsoft.com/azure/active-directory/manage-apps/application-provisioning-configure-api)
+* [How to configure provisioning using Microsoft Graph APIs](https://docs.microsoft.com/azure/active-directory/manage-apps/application-provisioning-configure-api)
 * [List of Tutorials on How to Integrate SaaS Apps with Azure Active Directory](tutorial-list.md)
 * [What is application access and single sign-on with Azure Active Directory?](../manage-apps/what-is-single-sign-on.md)
 
diff --git a/articles/active-directory/saas-apps/sharepoint-on-premises-tutorial.md b/articles/active-directory/saas-apps/sharepoint-on-premises-tutorial.md
@@ -329,7 +329,7 @@ Users can now sign into SharePoint 2016 using identities from Azure AD, but ther
 
 There is no validation on the values you search for, which can lead to misspellings or users accidentally choosing the wrong claim type to assign such as the **SurName** claim. This can prevent users from successfully accessing resources.
 
-To assist with this scenario, there is an open-source solution called [AzureCP](https://yvand.github.io/AzureCP/) that provides a custom claims provider for SharePoint 2016. It will use the Azure AD Graph to resolve what users enter and perform validation. Learn more at [AzureCP](https://yvand.github.io/AzureCP/).
+To assist with this scenario, there is an open-source solution called [AzureCP](https://yvand.github.io/AzureCP/) that provides a custom claims provider for SharePoint 2016. It will use the Microsoft Graph API to resolve what users enter and perform validation. Learn more at [AzureCP](https://yvand.github.io/AzureCP/).
 
 ### Assign the Azure AD Security Group in the Azure portal
 
diff --git a/articles/active-directory/saas-apps/workday-inbound-tutorial.md b/articles/active-directory/saas-apps/workday-inbound-tutorial.md
@@ -816,7 +816,7 @@ No, the solution does not maintain a cache of user profiles. The Azure AD provis
 
 #### Does the solution support assigning on-premises AD groups to the user?
 
-This functionality is not supported currently. Recommended workaround is to deploy a PowerShell script that queries the Azure AD Graph API endpoint for audit log data and use that to trigger scenarios such as group assignment. This PowerShell script can be attached to a task scheduler and deployed on the same box running the provisioning agent.  
+This functionality is not supported currently. Recommended workaround is to deploy a PowerShell script that queries the Microsoft Graph API endpoint for [audit log data](https://docs.microsoft.com/graph/api/resources/azure-ad-auditlog-overview?view=graph-rest-beta) and use that to trigger scenarios such as group assignment. This PowerShell script can be attached to a task scheduler and deployed on the same box running the provisioning agent.  
 
 #### Which Workday APIs does the solution use to query and update Workday worker profiles?
 
diff --git a/articles/storage/files/storage-files-how-to-create-large-file-share.md b/articles/storage/files/storage-files-how-to-create-large-file-share.md
@@ -39,7 +39,7 @@ Enabling large file shares on an account is an irreversible process. After you e
     ![Screenshot showing how to create a resource group in the portal](media/storage-files-how-to-create-large-file-share/create-large-file-share.png)
 
 1. Next, enter a name for your storage account. The name must be unique across Azure. The name also must be 3 to 24 characters in length, and it can only have numbers and lowercase letters.
-1. Select a location for your storage account, and make sure it's [one of the regions supported for large file shares](storage-files-planning.md#regional-availability).
+1. Select a location for your storage account, and make sure it's [one of the supported replication for large file shares](storage-files-planning.md#regional-availability).
 1. Set the replication to either **Locally redundant storage** or **Zone-redundant storage**.
 1. Leave these fields at their default values:
 
diff --git a/articles/storage/files/storage-files-planning.md b/articles/storage/files/storage-files-planning.md
@@ -172,8 +172,6 @@ This section only applies to the standard file shares. All premium file shares a
 Standard file shares with 100 TiB capacity limit are available globally in all Azure regions -
 
 - LRS: All regions, except for South Africa North and South Africa West.
-   - East US and West Europe: All new accounts are supported. A small number of existing accounts have not completed the upgrade process. You can check if your existing storage accounts have completed the upgrade process by attempting to [Enable large file shares](storage-files-how-to-create-large-file-share.md).
-
 - ZRS: All regions, except for Japan East, North Europe, South Africa North.
 - GRS/GZRS: Not supported.
 
