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

Author: cherylmc

articles/active-directory/authentication/concept-sspr-policy.md

@@ -81,8 +81,8 @@ The following table describes the password policy settings applied to user accou
 | Characters not allowed | Unicode characters. |
 | Password restrictions |<ul><li>A minimum of 8 characters and a maximum of 256 characters.</li><li>Requires three out of four of the following:<ul><li>Lowercase characters.</li><li>Uppercase characters.</li><li>Numbers (0-9).</li><li>Symbols (see the previous password restrictions).</li></ul></li></ul> |
 | Password expiry duration (Maximum password age) |<ul><li>Default value: **90** days.</li><li>The value is configurable by using the `Set-MsolPasswordPolicy` cmdlet from the Azure Active Directory Module for Windows PowerShell.</li></ul> |
-| Password expiry notification (When are users notified of password expiration) |<ul><li>Default value: **14** days (before password expires).</li><li>The value is configurable by using the `Set-MsolPasswordPolicy` cmdlet.</li></ul> |
-| Password expiry (Do passwords ever expire) |<ul><li>Default value: **false** days (indicates that password expiry is enabled).</li><li>The value can be configured for individual user accounts by using the `Set-MsolUser` cmdlet.</li></ul> |
+| Password expiry notification (When users are notified of password expiration) |<ul><li>Default value: **14** days (before password expires).</li><li>The value is configurable by using the `Set-MsolPasswordPolicy` cmdlet.</li></ul> |
+| Password expiry (Let password's never expire) |<ul><li>Default value: **false** (indicates that password's have an expiration date).</li><li>The value can be configured for individual user accounts by using the `Set-MsolUser` cmdlet.</li></ul> |
 | Password change history | The last password *can't* be used again when the user changes a password. |
 | Password reset history | The last password *can* be used again when the user resets a forgotten password. |
 | Account lockout | After 10 unsuccessful sign-in attempts with the wrong password, the user is locked out for one minute. Further incorrect sign-in attempts lock out the user for increasing durations of time. [Smart lockout](howto-password-smart-lockout.md) tracks the last three bad password hashes to avoid incrementing the lockout counter for the same password. If someone enters the same bad password multiple times, this behavior will not cause the account to lockout. |

articles/active-directory/develop/active-directory-certificate-credentials.md

@@ -127,6 +127,6 @@ In the Azure app registration for the client application:
 ## Code sample
 
 > [!NOTE]
-> You must calculate the X5T header by using the certificate's hash and  converting it to a base64 string. In C# it would look something similar to that of : `System.Convert.ToBase64String(cert.GetCertHash());`
+> You must calculate the X5T header by converting it to a base 64 string using the certificate's hash. The code to perform this in C# is : `System.Convert.ToBase64String(cert.GetCertHash());`
 
 The code sample on [Authenticating to Microsoft identity platform in daemon apps with certificates](https://github.com/Azure-Samples/active-directory-dotnet-daemon-certificate-credential) shows how an application uses its own credentials for authentication. It also shows how you can [create a self-signed certificate](https://github.com/Azure-Samples/active-directory-dotnet-daemon-certificate-credential#create-a-self-signed-certificate) using the `New-SelfSignedCertificate` Powershell command. You can also take advantage and use the [app creation scripts](https://github.com/Azure-Samples/active-directory-dotnet-daemon-certificate-credential/blob/master/AppCreationScripts/AppCreationScripts.md) to create the certificates, compute the thumbprint, and so on.

articles/active-directory/hybrid/reference-connect-version-history.md

@@ -34,7 +34,7 @@ While we go through this process, the version number of the release will be show
 Not all releases of Azure AD Connect will be made available for auto upgrade. The release status will indicate whether a release is made available for auto upgrade or for download only. If auto upgrade was enabled on your Azure AD Connect server then that server will automatically upgrade to the latest version of Azure AD Connect that is released for auto upgrade. Note that not all Azure AD Connect configurations are eligible for auto upgrade. Please follow this link to read more about [auto upgrade](how-to-connect-install-automatic-upgrade.md)
 
 >[!IMPORTANT]
-> Starting on November 1st, 2020, we will begin implementing a deprecation process whereby versions of Azure AD Connect that were released more than 18 months ago will be deprecated. At that time we will begin this process by deprecating all releases of Azure AD Connect with version 1.1.751.0 (which was released on 4/12/2018) and older, and we will proceed to evaluate the deprecation of older versions of Azure AD Connect every time a new version releases.
+> Starting on November 1st, 2020, we will begin implementing a deprecation process whereby versions of Azure AD Connect that were released more than 18 months ago will be deprecated. At that time we will begin this process by deprecating all releases of Azure AD Connect with version 1.3.20.0 (which was released on 4/24/2019) and older, and we will proceed to evaluate the deprecation of older versions of Azure AD Connect every time a new version releases.
 >
 > You need to make sure you are running a recent version of Azure AD Connect to receive an optimal support experience. 
 >

articles/hdinsight/hadoop/apache-ambari-troubleshoot-heartbeat-issues.md

@@ -78,6 +78,21 @@ The alerts are caused by the Ambari agent not running.
 
     If failover controller services are not running, it is likely due to a problem prevent hdinsight-agent from starting failover controller. Check hdinsight-agent log from `/var/log/hdinsight-agent/hdinsight-agent.out` file.
 
+## Scenario: Heartbeat lost for Ambari
+
+### Issue
+
+Ambari heartbeat agent was lost.
+
+### Cause
+
+OMS logs are causing high CPU utilization.
+
+### Resolution
+
+* Disable OMS logging using the [Disable-AzHDInsightOperationsManagementSuite](https://docs.microsoft.com/powershell/module/az.hdinsight/disable-azhdinsightoperationsmanagementsuite?view=azps-2.8.0) PowerShell module. 
+* Delete the `mdsd.warn` log file
+
 ---
 
 ## Next steps