Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into heidist-rbac

Author: HeidiSteen

articles/active-directory/authentication/concept-authentication-methods-manage.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 01/07/2023
+ms.date: 01/10/2023
 
 ms.author: justinha
 author: justinha
@@ -106,6 +106,9 @@ Tenants are set to either Pre-migration or Migration in Progress by default, dep
 > 
 > In the future, both of these features will be integrated with the Authentication methods policy.
 
+## Known issues
+Some customers may see the control to enable Voice call grayed out due to a licensing requirement, despite having a premium license. This is a known issue that we are actively working to fix.
+
 ## Next steps
 
 - [How to migrate MFA and SSPR policy settings to the Authentication methods policy](how-to-authentication-methods-manage.md)

articles/aks/azure-ad-rbac.md

@@ -50,7 +50,7 @@ Release notes for `v2.1`:
 | Container | Tags | Retrieve image |
 |------------|:------|------------|
 | **Layout**| &bullet; `latest` </br> &bullet; `2.1`| `docker pull mcr.microsoft.com/azure-cognitive-services/form-recognizer/layout)`|
-| **Business Card** | &bullet; `latest` </br> &bullet; `2.1` |`docker pull mcr.microsoft.com/azure-cognitive-services/form-recognizer/receipt` |
+| **Business Card** | &bullet; `latest` </br> &bullet; `2.1` |`docker pull mcr.microsoft.com/azure-cognitive-services/form-recognizer/businesscard` |
 | **ID Document** | &bullet; `latest` </br> &bullet; `2.1`| `docker pull mcr.microsoft.com/azure-cognitive-services/form-recognizer/id-document`|
 | **Receipt**| &bullet; `latest` </br> &bullet; `2.1`| `docker pull mcr.microsoft.com/azure-cognitive-services/form-recognizer/receipt` |
 | **Invoice**| &bullet; `latest` </br> &bullet; `2.1`|`docker pull mcr.microsoft.com/azure-cognitive-services/form-recognizer/invoice` |

articles/applied-ai-services/form-recognizer/containers/form-recognizer-container-image-tags.md

@@ -1,19 +1,19 @@
 ---
 title: Alert schema definitions in Azure Monitor for Test Action Group
-description: Understanding the common alert schema definitions for Azure Monitor for Test Action group
+description: Understand the common alert schema definitions for Azure Monitor for the Test Action group.
 author: jacegummersall
 ms.topic: conceptual
 ms.date: 01/14/2022
 ms.revewer: jagummersall
 ---
 
-# Common alert schema definitions for Test Action Group (Preview)
+# Common alert schema definitions for Test Action Group (preview)
 
-This article describes the [common alert schema definitions](./alerts-common-schema.md) for Azure Monitor, including those for webhooks, Azure Logic Apps, Azure Functions, and Azure Automation runbooks. 
+This article describes the [common alert schema definitions](./alerts-common-schema.md) for Azure Monitor. It includes schema definitions for webhooks, Azure Logic Apps, Azure Functions, and Azure Automation runbooks.
 
 Any alert instance describes the resource that was affected and the cause of the alert. These instances are described in the common schema in the following sections:
-* **Essentials**: A set of standardized fields, common across all alert types, which describe what resource the alert is on, along with additional common alert metadata (for example, severity or description). 
-* **Alert context**: A set of fields that describes the cause of the alert, with fields that vary based on the alert type. For example, a metric alert includes fields like the metric name and metric value in the alert context, whereas an activity log alert has information about the event that generated the alert. 
+* **Essentials**: A set of standardized fields common across all alert types that describes what resource the alert is on, along with more common alert metadata like severity or description.
+* **Alert context**: A set of fields that describes the cause of the alert, with fields that vary based on the alert type. For example, a metric alert includes fields like the metric name and metric value in the alert context. An activity log alert has information about the event that generated the alert.
 
 **Sample alert payload**
 ```json
@@ -71,20 +71,20 @@ Any alert instance describes the resource that was affected and the cause of the
 
 | Field | Description|
 |:---|:---|
-| alertId | The unique resource ID identifying the alert instance. |
-| alertRule | The name of the alert rule that generated the alert instance. |
-| Severity | The severity of the alert. Possible values: Sev0, Sev1, Sev2, Sev3, or Sev4. |
-| signalType | Identifies the signal on which the alert rule was defined. Possible values: Metric, Log, or Activity Log. |
-| monitorCondition | When an alert fires, the alert's monitor condition is set to **Fired**. When the underlying condition that caused the alert to fire clears, the monitor condition is set to **Resolved**.   |
-| monitoringService | The monitoring service or solution that generated the alert. The fields for the alert context are dictated by the monitoring service. |
-| alertTargetIds | The list of the Azure Resource Manager IDs that are affected targets of an alert. For a log alert defined on a Log Analytics workspace or Application Insights instance, it's the respective workspace or application. |
-| configurationItems | The list of affected resources of an alert. The configuration items can be different from the alert targets in some cases, e.g. in metric-for-log or log alerts defined on a Log Analytics workspace, where the configuration items are the actual resources sending the telemetry, and not the workspace. This field is used by ITSM systems to correlate alerts to resources in a CMDB. |
-| originAlertId | The ID of the alert instance, as generated by the monitoring service generating it. |
-| firedDateTime | The date and time when the alert instance was fired in Coordinated Universal Time (UTC). |
-| resolvedDateTime | The date and time when the monitor condition for the alert instance is set to **Resolved** in UTC. Currently only applicable for metric alerts.|
-| description | The description, as defined in the alert rule. |
-|essentialsVersion| The version number for the essentials section.|
-|alertContextVersion | The version number for the `alertContext` section. |
+| `alertId` | The unique resource ID that identifies the alert instance. |
+| `alertRule` | The name of the alert rule that generated the alert instance. |
+| `Severity` | The severity of the alert. Possible values: `Sev0`, `Sev1`, `Sev2`, `Sev3`, or `Sev4`. |
+| `signalType` | Identifies the signal on which the alert rule was defined. Possible values: `Metric`, `Log`, or `Activity Log`. |
+| `monitorCondition` | When an alert fires, the alert's monitor condition is set to `Fired`. When the underlying condition that caused the alert to fire clears, the monitor condition is set to `Resolved`. |
+| `monitoringService` | The monitoring service or solution that generated the alert. The fields for the alert context are dictated by the monitoring service. |
+| `alertTargetIds` | The list of the Azure Resource Manager IDs that are affected targets of an alert. For a log alert defined on a Log Analytics workspace or Application Insights instance, it's the respective workspace or application. |
+| `configurationItems` | The list of affected resources of an alert. The configuration items can be different from the alert targets in some cases, for example, in metric-for-log or log alerts defined on a Log Analytics workspace. The configuration items are the actual resources that send the telemetry and not the workspace. This field is used by IT service management systems to correlate alerts to resources in a configuration management database. |
+| `originAlertId` | The ID of the alert instance, as generated by the monitoring service generating it. |
+| `firedDateTime` | The date and time when the alert instance was fired in Coordinated Universal Time (UTC). |
+| `resolvedDateTime` | The date and time when the monitor condition for the alert instance is set to `Resolved` in UTC. Currently, only applicable for metric alerts.|
+| `description` | The description, as defined in the alert rule. |
+|`essentialsVersion`| The version number for the `essentials` section.|
+|`alertContextVersion` | The version number for the `alertContext` section. |
 
 **Sample values**
 ```json
@@ -112,7 +112,7 @@ Any alert instance describes the resource that was affected and the cause of the
 
 ### Metric alerts - Static threshold
 
-#### `monitoringService` = `Platform`
+#### monitoringService = Platform
 
 **Sample values**
 ```json
@@ -180,7 +180,7 @@ Any alert instance describes the resource that was affected and the cause of the
 
 ### Metric alerts - Dynamic threshold
 
-#### `monitoringService` = `Platform`
+#### monitoringService = Platform
 
 **Sample values**
 ```json
@@ -249,9 +249,11 @@ Any alert instance describes the resource that was affected and the cause of the
 ### Log alerts
 
 > [!NOTE]
-> For log alerts that have a custom email subject and/or JSON payload defined, enabling the common schema reverts email subject and/or payload schema to the one described as follows. This means that if you want to have a custom JSON payload defined, the webhook cannot use the common alert schema. Alerts with the common schema enabled have an upper size limit of 256 KB per alert. Search results aren't embedded in the log alerts payload if they cause the alert size to cross this threshold. You can determine this by checking the flag `IncludedSearchResults`. When the search results aren't included, you should use the `LinkToFilteredSearchResultsAPI` or `LinkToSearchResultsAPI` to access query results with the [Log Analytics API](/rest/api/loganalytics/dataaccess/query/get).
+> For log alerts that have a custom email subject and/or JSON payload defined, enabling the common schema reverts email subject and/or payload schema to the one described as follows. This means that if you want to have a custom JSON payload defined, the webhook can't use the common alert schema.
 
-#### `monitoringService` = `Log Alerts V1 – Metric`
+Alerts with the common schema enabled have an upper size limit of 256 KB per alert. Search results aren't embedded in the log alerts payload if they cause the alert size to cross this threshold. To determine size, check the flag `IncludedSearchResults`. When the search results aren't included, use `LinkToFilteredSearchResultsAPI` or `LinkToSearchResultsAPI` to access query results with the [Log Analytics API](/rest/api/loganalytics/dataaccess/query/get).
+
+#### monitoringService = Log Alerts V1 – Metric
 
 **Sample values**
 ```json
@@ -342,7 +344,7 @@ Any alert instance describes the resource that was affected and the cause of the
 }
 ```
 
-#### `monitoringService` = `Log Alerts V1 - Numresults`
+#### monitoringService = Log Alerts V1 - Numresults
 
 **Sample values**
 ```json
@@ -431,10 +433,12 @@ Any alert instance describes the resource that was affected and the cause of the
 }
 ```
 
-#### `monitoringService` = `Log Alerts V2`
+#### monitoringService = Log Alerts V2
 
 > [!NOTE]
-> Log alerts rules from API version 2020-05-01 use this payload type, which only supports common schema. Search results aren't embedded in the log alerts payload when using this version. You should use [dimensions](./alerts-unified-log.md#split-by-alert-dimensions) to provide context to fired alerts. You can also use the `LinkToFilteredSearchResultsAPI` or `LinkToSearchResultsAPI` to access query results with the [Log Analytics API](/rest/api/loganalytics/dataaccess/query/get). If you must embed the results, use a logic app with the provided links the generate a custom payload.
+> Log alerts rules from API version 2020-05-01 use this payload type, which only supports common schema. Search results aren't embedded in the log alerts payload when you use this version. Use [dimensions](./alerts-unified-log.md#split-by-alert-dimensions) to provide context to fired alerts.
+
+You can also use `LinkToFilteredSearchResultsAPI` or `LinkToSearchResultsAPI` to access query results with the [Log Analytics API](/rest/api/loganalytics/dataaccess/query/get). If you must embed the results, use a logic app with the provided links to generate a custom payload.
 
 **Sample values**
 ```json
@@ -503,7 +507,7 @@ Any alert instance describes the resource that was affected and the cause of the
 
 ### Activity log alerts
 
-#### `monitoringService` = `Activity Log - Administrative`
+#### monitoringService = Activity Log - Administrative
 
 **Sample values**
 ```json
@@ -559,7 +563,7 @@ Any alert instance describes the resource that was affected and the cause of the
 }
 ```
 
-#### `monitoringService` = `ServiceHealth`
+#### monitoringService = ServiceHealth
 
 **Sample values**
 ```json
@@ -624,7 +628,7 @@ Any alert instance describes the resource that was affected and the cause of the
 }
 ```
 
-#### `monitoringService` = `Resource Health`
+#### monitoringService = Resource Health
 
 **Sample values**
 ```json
@@ -675,7 +679,7 @@ Any alert instance describes the resource that was affected and the cause of the
 }
 ```
 
-#### `monitoringService` = `Budget`
+#### monitoringService = Budget
 
 **Sample values**
 ```json
@@ -703,7 +707,7 @@ Any alert instance describes the resource that was affected and the cause of the
 }
 ```
 
-#### `monitoringService` = `Smart Alert`
+#### monitoringService = Smart Alert
 
 **Sample values**
 ```json

articles/azure-monitor/alerts/alerts-common-schema-test-action-definitions.md

@@ -428,7 +428,7 @@ You can also create an activity log alert on future events similar to an activit
 The current alert rule wizard is different from the earlier experience:
 
 - Previously, search results were included in the payload of the triggered alert and its associated notifications. The email included only 10 rows from the unfiltered results while the webhook payload contained 1,000 unfiltered results. To get detailed context information about the alert so that you can decide on the appropriate action:
-    - We recommend using [Dimensions](alerts-types.md#narrow-the-target-using-dimensions). Dimensions provide the column value that fired the alert, which gives you context for why the alert fired and how to fix the issue.
+    - We recommend using [Dimensions](alerts-types.md#narrow-the-target-by-using-dimensions). Dimensions provide the column value that fired the alert, which gives you context for why the alert fired and how to fix the issue.
     - When you need to investigate in the logs, use the link in the alert to the search results in logs.
     - If you need the raw search results or for any other advanced customizations, use Azure Logic Apps.
 - The new alert rule wizard doesn't support customization of the JSON payload.

articles/azure-monitor/alerts/alerts-create-new-alert-rule.md

@@ -22,15 +22,15 @@ In the past, users used the [legacy Log Analytics Alert API](./api-alerts.md) to
 - Single template for creation of alert rules (previously needed three separate templates).
 - Single API for all Azure resources log alerting.
 - Support for stateful (preview) and 1-minute log alerts.
-- [PowerShell cmdlets](./alerts-manage-alerts-previous-version.md#manage-log-alerts-using-powershell) and [Azure CLI](./alerts-log.md#manage-log-alerts-using-cli) support for switched rules.
+- [PowerShell cmdlets](./alerts-manage-alerts-previous-version.md#manage-log-alerts-by-using-powershell) and [Azure CLI](./alerts-log.md#manage-log-alerts-using-cli) support for switched rules.
 - Alignment of severities with all other alert types and newer rules.
 - Ability to create [cross workspace log alert](../logs/cross-workspace-query.md) that span several external resources like Log Analytics workspaces or Application Insights resources for switched rules.
 - Users can specify dimensions to split the alerts for switched rules.
 - Log alerts have extended period of up to two days of data (previously limited to one day) for switched rules.
 
 ## Impact
 
-- All switched rules must be created/edited with the current API. See [sample use via Azure Resource Template](alerts-log-create-templates.md) and [sample use via PowerShell](./alerts-manage-alerts-previous-version.md#manage-log-alerts-using-powershell).
+- All switched rules must be created/edited with the current API. See [sample use via Azure Resource Template](alerts-log-create-templates.md) and [sample use via PowerShell](./alerts-manage-alerts-previous-version.md#manage-log-alerts-by-using-powershell).
 - As rules become Azure Resource Manager tracked resources in the current API and must be unique, rules resource ID will change to this structure: `<WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>`. Display names of the alert rule will remain unchanged.
 
 ## Process
@@ -115,5 +115,5 @@ If the Log Analytics workspace wasn't switched, the response is:
 
 - Learn about the [Azure Monitor - Log Alerts](./alerts-unified-log.md).
 - Learn how to [manage your log alerts using the API](alerts-log-create-templates.md).
-- Learn how to [manage log alerts using PowerShell](./alerts-manage-alerts-previous-version.md#manage-log-alerts-using-powershell).
+- Learn how to [manage log alerts using PowerShell](./alerts-manage-alerts-previous-version.md#manage-log-alerts-by-using-powershell).
 - Learn more about the [Azure Alerts experience](./alerts-overview.md).