Merge pull request #239608 from MicrosoftDocs/main

Publish to Live Tuesday 4AM PST, 05/30

Author: PMEds28

articles/app-service/environment/how-to-migrate.md

@@ -256,7 +256,7 @@ Once you've completed all of the above steps, you can start migration. Make sure
 
 When migration is complete, you'll have an App Service Environment v3, and all of your apps will be running in your new environment. You can confirm the environment's version by checking the **Configuration** page for your App Service Environment.
 
-If your migration included a custom domain suffix, for App Service Environment v3, the custom domain will no longer be shown in the **Essentials** section of the **Overview** page of the portal as it is for App Service Environment v1/v2. Instead, for App Service Environment v3, go to the **Custom domain suffix** page where you can confirm your custom domain suffix is configured correctly. You can also remove the configuration if you no longer need it or configure one if you didn't have one previously. 
+If your migration included a custom domain suffix, the domain was shown in the **Essentials** section of the **Overview** page of the portal for App Service Environment v1/v2, but it is no longer shown there in App Service Environment v3. Instead, for App Service Environment v3, go to the **Custom domain suffix** page where you can confirm your custom domain suffix is configured correctly. You can also remove the configuration if you no longer need it or configure one if you didn't have one previously. 
 
 :::image type="content" source="./media/migration/custom-domain-suffix-app-service-environment-v3.png" alt-text="Screenshot that shows how to access custom domain suffix configuration for App Service Environment v3.":::
 

articles/application-gateway/retirement-faq.md

@@ -47,7 +47,7 @@ If you have an Application Gateway V1, [Migration from v1 to v2](./migrate-v1-v2
 ### Can Microsoft migrate this data for me?
 
 No, Microsoft cannot migrate user's data on their behalf. Users must do the migration themselves by using the self-serve options provided.
-Application Gateway v1 is built on some legacy components and customers have deployed the gateways in many different ways which makes the one click seamless migration a near impossible goal to achieve. Hence customer involvement is required for migration.
+Application Gateway v1 is built on legacy components and customers have deployed the gateways in many different ways in their architecture ,due to which customer involvement is required for migration.This also allows users to plan the migration during a maintenance window, which can help to ensure that the migration is successful with minimal downtime for the user's applications.
 
 ### What is the time required for migration?
 

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

@@ -239,23 +239,32 @@ Alerts triggered by these alert rules contain a payload that uses the [common al
 
 1. On the **Actions** tab, select or create the required [action groups](./action-groups.md).
 
-1. (Optional) If you've configured action groups for this alert rule, you can add custom properties in key:value pairs to add more information to the alert notification payload in the <a name="custom-props">**Custom properties**</a> section. Add the property **Name** and **Value** for the custom property you want included in the payload.
+
+    > [!NOTE]
+    > We're continually adding more regions for regional data processing.
+
+1. (Optional)  In the **Custom properties** section, if you've configured action groups for this alert rule, you can add custom properties in key:value pairs to the alert notification payload to add more information to it. Add the property **Name** and **Value** for the custom property you want included in the payload.
 
     You can also use custom properties to extract and manipulate data from alert payloads that use the common schema. You can use those values in the action group webhook or logic app.
 
-    The format for extracting values from the [common schema](alerts-common-schema.md), use a "$", and then the path of the common schema field inside curly brackets. For example: `${data.essentials.monitorCondition}`.
+    The format for extracting values from the common schema, use a "$", and then the path of the [common schema](https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-common-schema) field inside curly brackets. For example: `${data.essentials.monitorCondition}`.
+
+
 
     In the following examples, values in the **custom properties** are used to utilize data from the payload:
 
     **Example 1**
-    This example creates an "Additional Details" tag with data about the "evaluation window start time" and "evaluation window end time".
+
+    This example creates an "Additional Details" tag with data refarding the "window start time" and "window end time".
+
     - **Name:** "Additional Details"
     - **Value:** "Evaluation windowStartTime: \${data.alertContext.condition.windowStartTime}. windowEndTime: \${data.alertContext.condition.windowEndTime}"
     - **Result:** "AdditionalDetails:Evaluation windowStartTime: 2023-04-04T14:39:24.492Z. windowEndTime: 2023-04-04T14:44:24.492Z"
 
 
     **Example 2**
-    This example adds data about the reason the alert was fired or resolved. 
+    This example add the data regarding the reason of resolving or firing the alert. 
+
     - **Name:** "Alert \${data.essentials.monitorCondition} reason"
     - **Value:** "\${data.alertContext.condition.allOf[0].metricName} \${data.alertContext.condition.allOf[0].operator} \${data.alertContext.condition.allOf[0].threshold} \${data.essentials.monitorCondition}. The value is \${data.alertContext.condition.allOf[0].metricValue}"
     - **Result:**  Example results could be something like:
@@ -264,9 +273,11 @@ Alerts triggered by these alert rules contain a payload that uses the [common al
 
     :::image type="content" source="media/alerts-create-new-alert-rule/alerts-rule-actions-tab.png" alt-text="Screenshot that shows the Actions tab when creating a new alert rule.":::
 
+
     > [!NOTE]
     > The [common schema](alerts-common-schema.md) overwrites custom configurations. Therefore, you can't use both custom properties and the common schema for log alerts.
 
+
 1. On the **Details** tab, define the **Project details**.
     - Select the **Subscription**.
     - Select the **Resource group**.

articles/azure-monitor/alerts/alerts-log-query.md

@@ -2,7 +2,7 @@
 title: Optimize log alert queries | Microsoft Docs
 description: This article gives recommendations for writing efficient alert queries.
 ms.topic: conceptual
-ms.date: 2/23/2022
+ms.date: 5/30/2023
 ms.reviewer: yalavi
 ---
 # Optimize log alert queries
@@ -55,13 +55,13 @@ Log alert rules using [cross-resource queries](../logs/cross-workspace-query.md)
 
 ```Kusto
 union
-app('Contoso-app1').requests,
-app('Contoso-app2').requests,
-workspace('Contoso-workspace1').Perf 
+app('00000000-0000-0000-0000-000000000001').requests,
+app('00000000-0000-0000-0000-000000000002').requests,
+workspace('00000000-0000-0000-0000-000000000001').Perf 
 ```
 
 >[!NOTE]
-> [Cross-resource queries](../logs/cross-workspace-query.md) are supported in the new [scheduledQueryRules API](/rest/api/monitor/scheduledqueryrule-2021-08-01/scheduled-query-rules). If you still use the [legacy Log Analytics Alert API](./api-alerts.md) for creating log alerts, see [Upgrade legacy rules management to the current Azure Monitor Log Alerts API](/previous-versions/azure/azure-monitor/alerts/alerts-log-api-switch) to learn about switching.
+> [Cross-resource queries](../logs/cross-workspace-query.md) are supported in the new [scheduledQueryRules API](/rest/api/monitor/scheduledqueryrule-2021-08-01/scheduled-query-rules). If you still use the [legacy Log Analytics Alert API](./api-alerts.md) for creating log alerts, see [Upgrade legacy rules management to the current Azure Monitor Log Alerts API](./alerts-log-api-switch.md) to learn about switching.
 
 ## Examples
 

articles/azure-monitor/essentials/prometheus-authorization-proxy.md

@@ -1,7 +1,7 @@
 ---
 title: Azure Active Directory authorization proxy 
 description: Azure Active Directory authorization proxy 
-ms.topic: conceptual
+ms.topic: how-to
 author: EdB-MSFT
 ms.author: edbaynash
 ms.date: 07/10/2022
@@ -19,7 +19,9 @@ The Azure Active Directory authorization proxy is a reverse proxy, which can be
 > The remote write example in this article uses Prometheus remote write to write data to Azure Monitor. Onboarding your AKS cluster to Prometheus automatically installs Prometheus on your cluster and sends data to your workspace.
 ## Deployment
 
-The proxy can be deployed with custom templates using release image or as helm chart. Both deployments contain the same customizable parameters. These parameters are described in the [Parameters](#parameters) table.  
+The proxy can be deployed with custom templates using release image or as a helm chart. Both deployments contain the same customizable parameters. These parameters are described in the [Parameters](#parameters) table.  
+
+For for more information, see [Azure Active Directory authentication proxy](https://github.com/Azure/aad-auth-proxy) project.
 
 The following examples show how to deploy the proxy for remote write and for querying data from Azure Monitor.
 
@@ -110,7 +112,7 @@ Before deploying the proxy, find your managed identity and assign it the `Monito
             spec:
                 containers:
                 - name: aad-auth-proxy
-                  image: mcr.microsoft.com/azuremonitor/auth-proxy/prod/aad-auth-proxy/images/aad-auth-proxy:aad-auth-proxy-0.1.0-main-04-11-2023-623473b0
+                  image: mcr.microsoft.com/azuremonitor/auth-proxy/prod/aad-auth-proxy/images/aad-auth-proxy:0.1.0-main-05-24-2023-b911fe1c
                   imagePullPolicy: Always
                   ports:
                   - name: auth-port
@@ -171,7 +173,7 @@ Before deploying the proxy, find your managed identity and assign it the `Monito
 
     ```bash 
     helm install aad-auth-proxy oci://mcr.microsoft.com/azuremonitor/auth-proxy/prod/aad-auth-proxy/helmchart/aad-auth-proxy \
-    --version 0.1.0 \
+    --version 0.1.0-main-05-24-2023-b911fe1c \
     -n observability \
     --set targetHost=https://proxy-test-abc123.eastus-1.metrics.ingest.monitor.azure.com \
     --set identityType=userAssigned \
@@ -191,11 +193,14 @@ Before deploying the proxy, find your managed identity and assign it the `Monito
         ## https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write
         ##
         remoteWrite:
-        - url: "http://azuremonitor-ingestion.observability.svc.cluster.local/dataCollectionRules/dcr-abc123d987e654f3210abc1def234567/streams/    Microsoft-PrometheusMetrics/api/v1/write?api-version=2021-11-01-preview" 
+        - url: "http://azuremonitor-ingestion.observability.svc.cluster.local/dataCollectionRules/dcr-abc123d987e654f3210abc1def234567/streams/Microsoft-PrometheusMetrics/api/v1/write?api-version=2021-11-01-preview" 
     ```
 
 1. Apply the remote write configuration.
 
+> [!NOTE]
+> For the latest proxy image version ,see the [release notes](https://github.com/Azure/aad-auth-proxy/blob/main/RELEASENOTES.md)
+
 ###  Check that the proxy is ingesting data
 
 Check that the proxy is successfully ingesting metrics by checking the pod's logs, or by querying the Azure Monitor workspace.

articles/azure-monitor/logs/cross-workspace-query.md

@@ -4,7 +4,7 @@ description: This article describes how you can query against resources from mul
 ms.topic: conceptual
 author: bwren
 ms.author: bwren
-ms.date: 04/01/2023
+ms.date: 05/30/2023
 
 ---
 
@@ -24,22 +24,22 @@ There are two methods to query data that's stored in multiple workspaces and app
 
 ## Cross-resource query limits
 
-* The number of Application Insights resources and Log Analytics workspaces that you can include in a single query is limited to 100.
-* Cross-resource queries in log alerts are only supported in the current [scheduledQueryRules API](/rest/api/monitor/scheduledqueryrule-2018-04-16/scheduled-query-rules). If you're using the legacy Log Analytics Alerts API, you'll need to [switch to the current API](/previous-versions/azure/azure-monitor/alerts/alerts-log-api-switch).
+* The number of Application Insights components and Log Analytics workspaces that you can include in a single query is limited to 100.
+* Cross-resource queries in log alerts are only supported in the current [scheduledQueryRules API](/rest/api/monitor/scheduledqueryrule-2018-04-16/scheduled-query-rules). If you're using the legacy Log Analytics Alerts API, you'll need to [switch to the current API](../alerts/alerts-log-api-switch.md).
 * References to a cross resource, such as another workspace, should be explicit and can't be parameterized. See [Identify workspace resources](#identify-workspace-resources) for examples.
 
 ## Query across Log Analytics workspaces and from Application Insights
 To reference another workspace in your query, use the [workspace](../logs/workspace-expression.md) identifier. For an app from Application Insights, use the [app](./app-expression.md) identifier.
 
 ### Identify workspace resources
 
-You can identify a workspace in one of several ways:
+You can identify a workspace using one of these IDs:
 
 * **Workspace ID**: A workspace ID is the unique, immutable, identifier assigned to each workspace represented as a globally unique identifier (GUID).
 
     `workspace("00000000-0000-0000-0000-000000000000").Update | count`
 
-* **Azure Resource ID**: This ID is the Azure-defined unique identity of the workspace. You use the Resource ID when the resource name is ambiguous. For workspaces, the format is */subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/workspaces/workspaceName*.
+* **Azure Resource ID**: This ID is the Azure-defined unique identity of the workspace. For workspaces, the format is */subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/workspaces/workspaceName*.
 
     For example:
 
@@ -50,13 +50,13 @@ You can identify a workspace in one of several ways:
 ### Identify an application
 The following examples return a summarized count of requests made against an app named *fabrikamapp* in Application Insights.
 
-You can identify an application in Application Insights with the `app(Identifier)` expression. The `Identifier` argument specifies the app by using one of the following IDs:
+You can identify an app using one of these IDs:
 
 * **ID**: This ID is the app GUID of the application.
 
     `app("00000000-0000-0000-0000-000000000000").requests | count`
 
-* **Azure Resource ID**: This ID is the Azure-defined unique identity of the app. You use the resource ID when the resource name is ambiguous. The format is */subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/components/componentName*.
+* **Azure Resource ID**: This ID is the Azure-defined unique identity of the app. The format is */subscriptions/subscriptionId/resourcegroups/resourceGroup/providers/microsoft.OperationalInsights/components/componentName*.
 
     For example:
 
@@ -67,24 +67,25 @@ You can identify an application in Application Insights with the `app(Identifier
 ### Perform a query across multiple resources
 You can query multiple resources from any of your resource instances. These resources can be workspaces and apps combined.
 
-Example for a query across two workspaces:
+Example for a query across three workspaces:
 
 ```
 union 
   Update, 
-  workspace("").Update, workspace("00000000-0000-0000-0000-000000000000").Update
+  workspace("00000000-0000-0000-0000-000000000001").Update, 
+  workspace("00000000-0000-0000-0000-000000000002").Update
 | where TimeGenerated >= ago(1h)
 | where UpdateState == "Needed"
 | summarize dcount(Computer) by Classification
 ```
 
 ## Use a cross-resource query for multiple resources
-When you use cross-resource queries to correlate data from multiple Log Analytics workspaces and Application Insights resources, the query can become complex and difficult to maintain. You should make use of [functions in Azure Monitor log queries](./functions.md) to separate the query logic from the scoping of the query resources. This method simplifies the query structure. The following example demonstrates how you can monitor multiple Application Insights resources and visualize the count of failed requests by application name.
+When you use cross-resource queries to correlate data from multiple Log Analytics workspaces and Application Insights components, the query can become complex and difficult to maintain. You should make use of [functions in Azure Monitor log queries](./functions.md) to separate the query logic from the scoping of the query resources. This method simplifies the query structure. The following example demonstrates how you can monitor multiple Application Insights components and visualize the count of failed requests by application name.
 
-Create a query like the following example that references the scope of Application Insights resources. The `withsource= SourceApp` command adds a column that designates the application name that sent the log. [Save the query as a function](./functions.md#create-a-function) with the alias `applicationsScoping`.
+Create a query like the following example that references the scope of Application Insights components. The `withsource= SourceApp` command adds a column that designates the application name that sent the log. [Save the query as a function](./functions.md#create-a-function) with the alias `applicationsScoping`.
 
 ```Kusto
-// crossResource function that scopes my Application Insights resources
+// crossResource function that scopes my Application Insights components
 union withsource= SourceApp
 app('00000000-0000-0000-0000-000000000000').requests, 
 app('00000000-0000-0000-0000-000000000001').requests,

articles/azure-monitor/logs/logs-dedicated-clusters.md

@@ -205,7 +205,10 @@ The managed identity service generates the *principalId* GUID when you create th
 
 ## Link a workspace to a cluster
 
-When a Log Analytics workspace is linked to a dedicated cluster, new data ingested to the workspace, is routed to the cluster while existing data remains in the existing Log Analytics cluster. If the dedicated cluster is configured with customer-managed keys (CMK), new ingested data is encrypted with your key. The system abstracts the data location, you can query data as usual while the system performs cross-cluster queries in the background.
+When a Log Analytics workspace is linked to a dedicated cluster, the workspace billing plan in workspace is changed per cluster plan, new data ingested to the workspace is routed to the cluster, and existing data remains in Log Analytics cluster. Linking a workspace has no affect on data ingestion and query experiences.
+
+Queries and experiences aren't affected by the  
+If the dedicated cluster is configured with customer-managed keys (CMK), new ingested data is encrypted with your key. The system abstracts the data location, you can query data as usual while the system performs cross-cluster queries in the background.
 
 A cluster can be linked to up to 1,000 workspaces. Linked workspaces can be located in the same region as the cluster. A workspace can't be linked to a cluster more than twice a month, to prevent data fragmentation.
 
@@ -544,7 +547,7 @@ Content-type: application/json
 
 ### Unlink a workspace from cluster
 
-You can unlink a workspace from a cluster at any time. The workspace pricing tier is changed to per-GB, data ingested to cluster before the unlink operation remains in the cluster, and new data to workspace get ingested to Log Analytics. 
+You can unlink a workspace from a cluster at any time. The workspace pricing tier is changed to per-GB, data ingested to cluster before the unlink operation remains in the cluster, and new data to workspace get ingested to Log Analytics.
 
 > [!WARNING]
 > Unlinking a workspace does not move workspace data out of the cluster. Any data collected for workspace while linked to cluster, remains in cluster for the retention period defined in workspace, and accessible as long as cluster isn't deleted.