Merge pull request #195262 from MicrosoftDocs/main

4/15  PM Publish

Author: huypub

.openpublishing.redirection.iot-hub.json

@@ -1088,6 +1088,16 @@
       "redirect_url": "/azure/iot-hub/iot-hub-device-management-iot-toolkit",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/iot-hub/iot-hub-operations-monitoring.md",
+      "redirect_url": "/azure/iot-hub/monitor-iot-hub",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/iot-hub/iot-hub-migrate-to-diagnostics-settings.md",
+      "redirect_url": "/azure/iot-hub/monitor-iot-hub",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/iot-hub/iot-hub-protocol-gateway.md",
       "redirect_url": "/azure/iot-edge/iot-edge-as-gateway",

.openpublishing.redirection.json

@@ -44218,7 +44218,12 @@
       "redirect_url": "/azure/governance/policy/samples",
       "redirect_document_id": false
     },
-   {
+    {
+      "source_path_from_root": "/articles/cognitive-services/QnAMaker/custom-question-answering.md",
+      "redirect_url": "/azure/cognitive-services/language-service/question-answering/overview",
+      "redirect_document_id": false
+    },
+    {
       "source_path_from_root": "/articles/openshift/howto-secure-openshift-with-front-door-feb-22.md",
       "redirect_url": "/azure/openshift/howto-secure-openshift-with-front-door",
       "redirect_document_id": false

articles/active-directory-b2c/data-residency.md

@@ -52,7 +52,7 @@ Data resides in **Asia Pacific** for the following countries/regions:
 
 Data resides in **Australia** for the following countries/regions:
 
-> Australia and New Zealand
+> Australia (AU) and New Zealand (NZ)
 
 The following countries/regions are in the process of being added to the list. For now, you can still use Azure AD B2C by picking any of the countries/regions above.
 

articles/active-directory/app-provisioning/on-premises-migrate-microsoft-identity-manager.md

@@ -21,31 +21,38 @@ You can import into the Azure Active Directory (Azure AD) ECMA Connector Host a
 >[!IMPORTANT]
 >Currently, only the generic SQL and LDAP connectors are supported for use with the Azure AD ECMA Connector Host.
 
-## Create and export a connector configuration in MIM Sync
-If you already have MIM Sync with your ECMA connector configured, skip to step 10.
+## Create a connector configuration in MIM Sync
+This section is included for illustrative purposes, if you wish to set up MIM Sync with a connector. If you already have MIM Sync with your ECMA connector configured, skip to the next section.
 
  1. Prepare a Windows Server 2016 server, which is distinct from the server that will be used for running the Azure AD ECMA Connector Host. This host server should either have a SQL Server 2016 database colocated or have network connectivity to a SQL Server 2016 database. One way to set up this server is by deploying an Azure virtual machine with the image **SQL Server 2016 SP1 Standard on Windows Server 2016**. This server doesn't need internet connectivity other than remote desktop access for setup purposes.
  1. Create an account for use during the MIM Sync installation. It can be a local account on that Windows Server instance. To create a local account, open **Control Panel** > **User Accounts**, and add the user account **mimsync**.
  1. Add the account created in the previous step to the local Administrators group.
  1. Give the account created earlier the ability to run a service. Start **Local Security Policy** and select **Local Policies** > **User Rights Assignment** > **Log on as a service**. Add the account mentioned earlier.
- 1. Install MIM Sync on this host. If you don't have MIM Sync binaries, you can install an evaluation by downloading the zip file from the [Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=48244), mounting the ISO image, and copying the folder **Synchronization Service** to the Windows Server host. Then run the setup program contained in that folder. Evaluation software is time limited and will expire. It isn't intended for production use.
+ 1. Install MIM Sync on this host.
  1. After the installation of MIM Sync is complete, sign out and sign back in.
- 1. Install your connector on the same server as MIM Sync. For illustration purposes, this test lab guide will illustrate using one of the Microsoft-supplied connectors for download from the [Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=51495).
+ 1. Install your connector on the same server as MIM Sync. For illustration purposes, use either of the Microsoft-supplied SQL or LDAP connectors for download from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=51495).
  1. Start the Synchronization Service UI. Select **Management Agents**. Select **Create**, and specify the connector management agent. Be sure to select a connector management agent that's ECMA based.
  1. Give the connector a name, and configure the parameters needed to import and export data to the connector. Be sure to configure that the connector can import and export single-valued string attributes of a user or person object type.
+
+## Export a connector configuration from MIM Sync
+
  1. On the MIM Sync server computer, start the Synchronization Service UI, if it isn't already running. Select **Management Agents**.
  1. Select the connector, and select **Export Management Agent**. Save the XML file, and the DLL and related software for your connector, to the Windows server that will be holding the ECMA Connector Host.
 
 At this point, the MIM Sync server is no longer needed.
 
- 1. Sign in to the Windows server as the account that the Azure AD ECMA Connector Host will run as.
+## Import a connector configuration
+
+ 1. Install the ECMA Connector host and provisioning agent on a Windows Server, using the [provisioning users into SQL based applications](on-premises-sql-connector-configure.md#download-install-and-configure-the-azure-ad-connect-provisioning-agent-package) or [provisioning users into LDAP directories](on-premises-ldap-connector-configure.md#download-install-and-configure-the-azure-ad-connect-provisioning-agent-package) articles.
+ 1. Sign in to the Windows server as the account that the Azure AD ECMA Connector Host runs as.
  1. Change to the directory C:\Program Files\Microsoft ECMA2host\Service\ECMA. Ensure there are one or more DLLs already present in that directory. Those DLLs correspond to Microsoft-delivered connectors.
  1. Copy the MA DLL for your connector, and any of its prerequisite DLLs, to that same ECMA subdirectory of the Service directory.
  1. Change to the directory C:\Program Files\Microsoft ECMA2Host\Wizard. Run the program Microsoft.ECMA2Host.ConfigWizard.exe to set up the ECMA Connector Host configuration.
  1. A new window appears with a list of connectors. By default, no connectors will be present. Select **New connector**.
- 1. Specify the management agent XML file that was exported from MIM Sync earlier. Continue with the configuration and schema-mapping instructions from the section "Configure a connector."
+ 1. Specify the management agent XML file that was exported from MIM Sync earlier. Continue with the configuration and schema-mapping instructions from the section "Create a connector" in either the [provisioning users into SQL based applications](on-premises-sql-connector-configure.md#create-a-generic-sql-connector) or [provisioning users into LDAP directories](on-premises-ldap-connector-configure.md#configure-a-generic-ldap-connector) articles.
 
 ## Next steps
 
-- [App provisioning](user-provisioning.md)
-- [Generic SQL connector](on-premises-sql-connector-configure.md)
+- Learn more about [App provisioning](user-provisioning.md)
+- [Configuring Azure AD to provision users into SQL based applications](on-premises-sql-connector-configure.md) with the Generic SQL connector
+- [Configuring Azure AD to provision users into LDAP directories](on-premises-ldap-connector-configure.md) with the Generic LDAP connector

articles/active-directory/authentication/howto-password-ban-bad-on-premises-deploy.md

@@ -406,6 +406,9 @@ The current setting can be queried using the `Get-AzureADPasswordProtectionProxy
 
 The `Get-AzureADPasswordProtectionProxy` cmdlet may be used to query the software version of all currently installed Azure AD Password Protection proxy servers in a forest.
 
+> [!NOTE]
+> The proxy service will only automatically upgrade to a newer version when critical security patches are needed.
+
 ### Manual upgrade process
 
 A manual upgrade is accomplished by running the latest version of the `AzureADPasswordProtectionProxySetup.exe` software installer. The latest version of the software is available on the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=57071).

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

@@ -188,8 +188,8 @@ By selecting **Other clients**, you can specify a condition that affects apps th
 
 ## Device state (preview)
 
-> [!CAUTION]
-> **This preview feature has been deprecated.** Customers should use **Filter for devices** condition in Conditional Access to satisfy scenarios, previously achieved using device state (preview) condition.
+**This preview feature is being deprecated.** Customers should use the **Filter for devices** condition in the Conditional Access policy, to satisfy scenarios previously achieved using device state (preview) condition.
+
 
 The device state condition was used to exclude devices that are hybrid Azure AD joined and/or devices marked as compliant with a Microsoft Intune compliance policy from an organization's Conditional Access policies.
 

articles/active-directory/conditional-access/howto-conditional-access-session-lifetime.md

@@ -142,7 +142,7 @@ Use the What-If tool to simulate a login from the user to the target application
 To make sure that your policy works as expected, the recommended best practice is to test it before rolling it out into production. Ideally, use a test tenant to verify whether your new policy works as intended. For more information, see the article [Plan a Conditional Access deployment](plan-conditional-access.md).
 
 ## Known issues
-- If you configure sign-in frequency for mobile devices, authentication after each sign-in frequency internal would be slow (can take 30 seconds on average). Also, it could happen across various apps at the same time. 
+- If you configure sign-in frequency for mobile devices, authentication after each sign-in frequency interval could be slow (it can take 30 seconds on average). Also, it could happen across various apps at the same time. 
 - In iOS devices, if an app configures certificates as the first authentication factor and the app has both Sign-in frequency and [Intune mobile application management](/mem/intune/apps/app-lifecycle) policies applied, the end-users will be blocked from signing in to the app when the policy is triggered.
 
 ## Next steps

articles/active-directory/conditional-access/overview.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: overview
-ms.date: 02/08/2022
+ms.date: 04/15/2022
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -91,6 +91,8 @@ Customers with [Microsoft 365 Business Premium licenses](/office365/servicedescr
 
 Risk-based policies require access to [Identity Protection](../identity-protection/overview-identity-protection.md), which is an Azure AD P2 feature.
 
+Other products and features that may interact with Conditional Access policies require appropriate licensing for those products and features.
+
 ## Next steps
 
 - [Building a Conditional Access policy piece by piece](concept-conditional-access-policies.md)

articles/active-directory/develop/active-directory-v2-protocols.md

@@ -46,7 +46,7 @@ Three types of bearer tokens are used by the Microsoft identity platform as *sec
 
 * [ID tokens](id-tokens.md) - ID tokens are issued by the authorization server to the client application. Clients use ID tokens when signing in users and to get basic information about them.
 
-* **Refresh tokens** - The client uses a refresh token, or *RT*, to request new access and ID tokens from the authorization server. Your code should treat refresh tokens and their string content as opaque because they're intended for use only by authorization server.
+* [Refresh tokens](refresh-tokens.md) - The client uses a refresh token, or *RT*, to request new access and ID tokens from the authorization server. Your code should treat refresh tokens and their string content as opaque because they're intended for use only by authorization server.
 
 ## App registration
 

articles/active-directory/develop/v2-oauth2-client-creds-grant-flow.md

@@ -21,7 +21,7 @@ You can use the OAuth 2.0 client credentials grant specified in [RFC 6749](https
 
 This article describes how to program directly against the protocol in your application. When possible, we recommend you use the supported Microsoft Authentication Libraries (MSAL) instead to [acquire tokens and call secured web APIs](authentication-flows-app-scenarios.md#scenarios-and-supported-authentication-flows).  Also take a look at the [sample apps that use MSAL](sample-v2-code.md).
 
-The OAuth 2.0 client credentials grant flow permits a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service. For a higher level of assurance, the Microsoft identity platform also allows the calling service to authenticate using a [certificate](#second-case-access-token-request-with-a-certificate) or federated credential instead of a shared secret.  Because the applications own credentials are being used, these credentials must be kept safe - _never_ publish that credential in your source code, embed it in web pages, or use it in a widely distributed native application. 
+The OAuth 2.0 client credentials grant flow permits a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service. For a higher level of assurance, the Microsoft identity platform also allows the calling service to authenticate using a [certificate](#second-case-access-token-request-with-a-certificate) or federated credential instead of a shared secret.  Because the application's own credentials are being used, these credentials must be kept safe - _never_ publish that credential in your source code, embed it in web pages, or use it in a widely distributed native application. 
 
 In the client credentials flow, permissions are granted directly to the application itself by an administrator. When the app presents a token to a resource, the resource enforces that the app itself has authorization to perform an action since there is no user involved in the authentication.  This article covers both the steps needed to [authorize an application to call an API](#application-permissions), as well as [how to get the tokens needed to call that API](#get-a-token).