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

Author: tamram

articles/active-directory-b2c/TOC.yml

@@ -187,6 +187,8 @@
       - name: Custom email
         href: custom-email.md
         displayName: verification
+      - name: Disable email verification
+        href: custom-policy-disable-email-verification.md
       - name: Enable JavaScript
         href: javascript-samples.md
       - name: Password complexity

articles/active-directory-b2c/custom-policy-disable-email-verification.md

@@ -0,0 +1,56 @@
+---
+title: Disable email verification during customer sign-up with a custom policy
+titleSuffix: Azure AD B2C
+description: Learn how to disable email verification during customer sign-up in Azure Active Directory B2C.
+services: active-directory-b2c
+author: msmimart
+manager: celestedg
+
+ms.service: active-directory
+ms.workload: identity
+ms.topic: conceptual
+ms.date: 03/11/2020
+ms.author: mimart
+ms.subservice: B2C
+---
+
+# Disable email verification during customer sign-up using a custom policy in Azure Active Directory B2C
+
+[!INCLUDE [disable email verification intro](../../includes/active-directory-b2c-disable-email-verification.md)]
+
+## Prerequisites
+
+Complete the steps in [Get started with custom policies](custom-policy-get-started.md). You should have a working custom policy for sign-up and sign-in with social and local accounts.
+
+## Add the metadata to the self-asserted technical profile
+
+The **LocalAccountSignUpWithLogonEmail** technical profile is a [self-asserted](self-asserted-technical-profile.md), which is invoked during the sign-up flow. To disable the email verification, set the `EnforceEmailVerification` metadata to false. Override the LocalAccountSignUpWithLogonEmail technical profiles in the extension file. Find the `ClaimsProviders` element. Add the following claims provider to the `ClaimsProviders` element:
+
+
+```XML
+<ClaimsProvider>
+  <DisplayName>Local Account</DisplayName>
+  <TechnicalProfiles>
+    <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
+      <Metadata>
+        <Item Key="EnforceEmailVerification">false</Item>
+      </Metadata>
+    </TechnicalProfile>
+  </TechnicalProfiles>
+</ClaimsProvider>
+```
+
+## Test the custom policy
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+2. Make sure you're using the directory that contains your Azure AD tenant by selecting the **Directory + subscription** filter in the top menu and choosing the directory that contains your Azure AD tenant.
+3. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **App registrations**.
+4. Select **Identity Experience Framework**.
+5. Select **Upload Custom Policy**, and then upload the two policy files that you changed.
+2. Select the sign-up or sign-in policy that you uploaded, and click the **Run now** button.
+3. You should be able to sign up using an email address without the validation.
+
+
+## Next steps
+
+- Learn more about the [self-asserted technical profile](self-asserted-technical-profile.md) in the IEF reference.

articles/active-directory-b2c/user-flow-disable-email-verification.md

@@ -9,16 +9,14 @@ manager: celestedg
 ms.service: active-directory
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 09/25/2018
+ms.date: 03/11/2020
 ms.author: mimart
 ms.subservice: B2C
 ---
 
 # Disable email verification during customer sign-up in Azure Active Directory B2C
 
-By default, Azure Active Directory B2C (Azure AD B2C) verifies your customer's email address for local accounts (accounts for users who sign up with email address or username). Azure AD B2C ensures valid email addresses by requiring customers to verify them during the sign-up process. It also prevents a malicious actors from using automated processes to generate fraudulent accounts in your applications.
-
-Some application developers prefer to skip email verification during the sign-up process and instead have customers verify their email address later. To support this, Azure AD B2C can be configured to disable email verification. Doing so creates a smoother sign-up process and gives developers the flexibility to differentiate customers that have verified their email address from customers that have not.
+[!INCLUDE [disable email verification intro](../../includes/active-directory-b2c-disable-email-verification.md)]
 
 Follow these steps to disable email verification:
 
@@ -30,8 +28,10 @@ Follow these steps to disable email verification:
 1. Select **Page layouts**.
 1. Select **Local account sign-up page**.
 1. Under **User attributes**, select **Email Address**.
-1. In the **REQUIRES VERIFICATION** drop down, select **No**.
+1. In the **REQUIRES VERIFICATION** drop-down, select **No**.
 1. Select **Save**. Email verification is now disabled for this user flow.
 
-> [!WARNING]
-> Disabling email verification in the sign-up process may lead to spam. If you disable the default Azure AD B2C-provided email verification, we recommend that you implement a replacement verification system.
+## Next steps
+
+- Learn how to [customize the user interface in Azure Active Directory B2C](customize-ui-overview.md)
+

articles/active-directory-domain-services/change-sku.md

@@ -17,7 +17,7 @@ ms.author: iainfou
 
 # Change the SKU for an existing Azure AD Domain Services managed domain
 
-In Azure Active Directory Domain Services (Azure AD DS), the available performance and features are based on the SKU type. These feature differences include the backup frequency or maximum number of one-way outbound forest trusts (currently in preview). You select a SKU when you create the managed domain, and you can switch SKUs as your business needs change after the managed domain has been deployed. Changes in business requirements could include the need for more frequent backups or to create additional forest trusts. For more information on the limits and pricing of the different SKUs, see [Azure AD DS SKU concepts][concepts-sku] and [Azure AD DS pricing][pricing] pages.
+In Azure Active Directory Domain Services (Azure AD DS), the available performance and features are based on the SKU type. These feature differences include the backup frequency or maximum number of one-way outbound forest trusts (currently in preview). You select a SKU when you create the managed domain, and you can switch SKUs up or down as your business needs change after the managed domain has been deployed. Changes in business requirements could include the need for more frequent backups or to create additional forest trusts. For more information on the limits and pricing of the different SKUs, see [Azure AD DS SKU concepts][concepts-sku] and [Azure AD DS pricing][pricing] pages.
 
 This article shows you how to change the SKU for an existing Azure AD DS managed domain using the Azure portal.
 
@@ -34,9 +34,12 @@ To complete this article, you need the following resources and privileges:
 
 ## SKU change limitations
 
-There are some limitations for the SKU change operation if you use a resource forest (currently in preview) and have created one-way outbound forest trusts from Azure AD DS to an on-premises AD DS environment. The *Premium* and *Enterprise* SKUs define a limit on the number of trusts you can create. You can't change to a SKU with a lower maximum limit than you currently have configured.
+You can change SKUs up or down after the Azure AD DS managed domain has been deployed. However, if you use a resource forest (currently in preview) and have created one-way outbound forest trusts from Azure AD DS to an on-premises AD DS environment, there are some limitations for the SKU change operation. The *Premium* and *Enterprise* SKUs define a limit on the number of trusts you can create. You can't change to a SKU with a lower maximum limit than you currently have configured.
 
-For example, if you have created two forest trusts on the *Premium* SKU, you can't change down to the *Standard* SKU. The *Standard* SKU doesn't support forest trusts. Or, if you have created seven trusts on the *Premium* SKU, you can't change down to the *Enterprise* SKU. The *Enterprise* SKU supports a maximum of five trusts.
+For example:
+
+* If you have created two forest trusts on the *Premium* SKU, you can't change down to the *Standard* SKU. The *Standard* SKU doesn't support forest trusts.
+* Or, if you have created seven trusts on the *Premium* SKU, you can't change down to the *Enterprise* SKU. The *Enterprise* SKU supports a maximum of five trusts.
 
 For more information on these limits, see [Azure AD DS SKU features and limits][concepts-sku].
 

articles/active-directory/develop/tutorial-v2-asp-webapp.md

@@ -27,6 +27,9 @@ When you've completed this guide, your application will be able to accept sign-i
 
 > This guide requires Microsoft Visual Studio 2019.  Don’t have it?  [Download Visual Studio 2019 for free](https://www.visualstudio.com/downloads/).
 
+>[!NOTE]
+> If you are new to the Microsoft identity platform, we recommend you start with the [Add Microsoft identity platform sign-in to an ASP.NET web app](quickstart-v2-aspnet-webapp.md).
+
 ## How the sample app generated by this guide works
 
 ![Shows how the sample app generated by this tutorial works](media/active-directory-develop-guidedsetup-aspnetwebapp-intro/aspnetbrowsergeneral.svg)

articles/active-directory/develop/tutorial-v2-aspnet-daemon-web-app.md

@@ -36,7 +36,8 @@ The app is built as an ASP.NET MVC application. It uses the OWIN OpenID Connect
 
 The "daemon" component in this sample is an API controller, `SyncController.cs`. When the controller is called, it pulls in a list of users in the customer's Azure Active Directory (Azure AD) tenant from Microsoft Graph. `SyncController.cs` is triggered by an AJAX call in the web application. It uses the [Microsoft Authentication Library (MSAL) for .NET](msal-overview.md) to acquire an access token for Microsoft Graph.
 
-For a simpler console daemon application, see the [.NET Core daemon quickstart](quickstart-v2-netcore-daemon.md).
+>[!NOTE]
+> If you are new to the Microsoft identity platform, we recommend you start with the [.NET Core daemon quickstart](quickstart-v2-netcore-daemon.md).
 
 ## Scenario
 

articles/active-directory/develop/tutorial-v2-ios.md

@@ -22,6 +22,9 @@ In this tutorial, you'll learn how to integrate an iOS or macOS app with the Mic
 
 When you've completed the guide, your application will accept sign-ins of personal Microsoft accounts (including outlook.com, live.com, and others) and work or school accounts from any company or organization that uses Azure Active Directory.
 
+>[!NOTE]
+> If you are new to the Microsoft identity platform, we recommend you start with the [Sign in users and call the Microsoft Graph API from an iOS or macOS app](quickstart-v2-ios.md).
+
 ## How this tutorial works
 
 ![Shows how the sample app generated by this tutorial works](../../../includes/media/active-directory-develop-guidedsetup-ios-introduction/iosintro.svg)

articles/active-directory/develop/tutorial-v2-javascript-spa.md

@@ -25,6 +25,9 @@ This guide demonstrates how a JavaScript single-page application (SPA) can:
 - Acquire an access token
 - Call the Microsoft Graph API or other APIs that require access tokens from the *Microsoft identity platform endpoint*
 
+>[!NOTE]
+> If you are new to the Microsoft identity platform, we recommend you start with the [Sign in users and get an access token in a JavaScript SPA quickstart](quickstart-v2-javascript.md).
+
 ## How the sample app generated by this guide works
 
 ![Shows how the sample app generated by this tutorial works](media/active-directory-develop-guidedsetup-javascriptspa-introduction/javascriptspa-intro.svg)

articles/active-directory/develop/tutorial-v2-windows-desktop.md

@@ -27,6 +27,9 @@ When you've completed the guide, your application will be able to call a protect
 > [!NOTE]
 > The guide requires Visual Studio 2015 Update 3, Visual Studio 2017, or Visual Studio 2019. Don’t have any of these versions? [Download Visual Studio 2019 for free](https://www.visualstudio.com/downloads/).
 
+>[!NOTE]
+> If you are new to the Microsoft identity platform, we recommend you start with the [Acquire a token and call Microsoft Graph API from a Windows desktop app](quickstart-v2-windows-desktop.md).
+
 ## How the sample app generated by this guide works
 
 ![Shows how the sample app generated by this tutorial works](./media/active-directory-develop-guidedsetup-windesktop-intro/windesktophowitworks.svg)

articles/active-directory/develop/tutorial-v2-windows-uwp.md

@@ -29,6 +29,9 @@ At the end of this guide, your application calls a protected API by using person
 >[!NOTE]
 > This guide requires Visual Studio with Universal Windows Platform development installed. See [Get set up](https://docs.microsoft.com/windows/uwp/get-started/get-set-up) for instructions to download and configure Visual Studio to develop Universal Windows Platform apps.
 
+>[!NOTE]
+> If you are new to the Microsoft identity platform, we recommend you start with the [Call the Microsoft Graph API from a Universal Windows Platform (UWP) application quickstart](quickstart-v2-uwp.md).
+
 ## How this guide works
 
 ![Shows how the sample app generated by this tutorial works](./media/tutorial-v2-windows-uwp/uwp-intro.svg)