Merge branch 'MicrosoftDocs:main' into main

Author: v-shnarang

.openpublishing.redirection.json

@@ -2639,6 +2639,11 @@
       "redirect_url": "/azure/dns/scripts/dns-cli-create-dns-zone-record",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/dns/dns-alerts-metrics.md",
+      "redirect_url": "/azure/dns/monitor-dns",
+      "redirect_document_id": false
+    },    
     {
       "source_path_from_root": "/articles/docker/index.yml",
       "redirect_url": "/dotnet/architecture/microservices/container-docker-introduction/docker-defined",

articles/api-management/azure-openai-enable-semantic-caching.md

@@ -127,6 +127,7 @@ Configure the following policies to enable semantic caching for Azure OpenAI API
     <azure-openai-semantic-cache-lookup
         score-threshold="0.8"
         embeddings-backend-id="embeddings-deployment"
+        embeddings-backend-auth="system-assigned"
         ignore-system-messages="true"
         max-message-count="10">
         <vary-by>@(context.Subscription.Id)</vary-by>

articles/api-management/azure-openai-semantic-cache-lookup-policy.md

@@ -34,6 +34,7 @@ Use the `azure-openai-semantic-cache-lookup` policy to perform cache lookup of r
 <azure-openai-semantic-cache-lookup
     score-threshold="similarity score threshold"
     embeddings-backend-id ="backend entity ID for embeddings API"
+    embeddings-backend-auth ="system-assigned"             
     ignore-system-messages="true | false"      
     max-message-count="count" >
     <vary-by>"expression to partition caching"</vary-by>
@@ -46,6 +47,7 @@ Use the `azure-openai-semantic-cache-lookup` policy to perform cache lookup of r
 | ----------------- | ------------------------------------------------------ | -------- | ------- |
 | score-threshold	| Similarity score threshold used to determine whether to return a cached response to a prompt. Value is a decimal between 0.0 and 1.0. [Learn more](../azure-cache-for-redis/cache-tutorial-semantic-cache.md#change-the-similarity-threshold). | Yes |	N/A |
 | embeddings-backend-id | [Backend](backends.md) ID for OpenAI embeddings API call. |	Yes |	N/A |
+| embeddings-backend-auth | Authentication used for Azure OpenAI embeddings API backend. | Yes. Must be set to `system-assigned`. | N/A |
 | ignore-system-messages | Boolean. If set to `true`, removes system messages from a GPT chat completion prompt before assessing cache similarity. | No | false |
 | max-message-count | If specified, number of remaining dialog messages after which caching is skipped. | No | N/A |
                                              

articles/api-management/how-to-deploy-self-hosted-gateway-kubernetes-opentelemetry.md

@@ -15,8 +15,6 @@ ms.date: 12/17/2021
 
 This article describes the steps for deploying the self-hosted gateway component of Azure API Management to a Kubernetes cluster and automatically send all metrics to an [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/).
 
-[!INCLUDE [preview](./includes/preview/preview-callout-self-hosted-gateway-opentelemetry.md)]
-
 You learn how to:
 
 > [!div class="checklist"]
@@ -35,8 +33,6 @@ You learn how to:
 
 [OpenTelemetry](https://opentelemetry.io/) is a set of open-source tools and frameworks for logging, metrics, and tracing in a vendor-neutral way.
 
-[!INCLUDE [preview](./includes/preview/preview-callout-self-hosted-gateway-opentelemetry.md)]
-
 The self-hosted gateway can be configured to automatically collect and send metrics to an [OpenTelemetry Collector](https://opentelemetry.io/docs/concepts/components/#collector). This allows you to bring your own metrics collection and reporting solution for the self-hosted gateway.
 
 > [!NOTE]

articles/api-management/includes/preview/preview-callout-self-hosted-gateway-opentelemetry.md

@@ -34,6 +34,7 @@ Use the `llm-semantic-cache-lookup` policy to perform cache lookup of responses
 <llm-semantic-cache-lookup
     score-threshold="similarity score threshold"
     embeddings-backend-id ="backend entity ID for embeddings API"
+    embeddings-backend-auth ="system-assigned"             
     ignore-system-messages="true | false"      
     max-message-count="count" >
     <vary-by>"expression to partition caching"</vary-by>
@@ -46,6 +47,7 @@ Use the `llm-semantic-cache-lookup` policy to perform cache lookup of responses
 | ----------------- | ------------------------------------------------------ | -------- | ------- |
 | score-threshold	| Similarity score threshold used to determine whether to return a cached response to a prompt. Value is a decimal between 0.0 and 1.0. [Learn more](../azure-cache-for-redis/cache-tutorial-semantic-cache.md#change-the-similarity-threshold). | Yes |	N/A |
 | embeddings-backend-id | [Backend](backends.md) ID for OpenAI embeddings API call. |	Yes |	N/A |
+| embeddings-backend-auth | Authentication used for Azure OpenAI embeddings API backend. | Yes. Must be set to `system-assigned`. | N/A |
 | ignore-system-messages | Boolean. If set to `true`, removes system messages from a GPT chat completion prompt before assessing cache similarity. | No | false |
 | max-message-count | If specified, number of remaining dialog messages after which caching is skipped. | No | N/A |
                                              

articles/api-management/llm-semantic-cache-lookup-policy.md

@@ -157,7 +157,7 @@ Once diagnostic collection is enabled, you can create a storage account or choos
 
 ## Monitoring
 
-After providing your application's Health check path, you can monitor the health of your site using Azure Monitor. From the **Health check** blade in the portal, select **Metrics** in the top toolbar. This opens a new blade where you can see the site's health status history and create a new alert rule. Health check metrics aggregate the successful pings and display failures only when the instance was deemed unhealthy based on the Health check configuration. For more information on monitoring your sites, see [Azure App Service quotas and alerts](web-sites-monitor.md).
+After providing your application's Health check path, you can monitor the health of your site using Azure Monitor. From the **Health check** blade in the portal, select **Metrics** in the top toolbar. This opens a new blade where you can see the site's health check status history and create a new alert rule. Health check status metric aggregate the successful pings and display failures only when the instance was deemed unhealthy based on the Health Check Load balancing threshold value configured. By default this value is set to 10 minutes, so it takes 10 consecutive pings (1 per minute) for a given instance to be deemed unhealthy and only then will it be reflected on the metric. For more information on monitoring your sites, see [Azure App Service quotas and alerts](web-sites-monitor.md).
 
 ## Limitations
 

articles/app-service/monitor-instances-health-check.md

@@ -12,14 +12,12 @@ ms.custom: devx-track-azurepowershell, devx-track-azurecli
 
 # Remove TLS 1.0 and 1.1 from use with Azure Cache for Redis
 
-To meet the industry-wide push toward the exclusive use of Transport Layer Security (TLS) version 1.2 or later, Azure Cache for Redis is moving toward requiring the use of the TLS 1.2 in March 2025. TLS versions 1.0 and 1.1 are known to be susceptible to attacks such as BEAST and POODLE, and to have other Common Vulnerabilities and Exposures (CVE) weaknesses.
+To meet the industry-wide push toward the exclusive use of Transport Layer Security (TLS) version 1.2 or later, Azure Cache for Redis is moving toward requiring the use of the TLS 1.2 in April 2025. TLS versions 1.0 and 1.1 are known to be susceptible to attacks such as BEAST and POODLE, and to have other Common Vulnerabilities and Exposures (CVE) weaknesses.
 
 TLS versions 1.0 and 1.1 also don't support the modern encryption methods and cipher suites recommended by Payment Card Industry (PCI) compliance standards. This [TLS security blog](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/) explains some of these vulnerabilities in more detail.
 
 > [!IMPORTANT]
-> Starting March 1, 2025, the TLS 1.2 requirement will be enforced.
->
->
+> Starting April 1, 2025, the TLS 1.2 requirement will be enforced.
 
 > [!IMPORTANT]
 > The TLS 1.0/1.1 retirement content in this article does not apply to Azure Cache for Redis Enterprise/Enterprise Flash because the Enterprise tiers only support TLS 1.2 or newer.
@@ -34,12 +32,8 @@ As a part of this effort, you can expect the following changes to Azure Cache fo
 |--|--|
 | September 2023 | TLS 1.0/1.1 retirement announcement |
 | March 1, 2024 | Beginning March 1, 2024, you can't create new caches with the Minimum TLS version set to 1.0 or 1.1 and you can't set the _MinimumTLSVersion_ to 1.0 or 1.1 for your existing cache. The minimum TLS version aren't updated automatically for existing caches at this point. |
-| October 31, 2024 | Ensure that all your applications are connecting to Azure Cache for Redis using TLS 1.2 and Minimum TLS version on your cache settings is set to 1.2. |
-| Starting March 1, 2025 | Minimum TLS version for all cache instances is updated to 1.2. This means Azure Cache for Redis instances reject connections using TLS 1.0 or 1.1 at this point. |
-  
-  > [!IMPORTANT]
-  > The content in this article does not apply to Azure Cache for Redis Enterprise/Enterprise Flash because the Enterprise tiers only support TLS 1.2.
-  >
+| March 31, 2025 | Ensure that all your applications are connecting to Azure Cache for Redis using TLS 1.2 and Minimum TLS version on your cache settings is set to 1.2. |
+| Starting April 1, 2025 | Minimum TLS version for all cache instances is updated to 1.2. This means Azure Cache for Redis instances *reject* connections using TLS 1.0 or 1.1 at this point. |
 
 As part of this change, Azure Cache for Redis removes support for older cipher suites that aren't secure. Supported cipher suites are restricted to the following suites when the cache is configured with a minimum of TLS 1.2:
 
@@ -50,9 +44,9 @@ The following sections provide guidance about how to detect dependencies on thes
 
 ## Check TLS versions supported by your Azure Cache for Redis
 
-You can use this PowerShell script to verify the TLS versions supported by your Azure Cache for Redis endpoint. If your Redis instance is virtual network (VNet) injected, you have to run this script from a Virtual Machine in your VNet that has access to the Azure Cache for Redis endpoint.
+You can verify that **Minimum TLS version** value is set to TLS 1.2 in the [Advanced settings](cache-configure.md#advanced-settings) of your cache in the Azure portal. If it is any value other than TLS 1.2, then ensure you follow the instructions to [Configure your Azure Cache for Redis to use TLS 1.2](#configure-your-azure-cache-for-redis-to-use-tls-12). If the value is TLS 1.2, and your client application is able to connect without any errors, then no action is needed.
 
-If the result shows `Tls Enabled` and/or `Tls 11 Enabled`, then ensure you follow the instructions to [Configure your Azure Cache for Redis to use TLS 1.2](#configure-your-azure-cache-for-redis-to-use-tls-12). If the result shows only `Tls12 Enabled` and your client application is able to connect without any errors, then no action is needed.
+You can also use this PowerShell script to verify the minimum TLS version supported by your Azure Cache for Redis endpoint. If your Redis instance is virtual network (VNet) injected, you have to run this script from a Virtual Machine in your VNet that has access to the Azure Cache for Redis endpoint. If the result shows `Tls Enabled` and/or `Tls 11 Enabled`, then ensure you follow the instructions to [Configure your Azure Cache for Redis to use TLS 1.2](#configure-your-azure-cache-for-redis-to-use-tls-12). If the result shows only `Tls12 Enabled` and your client application is able to connect without any errors, then no action is needed.
 
 ```powershell
     param(
@@ -123,7 +117,7 @@ You can also do the same using PowerShell. You need the Az.RedisCache module alr
 For setting the TLS version through CLI, the `--minimum-tls-version` is available only at Redis creation time and changing `minimum-tls-version` on an existing Redis instance isn't supported.
 
 > [!NOTE]
-> The Azure Cache for Redis service should be available during the migration TLS 1.2 or later.
+> The Azure Cache for Redis service should be available during the migration to TLS 1.2 or later.
 
 ## Check whether your client application is already compliant
 

articles/azure-cache-for-redis/cache-remove-tls-10-11.md

@@ -236,7 +236,7 @@ The following list of VM attributes are supported and provide examples of config
 
 - Optional
 - The `acceleratorManufacturers` is specified as a list
-- Valid values are *AMD*, *Nvidia*, and *Xilinx*
+- Valid values are *AMD*, *NVIDIA*, and *Xilinx*
 - `acceleratorSupport` should be set to *Included* or *Required* to use this VM attribute
 - If `acceleratorSupport` is set to *Excluded*, this VM attribute can't be used
 - The default for `acceleratorManufacturers`, if not specified, is *ANY* of the valid values

articles/azure-compute-fleet/attribute-based-vm-selection.md

@@ -23,6 +23,8 @@
         href: network-attached-storage-concept.md 
       - name: Understand NAS protocols
         href: network-attached-storage-protocols.md
+      - name: Understand SMB support 
+        href: sever-message-block-support.md
       - name: Understand NAS permissions 
         items:
         - name: Understand NAS share permissions 
@@ -43,6 +45,8 @@
         href: dual-protocol-permission-behaviors.md
       - name: Understand data encryption 
         href: understand-data-encryption.md
+      - name: Understand Kerberos
+        href: kerberos.md 
       - name: Understand guidelines for Active Directory Domain Services
         href: understand-guidelines-active-directory-domain-service-site.md
       - name: Understand DNS