Acrolinx fixes

Author: ktoliver

articles/app-service/app-service-configuration-references.md

@@ -45,17 +45,17 @@ This configuration applies to all references from this app.
 
 ## Grant your app access to referenced key vaults
 
-In addition to storing raw configuration values, Azure App Configuration has its own format for storing [key vault references][app-config-key-vault-references]. If the value of an App Configuration reference is a key vault reference in the App Configuration store, your app also must have permissions to access the key vault that's specified in the reference.
+In addition to storing raw configuration values, Azure App Configuration has its own format for storing [key vault references][app-config-key-vault-references]. If the value of an App Configuration reference is a key vault reference in the App Configuration store, your app also must have permissions to access the key vault that is specified in the reference.
 
 > [!NOTE]
-> The [App Configuration key vault references concept][app-config-key-vault-references] should not be confused with [the App Service and Azure Functions key vault references concept][app-service-key-vault-references]. Your app can use any combination of these references, but there are some important differences. If your vault needs to be network restricted or if you need the app to periodically update to latest versions, consider using the App Service and Azure Functions direct approach instead of using an App Configuration reference.
+> The [App Configuration key vault references concept][app-config-key-vault-references] shouldn't be confused with [the App Service and Azure Functions key vault references concept][app-service-key-vault-references]. Your app can use any combination of these references, but there are some important differences. If your vault needs to be network restricted or if you need the app to periodically update to latest versions, consider using the App Service and Azure Functions direct approach instead of using an App Configuration reference.
 
 [app-config-key-vault-references]: ../azure-app-configuration/use-key-vault-references-dotnet-core.md
 [app-service-key-vault-references]: app-service-key-vault-references.md
 
 1. Identify the identity that you used for the App Configuration reference. You must grant vault access to the same identity.
 
-1. Create an [access policy in Key Vault](/azure/key-vault/general/security-features#privileged-access) for that identity. Enable the *Get* secret permission on this policy. Do not configure the *authorized application* or the `applicationId` settings because they aren't compatible with a managed identity.
+1. Create an [access policy in Key Vault](/azure/key-vault/general/security-features#privileged-access) for that identity. Enable the *Get* secret permission on this policy. Don't configure the *authorized application* or the `applicationId` settings because they aren't compatible with a managed identity.
 
 ## Reference syntax
 
@@ -84,7 +84,7 @@ Here's an example that doesn't include `Label`:
 Any configuration change to the app that results in a site restart causes an immediate refetch of all referenced key-value pairs from the App Configuration store.
 
 > [!NOTE]
-> Automatic refresh and refetch of these values when the key-value pairs have been updated in App Configuration is currently not supported.
+> Automatic refresh and refetch of these values when the key-value pairs are updated in App Configuration currently isn't supported.
 
 ## Source application settings from App Configuration
 
@@ -102,7 +102,7 @@ Apps can use the `WEBSITE_CONTENTAZUREFILECONNECTIONSTRING` application setting
 If you use App Configuration references for this setting, this validation check fails by default because the connection itself can't be resolved while the platform processes the incoming request. To avoid this issue, you can skip the validation by setting `WEBSITE_SKIP_CONTENTSHARE_VALIDATION` to `1`. This setting bypasses all checks, and the content share isn't automatically created. You must ensure that the share is created in advance.
 
 > [!CAUTION]
-> If you skip validation and either the connection string or the content share are invalid, the app can't start properly and serves only HTTP 500 errors.
+> If you skip validation and either the connection string or the content share is invalid, the app can't start properly and serves only HTTP 500 errors.
 
 As part of creating the site, mounting the content share might fail if managed identity permissions aren't propagated or if the virtual network integration isn't set up. You can defer setting up Azure Files until later in the deployment template to accommodate for the required setup. For more information, see [Azure Resource Manager deployment](#azure-resource-manager-deployment). App Service uses only a default file system until Azure Files is set up, and files aren't copied over. Ensure that no deployment attempts occur during the interim period before Azure Files is mounted.
 
@@ -241,7 +241,7 @@ Here's a demonstration template for a function app that has App Configuration re
 
 If a reference isn't resolved properly, the reference value is used instead. For an application setting in this scenario, an environment variable that uses the syntax `@Microsoft.AppConfiguration(...)` is created. The reference might cause an error because the application was expecting a configuration value.
 
-This error most commonly is the result of a misconfiguration of the [App Configuration access policy](#grant-app-access-to-app-configuration). But it also might occur if there's a syntax error in the reference or if the configuration key-value pair does not exist in the store.
+This error most commonly is the result of a misconfiguration of the [App Configuration access policy](#grant-app-access-to-app-configuration). But it also might occur if there's a syntax error in the reference or if the configuration key-value pair doesn't exist in the store.
 
 ## Related content
 

articles/app-service/configure-authentication-oauth-tokens.md

@@ -30,7 +30,7 @@ From your server code, the provider-specific tokens are injected into the reques
 From your client code (such as a mobile app or in-browser JavaScript), send an HTTP `GET` request to `/.auth/me` ([token store](overview-authentication-authorization.md#token-store) must be enabled). The returned JSON has the provider-specific tokens.
 
 > [!NOTE]
-> Access tokens are for accessing provider resources, so they are present only if you configure your provider with a client secret. To see how to get refresh tokens, see the next section.
+> Access tokens are for accessing provider resources, so they're present only if you configure your provider with a client secret. To see how to get refresh tokens, see the next section.
 
 ## Refresh auth tokens
 
@@ -75,13 +75,13 @@ function refreshTokens() {
 }
 ```
 
-If a user revokes the permissions granted to your app, your call to `/.auth/me` may fail with a `403 Forbidden` response. To diagnose errors, check your application logs for details.
+If a user revokes the permissions granted to your app, your call to `/.auth/me` might fail with a `403 Forbidden` response. To diagnose errors, check your application logs for details.
 
 ## Extend session token expiration grace period
 
-The authenticated session expires after 8 hours. After an authenticated session expires, there is a 72-hour grace period by default. Within this grace period, you're allowed to refresh the session token with App Service without reauthenticating the user. You can just call `/.auth/refresh` when your session token becomes invalid, and you don't need to track token expiration yourself. Once the 72-hour grace period lapses, the user must sign in again to get a valid session token.
+The authenticated session expires after 8 hours. After an authenticated session expires, a 72-hour grace period follows by default. Within this grace period, you're allowed to refresh the session token with App Service without reauthenticating the user. You can just call `/.auth/refresh` when your session token becomes invalid, and you don't need to track token expiration yourself. When the 72-hour grace period lapses, the user must sign in again to get a valid session token.
 
-If 72 hours isn't enough time for you, you can extend this expiration window. Extending the expiration over a long period could have significant security implications (such as when an authentication token is leaked or stolen). So you should leave it at the default 72 hours or set the extension period to the smallest value.
+If 72 hours isn't enough time for you, you can extend this expiration window. Extending the expiration over a long period could have significant security implications (such as when an authentication token is leaked or stolen). We recommend that you leave the setting at the default 72 hours or set the extension period to the smallest value.
 
 To extend the default expiration window, run the following command in the [Cloud Shell](../cloud-shell/overview.md).
 
@@ -90,7 +90,7 @@ az webapp auth update --resource-group <group_name> --name <app_name> --token-re
 ```
 
 > [!NOTE]
-> The grace period only applies to the App Service authenticated session, not the tokens from the identity providers. There is no grace period for the expired provider tokens.
+> The grace period only applies to the App Service authenticated session, not the tokens from the identity providers. No grace period exists for expired provider tokens.
 >
 
 ## Related content

articles/app-service/overview-security.md

@@ -89,9 +89,9 @@ You can securely access on-premises resources, such as databases, in three ways:
 
 ## Application secrets
 
-Don't store application secrets like database credentials, API tokens, and private keys in your code or configuration files. The commonly accepted approach is to access them as [environment variables](https://wikipedia.org/wiki/Environment_variable) by using the standard pattern in your language of choice. In App Service, the way to define environment variables is through [app settings](configure-common.md#configure-app-settings) (and, especially for .NET applications, [connection strings](configure-common.md#configure-connection-strings)). App settings and connection strings are stored encrypted in Azure, and they're decrypted only before they are injected into your app's process memory when the app starts. The encryption keys are rotated regularly.
+Don't store application secrets like database credentials, API tokens, and private keys in your code or configuration files. The commonly accepted approach is to access them as [environment variables](https://wikipedia.org/wiki/Environment_variable) by using the standard pattern in your language of choice. In App Service, the way to define environment variables is through [app settings](configure-common.md#configure-app-settings) (and, especially for .NET applications, [connection strings](configure-common.md#configure-connection-strings)). App settings and connection strings are stored encrypted in Azure, and they're decrypted only before they're injected into your app's process memory when the app starts. The encryption keys are rotated regularly.
 
-Alternatively, you can integrate your App Service app with [Azure Key Vault](/azure/key-vault/) for advanced secrets management. By [accessing the Key Vault with a managed identity](/azure/key-vault/general/tutorial-net-create-vault-azure-web-app), your App Service app can securely access the secrets you need.
+Alternatively, you can integrate your App Service app with [Azure Key Vault](/azure/key-vault/) for advanced secrets management. By [accessing the key vault with a managed identity](/azure/key-vault/general/tutorial-net-create-vault-azure-web-app), your App Service app can securely access the secrets you need.
 
 ## Network isolation
 

articles/app-service/overview-tls.md

@@ -70,10 +70,10 @@ Azure App Service uses a secure set of TLS 1.2 cipher suites to ensure encrypted
 
 ### TLS 1.0 and TLS 1.1
 
-TLS 1.0 and 1.1 are considered **legacy protocols** and are no longer considered secure. They are supported on App Service only for backward compatibility and should be avoided when possible. The default minimum TLS version for new apps is **TLS 1.2**, and we recommend migrating apps that still use TLS 1.0 or 1.1.
+TLS 1.0 and TLS 1.1 are considered *legacy protocols* and are no longer considered secure. They are supported on App Service only for backward compatibility and should be avoided when possible. The default minimum TLS version for new apps is *TLS 1.2*, and we recommend that you migrate apps that still use TLS 1.0 or TLS 1.1.
 
 > [!IMPORTANT]
-> Incoming requests to web apps and incoming requests to Azure are treated differently. App Service will continue to support TLS 1.0 and 1.1 for incoming requests to the web apps. For incoming requests directly to the Azure control plane, for example through ARM or API calls, it's not recommended to use TLS 1.0 or 1.1.
+> Incoming requests to web apps and incoming requests to Azure are treated differently. App Service continues to support TLS 1.0 and TLS 1.1 for incoming requests to the web apps. For incoming requests made directly to the Azure control plane, for example through Azure Resource Manager or API calls, we recommend that you don't use use TLS 1.0 or TLS 1.1.
 
 ## Minimum TLS cipher suite
 
@@ -93,16 +93,16 @@ For App Service Environments (ASE) with the `FrontEndSSLCipherSuiteOrder` cluste
 - `TLS_AES_256_GCM_SHA384`
 - `TLS_AES_128_GCM_SHA256`
 
-Once you update your cluster setting, **you must restart your front-end** for the changes to take effect. Also, remember that **you must still include the two required cipher suites as mentioned in the documentation**, even when updating to support TLS 1.3. If you are already using `FrontEndSSLCipherSuiteOrder`, it is **not recommended to also enable Minimum TLS Cipher Suite for your web app**, as this could lead to conflicting configurations. **Only one** of these should be configured for managing cipher suite preferences.
+After you update your cluster setting, *you must restart your front end* for the changes to take effect. Also, remember that *you must still include the two required cipher suites as mentioned in the documentation*, even when you update to support TLS 1.3. If you already use `FrontEndSSLCipherSuiteOrder`, we *do not recommend that you also enable Minimum TLS Cipher Suite for your web app*. The result might be conflicting configurations. Configure *only one* of these options to manage cipher suite preferences.
 
 ## End-to-end TLS encryption
 
 End-to-end (E2E) TLS encryption ensures that **front-end to worker communication** within Azure App Service is encrypted using TLS. Without this feature, while incoming HTTPS requests are encrypted to the front ends, the traffic from front ends to workers running the application workloads would travel unencrypted inside Azure’s infrastructure.
 
 E2E TLS helps ensure **full encryption of traffic** between:
 
-- Clients and App Service front ends.
-- App Service front ends and worker processes hosting the application.
+- Clients and App Service front ends
+- App Service front ends and worker processes hosting the application
 
 This feature is available on:
 

articles/app-service/webjobs-sdk-how-to.md

@@ -814,7 +814,7 @@ The Azure Functions documentation provides reference information about each bind
   
 For a full list of bindings supported in Azure Functions runtime, see [Supported bindings](../azure-functions/functions-triggers-bindings.md#supported-bindings).  
 
-## Attributes for Disable, Timeout, and Singleton
+## Attributes: Disable, Timeout, and Singleton
 
 With these attributes, you can control function triggering, cancel functions, and ensure that only one instance of a function runs.
 
@@ -838,7 +838,7 @@ The attribute can be declared at the parameter, method, or class level. The sett
 
 ### Timeout attribute
 
-The [Timeout](https://github.com/Azure/azure-webjobs-sdk/blob/master/src/Microsoft.Azure.WebJobs/TimeoutAttribute.cs) attribute causes a function to be canceled if it doesn't finish within a specified amount of time. In the following example, the function would run for one day without the `Timeout` attribute. Timeout causes the function to be canceled after 15 seconds. When the `Timeout` attribute's `throwOnError` parameter is set to `true`, the function invocation is terminated by having an exception thrown by the webjobs SDK when the timeout interval is exceeded. The default value of `throwOnError` is `false`. When the `Timeout` attribute is used, the default behavior is to cancel the function invocation by setting the cancellation token while allowing the invocation to run indefinitely until the function code returns or throws an exception.
+The [Timeout](https://github.com/Azure/azure-webjobs-sdk/blob/master/src/Microsoft.Azure.WebJobs/TimeoutAttribute.cs) attribute causes a function to be canceled if it doesn't finish within a specified amount of time. In the following example, the function would run for one day without the `Timeout` attribute. Time-out causes the function to be canceled after 15 seconds. When the `Timeout` attribute `throwOnError` parameter is set to `true`, the function invocation is terminated by having an exception thrown by the webjobs SDK when the time-out interval is exceeded. The default value of `throwOnError` is `false`. When the `Timeout` attribute is used, the default behavior is to cancel the function invocation by setting the cancellation token while allowing the invocation to run indefinitely until the function code returns or throws an exception.
 
 ```csharp
 [Timeout("00:00:15")]
@@ -853,7 +853,7 @@ public static async Task TimeoutJob(
 }
 ```
 
-You can apply the `Timeout` attribute at the class or method level, and you can specify a global timeout by using `JobHostConfiguration.FunctionTimeout`. Class-level or method-level timeouts override global timeouts.
+You can apply the `Timeout` attribute at the class or method level, and you can specify a global time-out by using `JobHostConfiguration.FunctionTimeout`. Class-level or method-level time-outs override global time-outs.
 
 ### Singleton attribute
 

includes/app-service-ssl-prepare-app.md

@@ -1,10 +1,8 @@
 ---
-title: "include file"
-description: "include file"
 services: app-service
 author: cephalin
 ms.service: azure-app-service
-ms.topic: "include"
+ms.topic: include
 ms.date: 10/15/2018
 ms.author: cephalin
 ms.custom: "include file"
@@ -30,9 +28,9 @@ To create custom TLS/SSL bindings or enable client certificates for your App Ser
 
 1. On the resource menu for your web app, in the **Settings** section, select **Scale up (App Service plan)**.
 
-   ![Screenshot of web app menu, "Settings" section, and "Scale up (App Service plan)" selected.](./media/app-service-ssl-prepare-app/scale-up-menu.png)
+   ![Screenshot of the web app menu, "Settings" section, and "Scale up (App Service plan)" selected.](./media/app-service-ssl-prepare-app/scale-up-menu.png)
 
-1. Make sure that your web app isn't in the **F1** or **D1** tier, which don't support custom TLS/SSL.
+1. Make sure that your web app isn't in the **F1** or **D1** tier. These tiers don't support custom TLS/SSL.
 
 1. If you need to scale up, follow the steps in the next section. Otherwise, close the **Scale up** pane, and skip the [Scale up your App Service plan section](#scale-up-your-app-service-plan).