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

Author: KumudD

articles/active-directory/develop/msal-client-application-configuration.md

@@ -17,37 +17,37 @@ ms.date: 04/25/2019
 ms.author: ryanwi
 ms.reviewer: saeeda
 ms.custom: aaddev
-#Customer intent: As an application developer, I want to learn about the types of client application so I can decide if this platform meets my application development needs and requirements.
+#Customer intent: As an application developer, I want to learn about the types of client apps so I can decide if this platform meets my app development requirements.
 ms.collection: M365-identity-device-management
 ---
 
 # Public client and confidential client applications
-Microsoft Authentication Library (MSAL) defines two types of clients: public clients and confidential clients. The two client types are distinguished by their ability to authenticate securely with the authorization server and maintain the confidentiality of their client credentials.  In contrast, Azure AD Authentication Library (ADAL) has the concept of authentication context (which is a connection to Azure AD).
+Microsoft Authentication Library (MSAL) defines two types of clients: public clients and confidential clients. The two client types are distinguished by their ability to authenticate securely with the authorization server and maintain the confidentiality of their client credentials. In contrast, Azure AD Authentication Library (ADAL) uses what's called *authentication context* (which is a connection to Azure AD).
 
-- **Confidential client applications** are applications, which run on servers (Web Apps, Web API, or even service/daemon applications). They are considered difficult to access, and therefore capable of keeping an application secret. Confidential clients are able to hold configuration time secrets. Each instance of the client has a distinct configuration (including clientId and secret). These values are difficult for end users to extract. A web app is the most common confidential client. The client ID is exposed through the web browser, but the secret is passed only in the back channel and never directly exposed.
+- **Confidential client applications** are apps that run on servers (web apps, Web API apps, or even service/daemon apps). They're considered difficult to access, and for that reason capable of keeping an application secret. Confidential clients can hold configuration-time secrets. Each instance of the client has a distinct configuration (including client ID and client secret). These values are difficult for end users to extract. A web app is the most common confidential client. The client ID is exposed through the web browser, but the secret is passed only in the back channel and never directly exposed.
 
     Confidential client apps: <BR>
     ![Web app](media/msal-client-applications/web-app.png) ![Web API](media/msal-client-applications/web-api.png) ![Daemon/service](media/msal-client-applications/daemon-service.png)
 
-- **Public client applications** are applications, which run on devices or desktop machines or in a web browser. They are not trusted to safely keep application secrets, and therefore only access Web APIs on behalf of the user (they only support public client flows). Public clients are unable to hold configuration time secrets, and as a result have no client secret.
+- **Public client applications** are apps that run on devices or desktop computers or in a web browser. They're not trusted to safely keep application secrets, so they only access Web APIs on behalf of the user. (They support only public client flows.) Public clients can't hold configuration-time secrets, so they don't have client secrets.
 
-    Public client applications: <BR>
+    Public client apps: <BR>
     ![Desktop app](media/msal-client-applications/desktop-app.png) ![Browserless API](media/msal-client-applications/browserless-app.png) ![Mobile app](media/msal-client-applications/mobile-app.png)
 
 > [!NOTE]
-> In MSAL.js, there is no separation of public and confidential client apps.  MSAL.js represents client apps as user-agent-based apps, a public client in which the client code is executed in a user-agent such as a web browser.  These clients do not store secrets, since the browser context is openly accessible.
+> In MSAL.js, there is no separation of public and confidential client apps.  MSAL.js represents client apps as user agent-based apps, public clients in which the client code is executed in a user agent like a web browser. These clients don't store secrets because the browser context is openly accessible.
 
 ## Comparing the client types
-There are some commonalities and differences between public client and confidential client applications:
+Here are some similarities and differences between public client and confidential client apps:
 
-- Both kinds of applications maintain a user token cache and can acquire a token silently (in cases where the token is already in the token cache). Confidential client applications also have an app token cache for tokens, which are for the app itself.
-- Both manage user accounts and can get the accounts from the user token cache, get an account from its identifier, or remove an account.
-- Public client applications have four ways of acquiring a token (four authentication flows), whereas confidential client applications have three (and one method to compute the URL of the identity provider authorize endpoint). For more information, see Scenarios and Acquiring tokens.
+- Both kinds of app maintain a user token cache and can acquire a token silently (when the token is already in the token cache). Confidential client apps also have an app token cache for tokens that are for the app itself.
+- Both types of app manage user accounts and can get an account from the user token cache, get an account from its identifier, or remove an account.
+- Public client apps have four ways to acquire a token (four authentication flows). Confidential client apps have three ways to acquire a token (and one way to compute the URL of the identity provider authorize endpoint). For more information, see [Acquiring tokens](msal-acquire-cache-tokens.md).
 
-If you used ADAL in the past, you might notice that, contrary to ADAL's authentication context, in MSAL the client ID (also named application ID or app ID) is passed once at the construction of the application, and no longer needs to be repeated when acquiring a token. This is the case both for public and confidential client applications. Constructors of confidential client applications are also passed client credentials: the secret they share with the identity provider.
+If you've used ADAL, you might notice that, unlike ADAL's authentication context, in MSAL the client ID (also called the *application ID* or *app ID*) is passed once at the construction of the application. It doesn't need to be passed again when the app acquires a token. This is true for both for public and confidential client apps. Constructors of confidential client apps are also passed client credentials: the secret they share with the identity provider.
 
 ## Next steps
 Learn about:
 - [Client application configuration options](msal-client-application-configuration.md)
-- [Instantiating client applications using MSAL.NET](msal-net-initializing-client-applications.md).
-- [Instantiating client applications using MSAL.js](msal-js-initializing-client-applications.md).
+- [Instantiating client applications by using MSAL.NET](msal-net-initializing-client-applications.md)
+- [Instantiating client applications by using MSAL.js](msal-js-initializing-client-applications.md)

articles/active-directory/develop/msal-client-applications.md

@@ -1,5 +1,5 @@
 ---
-title: Configure customer containers - Azure App Service | Microsoft Docs 
+title: Configure custom container - Azure App Service | Microsoft Docs 
 description: Learn how to configure Node.js apps to work in Azure App Service
 services: app-service
 documentationcenter: ''

articles/app-service/containers/configure-custom-container.md

@@ -92,7 +92,7 @@ Diagnostics from Azure Automation creates two types of records in Azure Monitor
 | Caller_s |Who initiated the operation. Possible values are either an email address or system for scheduled jobs. |
 | Tenant_g | GUID that identifies the tenant for the Caller. |
 | JobId_g |GUID that is the Id of the runbook job. |
-| ResultType |The status of the runbook job. Possible values are:<br>- New<br>- Started<br>- Stopped<br>- Suspended<br>- Failed<br>- Completed |
+| ResultType |The status of the runbook job. Possible values are:<br>- New<br>- Created<br>- Started<br>- Stopped<br>- Suspended<br>- Failed<br>- Completed |
 | Category | Classification of the type of data. For Automation, the value is JobLogs. |
 | OperationName | Specifies the type of operation performed in Azure. For Automation, the value is Job. |
 | Resource | Name of the Automation account |

articles/automation/automation-manage-send-joblogs-log-analytics.md

@@ -13,7 +13,7 @@ ms.subservice: alerts
 
 This article shows you how to resolve common issues that might happen when you're setting up log alerts in Azure Monitor. It also provides solutions to common problems with functionality or configuration of log alerts. 
 
-The term *log alerts* describes alerts that fire based on a log query in an [Azure Log Analytics workspace](../learn/tutorial-viewdata.md) or in [Azure Application Insights](../../azure-monitor/app/analytics.md). Learn more about functionality, terminology, and types in [Log alerts in Azure Monitor](../platform/alerts-unified-log.md).
+The term *log alerts* describe rules that fire based on a log query in an [Azure Log Analytics workspace](../learn/tutorial-viewdata.md) or in [Azure Application Insights](../../azure-monitor/app/analytics.md). Learn more about functionality, terminology, and types in [Log alerts in Azure Monitor](../platform/alerts-unified-log.md).
 
 > [!NOTE]
 > This article doesn't consider cases where the Azure portal shows an alert rule triggered and a notification is not performed by an associated action group. For such cases, see the details in [Create and manage action groups in the Azure portal](../platform/action-groups.md).

articles/azure-monitor/platform/alert-log-troubleshoot.md

@@ -1,6 +1,6 @@
 ---
-title: Create, view and manage log alerts Using Azure Monitor | Microsoft Docs
-description: Use the Azure Monitor to author, view and manage log alert rules in Azure.
+title: Create, view, and manage log alerts Using Azure Monitor | Microsoft Docs
+description: Use the Azure Monitor to author, view, and manage log alert rules in Azure.
 author: msvijayn
 services: azure-monitor
 ms.service: azure-monitor
@@ -331,7 +331,7 @@ Azure Monitor - [Scheduled Query Rules API](https://docs.microsoft.com/rest/api/
 > [!NOTE]
 > Log alerts for Log Analytics can also be managed using legacy [Log Analytics Alert API](api-alerts.md) and legacy templates of [Log Analytics saved searches and alerts](../insights/solutions-resources-searches-alerts.md) as well. For more information on using the new ScheduledQueryRules API detailed here by default, see [Switch to new API for Log Analytics Alerts](alerts-log-api-switch.md).
 
-Log alerts currently do not have dedicated CLI commands currently; but as illustrated below can be used via Azure Resource Manager CLI command for sample Resource Template shown earlier (sampleScheduledQueryRule.json) in the Resource Template section :
+Log alerts currently do not have dedicated CLI commands currently; but as illustrated below can be used via Azure Resource Manager CLI command for sample Resource Template shown earlier (sampleScheduledQueryRule.json) in the Resource Template section:
 
 ```azurecli
 az group deployment create --resource-group contosoRG --template-file sampleScheduledQueryRule.json