Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into get-started-speech-translation

Author: ShawnJackson

.openpublishing.redirection.json

@@ -18032,6 +18032,11 @@
       "redirect_url": "/azure/lab-services/class-type-ethical-hacking",
       "redirect_document_id": true
     },
+    {
+      "source_path_from_root": "/articles/lab-services/class-type-ethical-hacking-virtualbox.md",
+      "redirect_url": "/azure/lab-services/class-types",
+      "redirect_document_id": false
+    },    
     {
       "source_path_from_root": "/articles/lab-services/classroom-labs/class-type-jupyter-notebook.md",
       "redirect_url": "/azure/lab-services/class-type-jupyter-notebook",
@@ -21052,7 +21057,11 @@
       "redirect_url": "/azure/machine-learning/reference-yaml-job-pipeline",
       "redirect_document_id": false
     },
-
+    {
+      "source_path_from_root": "/articles/machine-learning/tutorial-pipeline-batch-scoring-classification.md",
+      "redirect_url": "/azure/machine-learning/tutorial-pipeline-python-sdk",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/cognitive-services/QnAMaker/reference-precise-answering.md",
       "redirect_url": "/azure/cognitive-services/language/custom-question-answering/concepts/precise-answering",

articles/active-directory-domain-services/synchronization.md

@@ -20,14 +20,15 @@ Objects and credentials in an Azure Active Directory Domain Services (Azure AD D
 
 In a hybrid environment, objects and credentials from an on-premises AD DS domain can be synchronized to Azure AD using Azure AD Connect. Once those objects are successfully synchronized to Azure AD, the automatic background sync then makes those objects and credentials available to applications using the managed domain.
 
-If on-prem AD DS and Azure AD are configured for federated authentication using ADFS then there is no (current/valid) password hash available in Azure DS. Azure AD user accounts created before fed auth was implemented might have an old password hash but this likely doesn't match a hash of their on-prem password. Hence Azure AD DS won't be able to validate the users credentials.
+If on-premises AD DS and Azure AD are configured for federated authentication using ADFS without password hash sync, or if third-party identity protection products and Azure AD are configured for federated authentication without password hash sync, no (current/valid) password hash is available in Azure DS. Azure AD user accounts created before fed auth was implemented might have an old password hash, but this likely doesn't match a hash of their on-premises password. Hence, Azure AD DS won't be able to validate a user's credentials.
 
 The following diagram illustrates how synchronization works between Azure AD DS, Azure AD, and an optional on-premises AD DS environment:
 
 ![Synchronization overview for an Azure AD Domain Services managed domain](./media/active-directory-domain-services-design-guide/sync-topology.png)
 
 ## Synchronization from Azure AD to Azure AD DS
 
+
 User accounts, group memberships, and credential hashes are synchronized one way from Azure AD to Azure AD DS. This synchronization process is automatic. You don't need to configure, monitor, or manage this synchronization process. The initial synchronization may take a few hours to a couple of days, depending on the number of objects in the Azure AD directory. After the initial synchronization is complete, changes that are made in Azure AD, such as password or attribute changes, are then automatically synchronized to Azure AD DS.
 
 When a user is created in Azure AD, they're not synchronized to Azure AD DS until they change their password in Azure AD. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The password hashes are needed to successfully authenticate a user in Azure AD DS.

articles/active-directory/authentication/concept-authentication-phone-options.md

@@ -76,6 +76,9 @@ If you have problems with phone authentication for Azure AD, review the followin
    * Have the user change methods or activate SMS on the device.
 * Faulty telecom providers such as no phone input detected, missing DTMF tones issues, blocked caller ID on multiple devices, or blocked SMS across multiple devices.
    * Microsoft uses multiple telecom providers to route phone calls and SMS messages for authentication. If you see any of the above issues, have a user attempt to use the method at least five times within 5 minutes and have that user's information available when contacting Microsoft support.
+*  Poor signal quality.
+   * Have the user attempt to log in using a wi-fi connection by installing the Microsoft Authenticator app.
+   * Or, use SMS authentication instead of phone (voice) authentication.
 
 ## Next steps
 

articles/active-directory/authentication/tutorial-enable-sspr.md

@@ -29,6 +29,10 @@ In this tutorial you learn how to:
 > * Set up authentication methods and registration options
 > * Test the SSPR process as a user
 
+## Video tutorial
+
+You can also follow along in a related video: [How to enable and configure SSPR in Azure AD](https://www.youtube.com/embed/rA8TvhNcCvQ?azure-portal=true).
+
 ## Prerequisites
 
 To finish this tutorial, you need the following resources and privileges:

articles/active-directory/conditional-access/concept-conditional-access-conditions.md

@@ -6,12 +6,12 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 01/25/2022
+ms.date: 01/26/2022
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
 manager: karenhoran
-ms.reviewer: calebb, sandeo-MSFT
+ms.reviewer: calebb, sandeo
 
 ms.collection: M365-identity-device-management
 ---
@@ -43,11 +43,12 @@ Azure AD Conditional Access supports the following device platforms:
 - iOS
 - Windows
 - macOS
+- Linux (Preview)
 
 If you block legacy authentication using the **Other clients** condition, you can also set the device platform condition.
 
 > [!IMPORTANT]
-> Microsoft recommends that you have a Conditional Access policy for unsupported device platforms. As an example, if you want to block access to your corporate resources from Linux or any other unsupported clients, you should configure a policy with a Device platforms condition that includes any device and excludes supported device platforms and Grant control set to Block access.
+> Microsoft recommends that you have a Conditional Access policy for unsupported device platforms. As an example, if you want to block access to your corporate resources from **Chrome OS** or any other unsupported clients, you should configure a policy with a Device platforms condition that includes any device and excludes supported device platforms and Grant control set to Block access.
 
 ## Locations
 

articles/active-directory/conditional-access/concept-conditional-access-grant.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 11/04/2021
+ms.date: 01/27/2022
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -53,7 +53,7 @@ Selecting this checkbox will require users to perform Azure AD Multi-Factor Auth
 
 ### Require device to be marked as compliant
 
-Organizations who have deployed Microsoft Intune can use the information returned from their devices to identify devices that meet specific compliance requirements. This policy compliance information is forwarded from Intune to Azure AD where Conditional Access can make decisions to grant or block access to resources. For more information about compliance policies, see the article [Set rules on devices to allow access to resources in your organization using Intune](/intune/protect/device-compliance-get-started).
+Organizations who have deployed Microsoft Intune can use the information returned from their devices to identify devices that meet specific compliance requirements. Policy compliance information is sent from Intune to Azure AD so Conditional Access can decide to grant or block access to resources. For more information about compliance policies, see the article [Set rules on devices to allow access to resources in your organization using Intune](/intune/protect/device-compliance-get-started).
 
 A device can be marked as compliant by Intune (for any device OS) or by third-party MDM system for Windows 10 devices. A list of supported third-party MDM systems can be found in the article [Support third-party device compliance partners in Intune](/mem/intune/protect/device-compliance-partners).
 
@@ -62,9 +62,9 @@ Devices must be registered in Azure AD before they can be marked as compliant. M
 **Remarks**
 
 - The **Require device to be marked as compliant** requirement:
-   - Only supports Windows Windows current (Windows 10+), iOS, Android and macOS devices registered with Azure AD and enrolled with Intune.
+   - Only supports Windows 10+, iOS, Android, and macOS devices registered with Azure AD and enrolled with Intune.
    - For devices enrolled with third-party MDM systems, see [Support third-party device compliance partners in Intune](/mem/intune/protect/device-compliance-partners).
-   - Conditional Access cannot consider Microsoft Edge in InPrivate mode as a compliant device.
+   - Conditional Access can’t consider Microsoft Edge in InPrivate mode as a compliant device.
 
 > [!NOTE]
 > On Windows 7, iOS, Android, macOS, and some third-party web browsers Azure AD identifies the device using a client certificate that is provisioned when the device is registered with Azure AD. When a user first signs in through the browser the user is prompted to select the certificate. The end user must select this certificate before they can continue to use the browser.
@@ -73,19 +73,19 @@ Devices must be registered in Azure AD before they can be marked as compliant. M
 
 Organizations can choose to use the device identity as part of their Conditional Access policy. Organizations can require that devices are hybrid Azure AD joined using this checkbox. For more information about device identities, see the article [What is a device identity?](../devices/overview.md).
 
-When using the [device-code OAuth flow](../develop/v2-oauth2-device-code.md), the require managed device grant control or a device state condition are not supported. This is because the device performing authentication cannot provide its device state to the device providing a code and the device state in the token is locked to the device performing authentication. Use the require multi-factor authentication grant control instead.
+When using the [device-code OAuth flow](../develop/v2-oauth2-device-code.md), the require managed device grant control or a device state condition aren’t supported. This is because the device performing authentication can’t provide its device state to the device providing a code and the device state in the token is locked to the device performing authentication. Use the require multi-factor authentication grant control instead.
 
 **Remarks**
 
 - The **Require hybrid Azure AD joined device** requirement:
    - Only supports domain joined Windows down-level (pre Windows 10) and Windows current (Windows 10+) devices.
-   - Conditional Access cannot consider Microsoft Edge in InPrivate mode as a hybrid Azure AD joined device.
+   - Conditional Access can’t consider Microsoft Edge in InPrivate mode as a hybrid Azure AD joined device.
 
 ### Require approved client app
 
 Organizations can require that an access attempt to the selected cloud apps needs to be made from an approved client app. These approved client apps support [Intune app protection policies](/intune/app-protection-policy) independent of any mobile-device management (MDM) solution.
 
-In order to apply this grant control, Conditional Access requires that the device is registered in Azure Active Directory, which requires the use of a broker app. The broker app can be the Microsoft Authenticator for iOS, or either the Microsoft Authenticator or Microsoft Company portal for Android devices. If a broker app is not installed on the device when the user attempts to authenticate, the user gets redirected to the appropriate app store to install the required broker app.
+In order to apply this grant control, Conditional Access requires that the device is registered in Azure Active Directory, which requires the use of a broker app. The broker app can be the Microsoft Authenticator for iOS, or either the Microsoft Authenticator or Microsoft Company portal for Android devices. If a broker app isn’t installed on the device when the user attempts to authenticate, the user gets redirected to the appropriate app store to install the required broker app.
 
 The following client apps have been confirmed to support this setting:
 
@@ -126,16 +126,16 @@ The following client apps have been confirmed to support this setting:
 - The **Require approved client app** requirement:
    - Only supports the iOS and Android for device platform condition.
    - A broker app is required to register the device. The broker app can be the Microsoft Authenticator for iOS, or either the Microsoft Authenticator or Microsoft Company portal for Android devices.
-- Conditional Access cannot consider Microsoft Edge in InPrivate mode an approved client app.
-- Using Azure AD Application Proxy to enable the Power BI mobile app to connect to on premises Power BI Report Server is not supported with conditional access policies that require the Microsoft Power BI app as an approved client app.
+- Conditional Access can’t consider Microsoft Edge in InPrivate mode an approved client app.
+- Using Azure AD Application Proxy to enable the Power BI mobile app to connect to on premises Power BI Report Server isn’t supported with Conditional Access policies that require the Microsoft Power BI app as an approved client app.
 
 See the article, [How to: Require approved client apps for cloud app access with Conditional Access](app-based-conditional-access.md) for configuration examples.
 
 ### Require app protection policy
 
 In your Conditional Access policy, you can require an [Intune app protection policy](/intune/app-protection-policy) be present on the client app before access is available to the selected cloud apps. 
 
-In order to apply this grant control, Conditional Access requires that the device is registered in Azure Active Directory, which requires the use of a broker app. The broker app can be either the Microsoft Authenticator for iOS, or the Microsoft Company portal for Android devices. If a broker app is not installed on the device when the user attempts to authenticate, the user gets redirected to the app store to install the broker app.
+In order to apply this grant control, Conditional Access requires that the device is registered in Azure Active Directory, which requires the use of a broker app. The broker app can be either the Microsoft Authenticator for iOS, or the Microsoft Company portal for Android devices. If a broker app isn’t installed on the device when the user attempts to authenticate, the user gets redirected to the app store to install the broker app.
 
 Applications are required to have the **Intune SDK** with **Policy Assurance** implemented and meet certain other requirements to support this setting. Developers implementing applications with the Intune SDK can find more information in the SDK documentation on these requirements.
 
@@ -167,24 +167,24 @@ The following client apps have been confirmed to support this setting:
 - Apps for app protection policy support the Intune mobile application management feature with policy protection.
 - The **Require app protection policy** requirements:
     - Only supports the iOS and Android for device platform condition.
-    - A broker app is required to register the device. On iOS, the broker app is Microsoft Authenticator and on Android, it is Intune Company Portal app.
+    - A broker app is required to register the device. On iOS, the broker app is Microsoft Authenticator and on Android, it’s Intune Company Portal app.
 
 See the article, [How to: Require app protection policy and an approved client app for cloud app access with Conditional Access](app-protection-based-conditional-access.md) for configuration examples.
 
 ### Require password change 
 
 When user risk is detected, using the user risk policy conditions, administrators can choose to have the user securely change the password using Azure AD self-service password reset. If user risk is detected, users can perform a self-service password reset to self-remediate, this process will close the user risk event to prevent unnecessary noise for administrators. 
 
-When a user is prompted to change their password, they will first be required to complete multi-factor authentication. You’ll want to make sure all of your users have registered for multi-factor authentication, so they are prepared in case risk is detected for their account.  
+When a user is prompted to change their password, they’ll first be required to complete multi-factor authentication. You’ll want to make sure all of your users have registered for multi-factor authentication, so they’re prepared in case risk is detected for their account.  
 
 > [!WARNING]
 > Users must have previously registered for self-service password reset before triggering the user risk policy. 
 
 Restrictions when you configure a policy using the password change control.  
 
 1. The policy must be assigned to ‘all cloud apps’. This requirement prevents an attacker from using a different app to change the user’s password and reset account risk, by signing into a different app. 
-1. Require password change cannot be used with other controls, like requiring a compliant device.  
-1. The password change control can only be used with the user and group assignment condition, cloud app assignment condition (which must be set to all) and user risk conditions. 
+1. Require password change can’t be used with other controls, like requiring a compliant device.  
+1. The password change control can only be used with the user and group assignment condition, cloud app assignment condition (which must be set to all), and user risk conditions. 
 
 ### Terms of use
 

articles/active-directory/develop/quickstart-v2-android.md

@@ -10,6 +10,7 @@ ms.subservice: develop
 ms.topic: portal
 ms.workload: identity
 ms.date: 01/14/2022
+ROBOTS: NOINDEX
 ms.author: marsma
 ms.custom: aaddev, identityplatformtop40, "scenarios:getting-started", "languages:Android", has-adal-ref, mode-api
 #Customer intent: As an application developer, I want to learn how Android native apps can call protected APIs that require login and access tokens using the Microsoft identity platform.

articles/active-directory/develop/quickstart-v2-aspnet-core-web-api.md

@@ -10,6 +10,7 @@ ms.subservice: develop
 ms.topic: portal
 ms.workload: identity
 ms.date: 01/11/2022
+ROBOTS: NOINDEX
 ms.author: jmprieur
 ms.custom: devx-track-csharp, "scenarios:getting-started", "languages:aspnet-core", mode-api
 #Customer intent: As an application developer, I want to know how to write an ASP.NET Core web API that uses the Microsoft identity platform to authorize API requests from clients.

articles/active-directory/develop/quickstart-v2-aspnet-core-webapp-calls-graph.md

@@ -10,6 +10,7 @@ ms.subservice: develop
 ms.topic: portal
 ms.workload: identity
 ms.date: 11/22/2021
+ROBOTS: NOINDEX
 ms.author: jmprieur
 ms.custom: devx-track-csharp, aaddev, "scenarios:getting-started", "languages:aspnet-core", mode-other
 #Customer intent: As an application developer, I want to download and run a demo ASP.NET Core web app that can sign in users with personal Microsoft accounts (MSA) and work/school accounts from any Azure Active Directory instance, then access their data in Microsoft Graph on their behalf.

articles/active-directory/develop/quickstart-v2-aspnet-core-webapp.md

@@ -10,6 +10,7 @@ ms.subservice: develop
 ms.topic: portal
 ms.workload: identity
 ms.date: 11/22/2021
+ROBOTS: NOINDEX
 ms.author: jmprieur
 ms.custom: devx-track-csharp, aaddev, identityplatformtop40, "scenarios:getting-started", "languages:aspnet-core", mode-other
 #Customer intent: As an application developer, I want to know how to write an ASP.NET Core web app that can sign in personal accounts, as well as work and school accounts, from any Azure Active Directory instance.