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

Author: roygara

articles/ai-studio/how-to/deploy-models-llama.md

@@ -245,7 +245,7 @@ __Body__
 {
     "prompt": "What's the distance to the moon?",
     "temperature": 0.8,
-    "max_tokens": 512,
+    "max_tokens": 512
 }
 ```
 

articles/azure-arc/servers/agent-release-notes.md

@@ -18,7 +18,11 @@ This page is updated monthly, so revisit it regularly. If you're looking for ite
 
 ## Version 1.40 - April 2024
 
-Download for [Windows](https://download.microsoft.com/download/c/c/e/cce7456c-e998-4fa1-9566-f43f4a2f6a6f/AzureConnectedMachineAgent.msi) or [Linux](manage-agent.md#installing-a-specific-version-of-the-agent)
+Download for [Windows](https://download.microsoft.com/download/2/1/0/210f77ca-e069-412b-bd94-eac02a63255d/AzureConnectedMachineAgent.msi) or [Linux](manage-agent.md#installing-a-specific-version-of-the-agent)
+
+### Known issues
+
+The first release of the 1.40 agent may impact SQL Server enabled by Azure Arc when configured with least privileges on Windows servers. The 1.40 agent was re-released to address this problem. To check if your server is affected, run `azcmagent show` and locate the agent version number. Agent version `1.40.02664.1629` has the known issue and agent `1.40.02669.1635` fixes it. Download and install the [latest version of the agent](https://aka.ms/AzureConnectedMachineAgent) to restore functionality for SQL Server enabled by Azure Arc.
 
 ### New features
 

articles/azure-monitor/agents/azure-monitor-agent-migration.md

@@ -12,12 +12,12 @@ ms.custom:
 
 # Migrate to Azure Monitor Agent from Log Analytics agent
 
-[Azure Monitor Agent (AMA)](./agents-overview.md) replaces the Log Analytics agent (also known as Microsoft Monitor Agent (MMA) and OMS) for Windows and Linux machines, in Azure and non-Azure environments, including on-premises and third-party clouds. The agent introduces a simplified, flexible method of configuring data dollection using [Data Collection Rules (DCRs)](../essentials/data-collection-rule-overview.md). This article provides guidance on how to implement a successful migration from the Log Analytics agent to Azure Monitor Agent.
+[Azure Monitor Agent (AMA)](./agents-overview.md) replaces the Log Analytics agent (also known as Microsoft Monitor Agent (MMA) and OMS) for Windows and Linux machines, in Azure and non-Azure environments, including on-premises and third-party clouds. The agent introduces a simplified, flexible method of configuring data collection using [Data Collection Rules (DCRs)](../essentials/data-collection-rule-overview.md). This article provides guidance on how to implement a successful migration from the Log Analytics agent to Azure Monitor Agent.
 
 If you're currently using the Log Analytics agent with Azure Monitor or [other supported features and services](#migrate-additional-services-and-features), start planning your migration to Azure Monitor Agent by using the information in this article. If you are using the Log Analytics Agent for SCOM, you need to [migrate to the SCOM Agent](../vm/scom-managed-instance-overview.md).
 
 The Log Analytics agent will be [retired on **August 31, 2024**](https://azure.microsoft.com/updates/were-retiring-the-log-analytics-agent-in-azure-monitor-on-31-august-2024/). You can expect the following when you use the MMA or OMS agent after this date.
-> - **Data upload**: You can still upload data. At some point when major customer have finished migrating and data volumes significantly drop, upload will be suspended. You can expect this to take at least 6 to 9 months.  You will not receive a breaking change notification of the suspension. 
+> - **Data upload**: You can still upload data. At some point when major customers have finished migrating and data volumes significantly drop, upload will be suspended. You can expect this to take at least 6 to 9 months.  You will not receive a breaking change notification of the suspension. 
 > - **Install or reinstall**: You can still install and reinstall the legacy agents. You will not be able to get support for installing or reinstalling issues.
 > - **Customer Support**: You can expect support for MMA/OMS for security issues.
 
@@ -32,7 +32,7 @@ Before you begin migrating from the Log Analytics agent to Azure Monitor Agent,
 ### Before you begin 
 
 > [!div class="checklist"]
-> - **Check the [prerequisites](./azure-monitor-agent-manage.md#prerequisites) for installing Azure Monitor Agent.**<br>To monitor non-Azure and on-premises servers, you must [install the Azure Arc agent](../../azure-arc/servers/agent-overview.md). The Arc agent makes your on-premises servers visible as to Azure as a resource it can target. You won't incur any additional cost for installing the Azure Arc agent. 
+> - **Check the [prerequisites](./azure-monitor-agent-manage.md#prerequisites) for installing Azure Monitor Agent.**<br>To monitor non-Azure and on-premises servers, you must [install the Azure Arc agent](../../azure-arc/servers/agent-overview.md). The Arc agent makes your on-premises servers visible to Azure as a resource it can target. You won't incur any additional cost for installing the Azure Arc agent. 
 > - **Understand your current needs.**<br>Use the **Workspace overview** tab of the [AMA Migration Helper](./azure-monitor-agent-migration-tools.md#using-ama-migration-helper) to see connected agents and discover solutions enabled on your Log Analytics workspaces that use legacy agents, including per-solution migration recommendations. 
 > - **Verify that Azure Monitor Agent can address all of your needs.**<br>Azure Monitor Agent is General Availablity (GA) for data collection and is used for data collection by various Azure Monitor features and other Azure services. For details, see [Supported services and features](#migrate-additional-services-and-features). 
 > - **Consider installing Azure Monitor Agent together with a legacy agent for a transition period.**<br>Run Azure Monitor Agent alongside the legacy Log Analytics agent on the same machine to continue using existing functionality during evaluation or migration. Keep in mind that running two agents on the same machine doubles resource consumption, including but not limited to CPU, memory, storage space, and network bandwidth.<br>

articles/azure-monitor/app/java-standalone-config.md

@@ -413,6 +413,23 @@ For more information, see the [Telemetry processor](./java-standalone-telemetry-
 > [!NOTE]
 > If you want to drop specific (whole) spans for controlling ingestion cost, see [Sampling overrides](./java-standalone-sampling-overrides.md).
 
+## Custom instrumentation (preview)
+
+Starting from verion 3.3.1, you can capture spans for a method in your application:
+
+```json
+{
+  "preview": {
+    "customInstrumentation": [
+      {
+        "className": "my.package.MyClass",
+        "methodName": "myMethod"
+      }
+    ]
+  }
+}
+```
+
 ## Autocollected logging
 
 Log4j, Logback, JBoss Logging, and java.util.logging are autoinstrumented. Logging performed via these logging frameworks is autocollected.

articles/azure-monitor/app/java-standalone-sampling-overrides.md

@@ -189,7 +189,8 @@ with the text "exporting span".
 
 >[!Note]
 > Only attributes set at the start of the span are available for sampling,
-so attributes such as `http.status_code` which are captured later on can't be used for sampling.
+so attributes such as `http.response.status_code` or request duration which are captured later on can be filtered through [OpenTelemetry Java extensions](https://opentelemetry.io/docs/languages/java/automatic/extensions/). Here is a [sample extension that filters spans based on request duration](https://github.com/Azure-Samples/ApplicationInsights-Java-Samples/tree/main/opentelemetry-api/java-agent/TelemetryFilteredBaseOnRequestDuration).
+
 
 ## Troubleshooting
 

articles/azure-netapp-files/cross-region-replication-create-peering.md

@@ -91,7 +91,7 @@ To authorize the replication, you need to obtain the resource ID of the replicat
 6. In the Authorize field, paste the destination replication volume resource ID that you obtained in Step 3, then select **OK**.
 
     > [!NOTE]
-    > Due to various factors, like the state of the destination storage at a given time, there’s likely a difference between the used space of the source volume and the used space of the destination volume. <!-- ANF-14038 --> 
+    > Due to various factors, such as the state of the destination storage at a given time, there’s likely a difference between the used space of the source volume and the used space of the destination volume. <!-- ANF-14038 --> 
 
 ## Next steps  
 

articles/azure-netapp-files/cross-region-replication-manage-disaster-recovery.md

@@ -1,26 +1,24 @@
 ---
-title: Manage disaster recovery using Azure NetApp Files cross-region replication | Microsoft Docs
+title: Manage disaster recovery using Azure NetApp Files 
 description: Describes how to manage disaster recovery by using Azure NetApp Files cross-region replication.
 services: azure-netapp-files
 author: b-hchen
 ms.service: azure-netapp-files
 ms.topic: how-to
 ms.date: 11/09/2022
-ms.author: anfdocs
+ms.author: anfdocs 
 ---
-# Manage disaster recovery using cross-region replication 
+# Manage disaster recovery using Azure NetApp Files 
 
-An ongoing replication between the source and the destination volumes (see [Create volume replication](cross-region-replication-create-peering.md)) prepares you for a disaster recovery event. 
+An ongoing replication (with [cross-zone](create-cross-zone-replication.md) or [cross-region replication](cross-region-replication-create-peering.md)) between the source and the destination volumes prepares you for a disaster recovery event. 
 
 When such an event occurs, you can [fail over to the destination volume](#fail-over-to-destination-volume), enabling the client to read and write to the destination volume. 
 
 After disaster recovery, you can perform a [resync](#resync-replication) operation to fail back to the source volume. You then [reestablish the source-to-destination replication](#reestablish-source-to-destination-replication) and remount the source volume for the client to access. 
 
-The details are described below. 
-
 ## Fail over to destination volume
 
-Failover is a manual process. When you need to activate the destination volume (for example, when you want to failover to the destination region), you need to break replication peering and then mount the destination volume. . 
+Failover is a manual process. When you need to activate the destination volume (for example, when you want to fail over to the destination region), you need to break replication peering then mount the destination volume.
 
 1. To break replication peering, select the destination volume. Select **Replication** under Storage Service.  
 
@@ -32,9 +30,9 @@ Failover is a manual process. When you need to activate the destination volume (
 
     See [Display health status of replication relationship](cross-region-replication-display-health-status.md). 
 
-3.	Click **Break Peering**.  
+3.	Select **Break Peering**.  
 
-4.	Type **Yes** when prompted and click the **Break** button. 
+4.	Type **Yes** when prompted and then select **Break**.
 
     ![Break replication peering](./media/shared/cross-region-replication-break-replication-peering.png)
 
@@ -53,9 +51,9 @@ After disaster recovery, you can reactivate the source volume by performing a re
 > In case the source volume did not survive the disaster and therefore no common snapshot exists, all data in the destination will be resynchronized to a newly created source volume.
 
 
-1. To reverse resync replication, select the *source* volume. Click **Replication** under Storage Service. Then click **Reverse Resync**.  
+1. To reverse resync replication, select the *source* volume. Select **Replication** under Storage Service. Then select **Reverse Resync**.  
 
-2. Type **Yes** when prompted and click **OK**. 
+2. Type **Yes** when prompted then select **OK**. 
 
     ![Resync replication](./media/cross-region-replication-manage-disaster-recovery/cross-region-replication-resync-replication.png)
 
@@ -70,7 +68,7 @@ After disaster recovery, you can reactivate the source volume by performing a re
 After the resync operation from destination to source is complete, you need to break replication peering again to reestablish source-to-destination replication. You should also remount the source volume so that the client can access it.  
 
 1. Break the replication peering:  
-    a. Select the *destination* volume. Click **Replication** under Storage Service.  
+    a. Select the *destination* volume. Select **Replication** under Storage Service.  
     b. Check the following fields before continuing:   
     * Ensure that Mirror State shows ***Mirrored***.   
     Do not attempt to break replication peering if Mirror State shows *uninitialized*.  
@@ -79,12 +77,12 @@ After the resync operation from destination to source is complete, you need to b
 
         See [Display health status of replication relationship](cross-region-replication-display-health-status.md). 
 
-    c. Click **Break Peering**.   
-    d. Type **Yes** when prompted and click the **Break** button.  
+    c. Select **Break Peering**.   
+    d. Type **Yes** when prompted then select **Break**.  
 
 2. Resync the source volume with the destination volume:  
-    a. Select the *destination* volume. Click **Replication** under Storage Service. Then click **Reverse Resync**.   
-    b. Type **Yes** when prompted and click the **OK** button.
+    a. Select the *destination* volume. Select **Replication** under Storage Service. Then select **Reverse Resync**.   
+    b. Type **Yes** when prompted then select **OK**.
 
 3. Remount the source volume by following the steps in [Mount a volume for Windows or Linux virtual machines](azure-netapp-files-mount-unmount-volumes-for-virtual-machines.md).  
     This step enables a client to access the source volume.

articles/azure-netapp-files/cross-region-replication-requirements-considerations.md

@@ -19,6 +19,8 @@ This article describes requirements and considerations about [using the volume c
 * SMB volumes are supported along with NFS volumes. Replication of SMB volumes requires an Active Directory connection in the source and destination NetApp accounts. The destination AD connection must have access to the DNS servers or AD DS Domain Controllers that are reachable from the delegated subnet in the destination region. For more information, see [Requirements for Active Directory connections](create-active-directory-connections.md#requirements-for-active-directory-connections). 
 * The destination account must be in a different region from the source volume region. You can also select an existing NetApp account in a different region.  
 * The replication destination volume is read-only until you [fail over to the destination region](cross-region-replication-manage-disaster-recovery.md#fail-over-to-destination-volume) to enable the destination volume for read and write. 
+    >[!IMPORTANT]
+    >Failover is a manual process. When you need to activate the destination volume (for example, when you want to fail over to the destination region), you need to break replication peering then mount the destination volume. For more information, see [fail over to the destination volume](cross-region-replication-manage-disaster-recovery.md#fail-over-to-destination-volume)
 * Azure NetApp Files replication doesn't currently support multiple subscriptions; all replications must be performed under a single subscription.
 * See [resource limits](azure-netapp-files-resource-limits.md) for the maximum number of cross-region replication destination volumes. You can open a support ticket to [request a limit increase](azure-netapp-files-resource-limits.md#request-limit-increase) in the default quota of replication destination volumes (per subscription in a region).
 * There can be a delay up to five minutes for the interface to reflect a newly added snapshot on the source volume.  

articles/azure-netapp-files/cross-zone-replication-requirements-considerations.md

@@ -21,6 +21,8 @@ This article describes requirements and considerations about [using the volume c
 * You can use cross-zone replication with SMB and NFS volumes. Replication of SMB volumes requires an Active Directory connection in the source and destination NetApp accounts. The destination AD connection must have access to the DNS servers or AD DS Domain Controllers that are reachable from the delegated subnet in the destination zone. For more information, see [Requirements for Active Directory connections](create-active-directory-connections.md#requirements-for-active-directory-connections). 
 * The destination account must be in a different zone from the source volume zone. You can also select an existing NetApp account in a different zone.  
 * The replication destination volume is read-only until you fail over to the destination zone to enable the destination volume for read and write. For more information about the failover process, see [fail over to the destination volume](cross-region-replication-manage-disaster-recovery.md#fail-over-to-destination-volume).
+    >[!IMPORTANT]
+    >Failover is a manual process. When you need to activate the destination volume (for example, when you want to fail over to the destination region), you need to break replication peering then mount the destination volume. For more information, see [fail over to the destination volume](cross-region-replication-manage-disaster-recovery.md#fail-over-to-destination-volume)
 * Azure NetApp Files replication doesn't currently support multiple subscriptions; all replications must be performed under a single subscription.
 * See [resource limits](azure-netapp-files-resource-limits.md) for the maximum number of cross-zone destination volumes. You can open a support ticket to [request a limit increase](azure-netapp-files-resource-limits.md#request-limit-increase) in the default quota of replication destination volumes (per subscription in a region). 
 * There can be a delay up to five minutes for the interface to reflect a newly added snapshot on the source volume.  

articles/azure-resource-manager/bicep/add-template-to-azure-pipelines.md

@@ -63,7 +63,9 @@ You can use Azure Resource Group Deployment task or Azure CLI task to deploy a B
     name: Deploy Bicep files
 
     parameters:
-      azureServiceConnection: '<your-connection-name>'
+    - name: azureServiceConnection
+      type: string
+      default: '<your-connection-name>'
 
     variables:
       vmImageName: 'ubuntu-latest'