add requested fixes

Author: v-kents

articles/active-directory/hybrid/how-to-connect-sso-quick-start.md

@@ -1,5 +1,5 @@
 ---
-title: 'Azure AD Connect: Seamless Single Sign-On - quick start | Microsoft Docs'
+title: 'Azure AD Connect: Seamless Single Sign-On - quickstart | Microsoft Docs'
 description: This article describes how to get started with Azure Active Directory Seamless Single Sign-On
 services: active-directory
 keywords: what is Azure AD Connect, install Active Directory, required components for Azure AD, SSO, Single Sign-on
@@ -18,7 +18,7 @@ ms.author: billmath
 ms.collection: M365-identity-device-management
 ---
 
-# Azure Active Directory Seamless Single Sign-On: Quick start
+# Azure Active Directory Seamless Single Sign-On: Quickstart
 
 ## Deploy Seamless Single Sign-On
 
@@ -187,15 +187,15 @@ If you have overridden the [AuthNegotiateDelegateAllowlist](https://docs.microso
 
 #### Microsoft Edge based on Chromium (macOS and other non-Windows platforms)
 
-For Microsoft Edge based on Chromium on Mac OS and other non-Windows platforms, refer to [the Microsoft Edge based on Chromium Policy List](https://docs.microsoft.com/DeployEdge/microsoft-edge-policies#authserverallowlist) for information on how to add the Azure AD URL for integrated authentication to your allow-list.
+For Microsoft Edge based on Chromium on macOS and other non-Windows platforms, refer to [the Microsoft Edge based on Chromium Policy List](https://docs.microsoft.com/DeployEdge/microsoft-edge-policies#authserverallowlist) for information on how to add the Azure AD URL for integrated authentication to your allow-list.
 
 #### Google Chrome (all platforms)
 
 If you have overridden the [AuthNegotiateDelegateWhitelist](https://www.chromium.org/administrators/policy-list-3#AuthNegotiateDelegateWhitelist) or the [AuthServerWhitelist](https://www.chromium.org/administrators/policy-list-3#AuthServerWhitelist) policy settings in your environment, ensure that you add Azure AD's URL (`https://autologon.microsoftazuread-sso.com`) to them as well.
 
 #### Google Chrome (macOS and other non-Windows platforms)
 
-For Google Chrome on Mac OS and other non-Windows platforms, refer to [The Chromium Project Policy List](https://dev.chromium.org/administrators/policy-list-3#AuthServerWhitelist) for information on how to whitelist the Azure AD URL for integrated authentication.
+For Google Chrome on macOS and other non-Windows platforms, refer to [The Chromium Project Policy List](https://dev.chromium.org/administrators/policy-list-3#AuthServerWhitelist) for information on how to whitelist the Azure AD URL for integrated authentication.
 
 The use of third-party Active Directory Group Policy extensions to roll out the Azure AD URL to Firefox and Google Chrome on Mac users is outside the scope of this article.
 

articles/active-directory/saas-apps/trelica-tutorial.md

@@ -128,7 +128,7 @@ In this section, you enable B.Simon to use Azure single sign-on by granting acce
 
 ## Configure Trelica SSO
 
-To configure single sign-on on the **Trelica** side, go to the [SAML identity providers configuration page](https://app.trelica.com/Admin/Profile/SAML) (Admin > Account > SAML). Click on the **New** button. Enter **Azure AD** as the Name and choose **Metadata from url** for the Metadata type. Paste the **App Fedeation Metadata Url** you took from Azure AD into the **Metadata url** field in Trelica.
+To configure single sign-on on the **Trelica** side, go to the [SAML identity providers configuration page](https://app.trelica.com/Admin/Profile/SAML) (Admin > Account > SAML). Click on the **New** button. Enter **Azure AD** as the Name and choose **Metadata from url** for the Metadata type. Paste the **App Federation Metadata Url** you took from Azure AD into the **Metadata url** field in Trelica.
 
 Read the [Trelica help documentation](https://docs.trelica.com/admin/saml/azure-ad) or contact the [Trelica Client support team](mailto:[email protected]) if you have questions.
 

articles/data-factory/concepts-pipeline-execution-triggers.md

@@ -231,7 +231,7 @@ To have your schedule trigger kick off a pipeline run, include a pipeline refere
 The following table provides a high-level overview of the major schema elements that are related to recurrence and scheduling a trigger:
 
 | JSON property | Description |
-|:--- |:--- |
+| :--- | :--- |
 | **startTime** | A date-time value. For basic schedules, the value of the **startTime** property applies to the first occurrence. For complex schedules, the trigger starts no sooner than the specified **startTime** value. |
 | **endTime** | The end date and time for the trigger. The trigger doesn't execute after the specified end date and time. The value for the property can't be in the past. <!-- This property is optional. --> |
 | **timeZone** | The time zone. Currently, only the UTC time zone is supported. |
@@ -277,7 +277,7 @@ The following table provides a high-level overview of the major schema elements
 ### Schema defaults, limits, and examples
 
 | JSON property | Type | Required | Default value | Valid values | Example |
-|:--- |:--- |:--- |:--- |:--- |:--- |
+| :--- | :--- | :--- | :--- | :--- | :--- |
 | **startTime** | string | Yes | None | ISO 8601 date-times | `"startTime" : "2013-01-09T09:30:00-08:00"` |
 | **recurrence** | object | Yes | None | A recurrence object | `"recurrence" : { "frequency" : "monthly", "interval" : 1 }` |
 | **interval** | number | No | 1 | 1 to 1000 | `"interval":10` |
@@ -288,7 +288,7 @@ The following table provides a high-level overview of the major schema elements
 The following table shows you how the **startTime** property controls a trigger run:
 
 | startTime value | Recurrence without schedule | Recurrence with schedule |
-|:--- |:--- |:--- |
+| :--- | :--- | :--- |
 | **Start time is in the past** | Calculates the first future execution time after the start time, and runs at that time.<br /><br />Runs subsequent executions calculated from the last execution time.<br /><br />See the example that follows this table. | The trigger starts _no sooner than_ the specified start time. The first occurrence is based on the schedule,  calculated from the start time.<br /><br />Runs subsequent executions based on the recurrence schedule. |
 | **Start time is in the future or the current time** | Runs once at the specified start time.<br /><br />Runs subsequent executions calculated from the last execution time. | The trigger starts _no sooner_ than the specified start time. The first occurrence is based on the schedule, calculated from the start time.<br /><br />Runs subsequent executions based on the recurrence schedule. |
 
@@ -310,7 +310,7 @@ If multiple **schedule** elements are specified, the order of evaluation is from
 The following table describes the **schedule** elements in detail:
 
 | JSON element | Description | Valid values |
-|:--- |:--- |:--- |
+| :--- | :--- | :--- |
 | **minutes** | Minutes of the hour at which the trigger runs. |- Integer<br />- Array of integers|
 | **hours** | Hours of the day at which the trigger runs. |- Integer<br />- Array of integers|
 | **weekDays** | Days of the week the trigger runs. The value can be specified only with a weekly frequency.|<br />- Monday<br />- Tuesday<br />- Wednesday<br />- Thursday<br />- Friday<br />- Saturday<br />- Sunday<br />- Array of day values (maximum array size is 7)<br /><br />Day values aren't case-sensitive|
@@ -334,7 +334,7 @@ This section provides examples of recurrence schedules. It focuses on the **sche
 The examples assume that the **interval** value is 1 and that the **frequency** value is correct according to the schedule definition. For example, you can't have a **frequency** value of "day" and also have a **monthDays** modification in the **schedule** object. These kinds of restrictions are described in the table in the preceding section.
 
 | Example | Description |
-|:--- |:--- |
+| :--- | :--- |
 | `{"hours":[5]}` | Run at 5:00 AM every day. |
 | `{"minutes":[15], "hours":[5]}` | Run at 5:15 AM every day. |
 | `{"minutes":[15], "hours":[5,17]}` | Run at 5:15 AM and 5:15 PM every day. |
@@ -371,7 +371,7 @@ The tumbling window trigger and the schedule trigger both operate on time heartb
 The following table provides a comparison of the tumbling window trigger and schedule trigger:
 
 |  | Tumbling window trigger | Schedule trigger |
-|:--- |:--- |:--- |
+| :--- | :--- | :--- |
 | **Backfill scenarios** | Supported. Pipeline runs can be scheduled for windows in the past. | Not supported. Pipeline runs can be executed only on time periods from the current time and the future. |
 | **Reliability** | 100% reliability. Pipeline runs can be scheduled for all windows from a specified start date without gaps. | Less reliable. |
 | **Retry capability** | Supported. Failed pipeline runs have a default retry policy of 0, or a policy that's specified by the user in the trigger definition. Automatically retries when the pipeline runs fail due to concurrency/server/throttling limits (that is, status codes 400: User Error, 429: Too many requests, and 500: Internal Server error). | Not supported. |

articles/data-factory/how-to-create-tumbling-window-trigger.md

@@ -18,7 +18,7 @@ ms.date: 09/11/2019
 
 This article provides steps to create, start, and monitor a tumbling window trigger. For general information about triggers and the supported types, see [Pipeline execution and triggers](concepts-pipeline-execution-triggers.md).
 
-Tumbling window triggers are a type of trigger that fires at a periodic time interval from a specified start time, while retaining state. Tumbling windows are a series of fixed-sized, non-overlapping, and contiguous time intervals. A tumbling window trigger has a one-to-one relationship with a pipeline and can only reference a singular pipeline. Tumbling window trigger is a more heavy weight alternative for schedule trigger offering a suite of features for complex scenarios([dependency on other tumbing window triggers](#tumbling-window-trigger-dependency), [reruning a failed job](tumbling-window-trigger-dependency.md#monitor-dependencies) and [set user retry for pipelines](#user-assigned-retries-of-pipelines)). To further understand the difference between schedule trigger and tumbling window trigger, please visit [here](concepts-pipeline-execution-triggers.md#trigger-type-comparison).
+Tumbling window triggers are a type of trigger that fires at a periodic time interval from a specified start time, while retaining state. Tumbling windows are a series of fixed-sized, non-overlapping, and contiguous time intervals. A tumbling window trigger has a one-to-one relationship with a pipeline and can only reference a singular pipeline. Tumbling window trigger is a more heavy weight alternative for schedule trigger offering a suite of features for complex scenarios([dependency on other tumbling window triggers](#tumbling-window-trigger-dependency), [rerunning a failed job](tumbling-window-trigger-dependency.md#monitor-dependencies) and [set user retry for pipelines](#user-assigned-retries-of-pipelines)). To further understand the difference between schedule trigger and tumbling window trigger, please visit [here](concepts-pipeline-execution-triggers.md#trigger-type-comparison).
 
 ## Data Factory UI
 
@@ -146,14 +146,14 @@ If the startTime of trigger is in the past, then based on this formula, M=(Curre
 
 ### Existing TriggerResource elements
 
-The following points apply to update of exisiting **TriggerResource** elements:
+The following points apply to update of existing **TriggerResource** elements:
 
 * The value for the **frequency** element (or window size) of the trigger along with **interval** element cannot be changed once the trigger is created. This is required for proper functioning of triggerRun reruns and dependency evaluations
 * If the value for the **endTime** element of the trigger changes (added or updated), the state of the windows that are already processed is *not* reset. The trigger honors the new **endTime** value. If the new **endTime** value is before the windows that are already executed, the trigger stops. Otherwise, the trigger stops when the new **endTime** value is encountered.
 
 ### User assigned retries of pipelines
 
-In case of pipeline failures, tumblingwindow trigger can retry the execution of the referenced pipeline automatically, using the same input parameters, without the user intervention. This can be specified using the property "retryPolicy" in the trigger definition.
+In case of pipeline failures, tumbling window trigger can retry the execution of the referenced pipeline automatically, using the same input parameters, without the user intervention. This can be specified using the property "retryPolicy" in the trigger definition.
 
 ### Tumbling window trigger dependency
 

articles/role-based-access-control/resource-provider-operations.md

@@ -7301,6 +7301,7 @@ Azure service: [Azure Monitor](../azure-monitor/index.yml)
 > | Action Type | Operation | Description |
 > | --- | --- | --- |
 > | Action | Microsoft.OperationalInsights/register/action | Register a subscription to a resource provider. |
+> | Action | microsoft.operationalinsights/register/action | Rergisters the subscription. |
 > | Action | microsoft.operationalinsights/unregister/action | Unregisters the subscription. |
 > |  | **availableservicetiers** |  |
 > | Action | microsoft.operationalinsights/availableservicetiers/read | Get the available service tiers. |