Merge branch 'master' into alexbuckgit/docutune-autopr-20210806T2052571745Z

Author: alexbuckgit

.openpublishing.publish.config.json

@@ -357,6 +357,12 @@
       "branch": "main",
       "branch_mapping": {}
     },
+    {
+      "path_to_root": "media-services-v3-dotnet-core-functions-integration",
+      "url": "https://github.com/Azure-Samples/media-services-v3-dotnet-core-functions-integration",
+      "branch": "main",
+      "branch_mapping": {}
+    },
     {
       "path_to_root": "samples-javascript",
       "url": "https://github.com/Microsoft/tsiclient",

.openpublishing.redirection.json

@@ -14063,6 +14063,16 @@
       "redirect_url": "/azure/azure-toolkit-for-intelliJ",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/azure-vmware/deploy-disaster-recovery-using-jetstream.md",
+      "redirect_url": "/azure/azure-vmware/concepts-run-command",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/azure-vmware/deploy-zerto-disaster-recovery.md",
+      "redirect_url": "/azure/azure-vmware/introduction",
+      "redirect_document_id": false
+    },    
     {
       "source_path_from_root": "/articles/azure-vmware/concepts-monitor-protection.md",
       "redirect_url": "/azure/azure-vmware/integrate-azure-native-services",

articles/active-directory-b2c/azure-monitor.md

@@ -31,6 +31,10 @@ In this article, you learn how to transfer the logs to an Azure Log Analytics wo
 > [!IMPORTANT]
 > When you plan to transfer Azure AD B2C logs to different monitoring solutions, or repository, consider the following. Azure AD B2C logs contain personal data. Such data should be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing, using appropriate technical or organizational measures.
 
+Watch this video to learn how to configure monitoring for Azure AD B2C using Azure Monitor.  
+
+>[!Video https://www.youtube.com/embed/tF2JS6TGc3g]
+
 ## Deployment overview
 
 Azure AD B2C leverages [Azure Active Directory monitoring](../active-directory/reports-monitoring/overview-monitoring.md). Because an Azure AD B2C tenant, unlike Azure AD tenants, can't have a subscription associated with it, we need to take some additional steps to enable the integration between Azure AD B2C and Log Analytics, which is where we'll send the logs.

articles/active-directory-b2c/azure-sentinel.md

@@ -38,7 +38,7 @@ In this tutorial, you'll learn to:
 
 Enable **Diagnostic settings** in Azure AD within your Azure AD B2C tenant to define where logs and metrics for a resource should be sent.
 
-Then after, [configure Azure AD B2C to send logs to Azure Monitor](https://docs.microsoft.com/azure/active-directory-b2c/azure-monitor).
+Then after, [configure Azure AD B2C to send logs to Azure Monitor](./azure-monitor.md).
 
 ## Deploy an Azure Sentinel instance
 
@@ -79,7 +79,7 @@ In the following example, we explain the scenario where you receive a notificati
 1. From the Azure Sentinel navigation menu, select **Analytics**.
 
 2. In the action bar at the top, select **+ Create** and select
-   **Scheduled query rule**. It will open the **Analytics rule wizard**.
+   **Scheduled query rule**. This will open the **Analytics rule wizard**.
 
 ![image shows select create scheduled query rule](./media/azure-sentinel/create-scheduled-rule.png)
 

articles/active-directory-b2c/language-customization.md

@@ -34,6 +34,10 @@ You might not need that level of control over what languages your customer sees.
 > [!NOTE]
 > If you're using custom user attributes, you need to provide your own translations. For more information, see [Customize your strings](#customize-your-strings).
 
+Watch this video to learn how to localize or customize language using Azure AD B2C.
+
+>[!Video https://www.youtube.com/embed/yqrX5_tA7Ms]
+
 ::: zone pivot="b2c-custom-policy"
 
 Localization requires three steps: 

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

@@ -140,6 +140,9 @@ Filters for devices (preview) condition in Conditional Access evaluates policy b
 | Include/exclude mode with negative operators (NotEquals, NotStartsWith, NotEndsWith, NotContains, NotIn) and use of any attributes including extensionAttributes1-15 | Registered device managed by Intune | Yes, if criteria are met |
 | Include/exclude mode with negative operators (NotEquals, NotStartsWith, NotEndsWith, NotContains, NotIn) and use of any attributes including extensionAttributes1-15 | Registered device not managed by Intune | Yes, if criteria are met and if device is compliant or Hybrid Azure AD joined |
 
+> [!IMPORTANT]
+> For unregistered devices, the only device information passed is the Operating System, Operating System Version, and the Browser.  This means for unregistered devices and Conditional Access policies using negative operators for filters for device, any value outside of these will be evaluated with an blank value.  For example, if an unregistered device was being evaluated with the following: **device.displayName -notContains *Example***. Since the unregistered device will pass a blank display name, which is not the value of *Example*, the resulting condition will be true.
+
 ## Next steps
 
 - [Conditional Access: Conditions](concept-conditional-access-conditions.md)

articles/active-directory/develop/TOC.yml

@@ -256,7 +256,19 @@
       - name: Code configuration
         href: scenario-desktop-app-configuration.md
       - name: Acquire token
-        href: scenario-desktop-acquire-token.md
+        items:
+        - name: Overview
+          href: scenario-desktop-acquire-token.md
+        - name: Interactively
+          href: scenario-desktop-acquire-token-interactive.md
+        - name: Interactive with WAM
+          href: scenario-desktop-acquire-token-wam.md
+        - name: Integrated Windows Auth
+          href: scenario-desktop-acquire-token-integrated-windows-authentication.md
+        - name: Username Password
+          href: scenario-desktop-acquire-token-username-password.md
+        - name: Device code flow
+          href: scenario-desktop-acquire-token-device-code-flow.md
       - name: Call a web API
         href: scenario-desktop-call-api.md
       - name: Move to production

articles/active-directory/develop/authentication-flows-app-scenarios.md

@@ -56,7 +56,7 @@ However, there are also daemon apps. In these scenarios, applications acquire to
 
 Security tokens can be acquired by multiple types of applications. These applications tend to be separated into the following three categories. Each is used with different libraries and objects.
 
-- **Single-page applications**: Also known as SPAs, these are web apps in which tokens are acquired by a JavaScript or TypeScript app running in the browser. Many modern apps have a single-page application at the front end that's primarily written in JavaScript. The application often uses a framework like Angular, React, or Vue. MSAL.js is the only Microsoft authentication library that supports single-page applications.
+- **Single-page applications**: Also known as SPAs, these are web apps in which tokens are acquired by a JavaScript or TypeScript app running in the browser. Many modern apps have a single-page application at the front end that's primarily written in JavaScript. The application often uses a framework like Angular, React, or Vue. MSAL.js is the only Microsoft Authentication Library that supports single-page applications.
 
 - **Public client applications**: Apps in this category, like the following types, always sign in users:
   - Desktop apps that call web APIs on behalf of signed-in users
@@ -130,11 +130,11 @@ Applications running on a device without a browser can still call an API on beha
 
 ![Device code flow](media/scenarios/device-code-flow-app.svg)
 
-Though we don't recommend that you use it, the [username/password flow](scenario-desktop-acquire-token.md#username-and-password) is available in public client applications. This flow is still needed in some scenarios like DevOps.
+Though we don't recommend that you use it, the [username/password flow](scenario-desktop-acquire-token-username-password.md) is available in public client applications. This flow is still needed in some scenarios like DevOps.
 
 Using the username/password flow constrains your applications. For instance, applications can't sign in a user who needs to use multifactor authentication or the Conditional Access tool in Azure AD. Your applications also don't benefit from single sign-on. Authentication with the username/password flow goes against the principles of modern authentication and is provided only for legacy reasons.
 
-In desktop apps, if you want the token cache to persist, you can customize the [token cache serialization](scenario-desktop-acquire-token.md#file-based-token-cache). By implementing [dual token cache serialization](scenario-desktop-acquire-token.md#dual-token-cache-serialization-msal-unified-cache--adal-v3), you can use backward-compatible and forward-compatible token caches. These tokens support previous generations of authentication libraries. Specific libraries include Azure AD Authentication Library for .NET (ADAL.NET) version 3 and version 4.
+In desktop apps, if you want the token cache to persist, you can customize the [token cache serialization](msal-net-token-cache-serialization.md). By implementing [dual token cache serialization](msal-net-token-cache-serialization.md#dual-token-cache-serialization-msal-unified-cache-and-adal-v3), you can use backward-compatible and forward-compatible token caches. These tokens support previous generations of authentication libraries. Specific libraries include Azure AD Authentication Library for .NET (ADAL.NET) version 3 and version 4.
 
 For more information, see [Desktop app that calls web APIs](scenario-desktop-overview.md).
 
@@ -221,7 +221,7 @@ Scenarios that involve acquiring tokens also map to OAuth 2.0 authentication flo
  </tr>
 
   <tr>
-   <td rowspan="3"><a href="scenario-desktop-overview.md"><img alt=Desktop app that calls web APIs" src="media/scenarios/desktop-app.svg"></a></td>
+   <td rowspan="3"><a href="scenario-desktop-overview.md"><img alt="Desktop app that calls web APIs" src="media/scenarios/desktop-app.svg"></a></td>
    <td rowspan="4"><a href="scenario-desktop-overview.md">Desktop app that calls web APIs</a></td>
    <td>Interactive by using <a href="v2-oauth2-auth-code-flow.md">authorization code</a> with PKCE</td>
    <td>Work or school accounts, personal accounts, and Azure AD B2C</td>
@@ -238,7 +238,7 @@ Scenarios that involve acquiring tokens also map to OAuth 2.0 authentication flo
  </tr>
 
   <tr>
-   <td><a href="scenario-desktop-acquire-token.md#command-line-tool-without-a-web-browser"><img alt="Browserless application" src="media/scenarios/device-code-flow-app.svg"></a></td>
+   <td><a href="scenario-desktop-acquire-token-device-code-flow.md"><img alt="Browserless application" src="media/scenarios/device-code-flow-app.svg"></a></td>
    <td><a href="v2-oauth2-device-code.md">Device code</a></td>
    <td>Work or school accounts, personal accounts, but not Azure AD B2C</td>
  </tr>
@@ -274,7 +274,7 @@ Scenarios that involve acquiring tokens also map to OAuth 2.0 authentication flo
 
 ## Scenarios and supported platforms and languages
 
-Microsoft authentication libraries support multiple platforms:
+Microsoft Authentication Libraries support multiple platforms:
 
 - .NET Core
 - .NET Framework

articles/active-directory/develop/media/scenario-desktop-acquire-token-wam/wam-account-picker.png

@@ -24,11 +24,11 @@ The Microsoft Authentication Library (MSAL) supports several authentication flow
 |--|--|--|
 | [Authorization code](#authorization-code) | Used in apps that are installed on a device to gain access to protected resources, such as web APIs. Enables you to add sign-in and API access to your mobile and desktop apps. | [Desktop apps](scenario-desktop-overview.md), [mobile apps](scenario-mobile-overview.md), [web apps](scenario-web-app-call-api-overview.md) |
 | [Client credentials](#client-credentials) | Allows you to access web-hosted resources by using the identity of an application. Commonly used for server-to-server interactions that must run in the background, without immediate interaction with a user. | [Daemon apps](scenario-daemon-overview.md) |
-| [Device code](#device-code) | Allows users to sign in to input-constrained devices such as a smart TV, IoT device, or printer. | [Desktop/mobile apps](scenario-desktop-acquire-token.md#command-line-tool-without-a-web-browser) |
+| [Device code](#device-code) | Allows users to sign in to input-constrained devices such as a smart TV, IoT device, or printer. | [Desktop/mobile apps](scenario-desktop-acquire-token-device-code-flow.md) |
 | [Implicit grant](#implicit-grant) | Allows the app to get tokens without performing a back-end server credential exchange. Enables the app to sign in the user, maintain session, and get tokens to other web APIs, all within the client JavaScript code. | [Single-page applications (SPA)](scenario-spa-overview.md) |
 | [On-behalf-of](#on-behalf-of) | An application invokes a service or web API, which in turn needs to call another service or web API. The idea is to propagate the delegated user identity and permissions through the request chain. | [Web APIs](scenario-web-api-call-api-overview.md) |
-| [Username/password](#usernamepassword) | Allows an application to sign in the user by directly handling their password. This flow isn't recommended. | [Desktop/mobile apps](scenario-desktop-acquire-token.md#username-and-password) |
-| [Integrated Windows Authentication](#integrated-windows-authentication) | Allows applications on domain or Azure Active Directory (Azure AD) joined computers to acquire a token silently (without any UI interaction from the user). | [Desktop/mobile apps](scenario-desktop-acquire-token.md#integrated-windows-authentication) |
+| [Username/password](#usernamepassword) | Allows an application to sign in the user by directly handling their password. This flow isn't recommended. | [Desktop/mobile apps](scenario-desktop-acquire-token-username-password.md) |
+| [Integrated Windows Authentication](#integrated-windows-authentication) | Allows applications on domain or Azure Active Directory (Azure AD) joined computers to acquire a token silently (without any UI interaction from the user). | [Desktop/mobile apps](scenario-desktop-acquire-token-integrated-windows-authentication.md) |
 
 ## How each flow emits tokens and codes