Merge pull request #272644 from MicrosoftDocs/main

4/18 OOB publish

Author: huypub

.openpublishing.redirection.azure-monitor.json

@@ -6664,6 +6664,21 @@
             "redirect_url": "/azure/azure-monitor/monitor-azure-monitor-reference",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/azure-monitor/ai-ops/responsible-ai-faq.md",
+            "redirect_url": "/azure/copilot/overview",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/azure-monitor/ai-ops/investigator-overview.md",
+            "redirect_url": "/azure/copilot/overview",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/azure-monitor/ai-ops/investigate-alert-instance.md",
+            "redirect_url": "/azure/copilot/overview",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/azure-monitor/azure-monitor-monitoring-reference.md",
             "redirect_url": "/azure/azure-monitor/monitor-azure-monitor-reference",

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

@@ -47,13 +47,12 @@ items:
         href: how-to/deploy-models-cohere-command.md
       - name: Deploy Cohere Embed models
         href: how-to/deploy-models-cohere-embed.md
-    - name: Llama 2 family models
+    - name: Deploy Llama models
       items:
-      - name: Deploy Llama 2 family models
+      - name: Deploy Llama family models
         href: how-to/deploy-models-llama.md
       - name: Fine-tune Llama 2 family models
         href: how-to/fine-tune-model-llama.md
-        displayName: maas
     - name: Deploy Mistral family models
       href: how-to/deploy-models-mistral.md
       displayName: maas

articles/ai-studio/toc.yml

@@ -3,28 +3,28 @@ title: FAQ on V1 retirement
 titleSuffix: Azure Application Gateway
 description: This article lists out commonly added questions on  retirement of Application gateway V1 SKUs and Migration
 services: application-gateway
-author: MJyot
+author: greg-lindsay
 ms.service: application-gateway
 ms.topic: how-to
-ms.date: 04/19/2023
-ms.author: mjyothish
+ms.date: 04/18/2024
+ms.author: greglin
 ---
 # FAQs
-On April 28,2023 we announced retirement of Application gateway V1 on 28 April 2026.This article lists  the commonly asked questions on V1 retirement and V1-V2 migration.
+On April 28,2023 we announced retirement of Application gateway V1 on 28 April 2026. This article lists  the commonly asked questions on V1 retirement and V1-V2 migration.
 
 ## Common questions on V1 retirement
 
 ### What is the official date Application Gateway V1 is cut off from creation?
 
-New Customers will not be allowed to create V1 from 1 July 2023 onwards. However, any existing V1 customers can continue to create resources in existing subscriptions until August 2024 and manage V1 resources until the retirement date of 28 April 2026.
+New Customers won't be allowed to create V1 from 1 July 2023 onwards. However, any existing V1 customers can continue to create resources in existing subscriptions until August 2024 and manage V1 resources until the retirement date of 28 April 2026.
 
 ### What happens to existing Application Gateway V1 after 28 April 2026?
 
 Once the deadline arrives V1 gateways aren't supported. Any V1 SKU resources that are still active are stopped, and force deleted.
 
 ### What is the definition of a new customer on Application Gateway V1 SKU?
 
-Customers who didn't have Application Gateway V1 SKU in their subscriptions as of 4 July 2023 are considered as new customers. These customers won’t be able to create new V1 gateways in subscriptions which didn't have an existing V1 gateway as of 4 July 2023 going forward.
+Customers who didn't have Application Gateway V1 SKU in their subscriptions as of 4 July 2023 are considered as new customers. These customers aren't able to create new V1 gateways in subscriptions that didn't have an existing V1 gateway as of 4 July 2023.
 
 ### What is the definition of an existing customer on Application Gateway V1 SKU?
 
@@ -38,6 +38,10 @@ Until April 28, 2026, existing Application Gateway V1 deployments are supported.
 
 On April 28, 2026, the V1 gateways are fully retired and all active AppGateway V1s are stopped & deleted. To prevent business impact, we highly recommend starting to plan your migration at the earliest and complete it before April 28, 2026.
 
+### Does the retirement of Basic SKU Public IPs in September 2025 affect my existing V1 Application Gateways?
+
+Existing V1 Application Gateways will continue to function normally until April 2026. However, creation of new V1 Application Gateways will be disabled after August 2024. We strongly recommend that you plan and migrate your existing V1 Application Gateways to V2 as soon as possible to ensure a smooth transition.
+
 ### How do I migrate my application gateway V1 to V2 SKU?
 
 If you have an Application Gateway V1, [Migration from v1 to v2](./migrate-v1-v2.md) can be currently done in two stages:
@@ -46,43 +50,43 @@ If you have an Application Gateway V1, [Migration from v1 to v2](./migrate-v1-v2
 
 ### Can Microsoft migrate this data for me?
 
-No, Microsoft can't 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 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.
+No, Microsoft can't migrate a 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 legacy components and the gateways are deployed in many different ways in their architecture. Therefore, customer involvement is required for migration. This also allows users to plan the migration during a maintenance window. This can help to ensure that the migration is successful with minimal downtime for the user's applications.
 
 ### What is the time required for migration?
 
 Planning and execution of migration greatly depends on the complexity of the deployment and could take couple of months.
 
 ### How do I report an issue?
 
-Post your issues and questions about migration to our [Microsoft Q&A](https://aka.ms/ApplicationGatewayQA) for AppGateway, with the keyword V1Migration. We recommend posting all your questions on this forum. If you have a support contract, you're welcome to log a [support ticket](https://ms.portal.azure.com/#view/Microsoft_Azure_Support/NewSupportRequestV3Blade) as well.
+Post your issues and questions about migration to our [Microsoft Q&A](https://aka.ms/ApplicationGatewayQA) for AppGateway, with the keyword `V1Migration`. We recommend posting all your questions on this forum. If you have a support contract, you're welcome to log a [support ticket](https://ms.portal.azure.com/#view/Microsoft_Azure_Support/NewSupportRequestV3Blade) as well.
 
 ## FAQ on V1 to V2 migration
 
 ### Are there any limitations with the Azure PowerShell script to migrate the configuration from v1 to v2?
 
-Yes. See [Caveats/Limitations](./migrate-v1-v2.md#caveatslimitations).
+Yes, see [Caveats/Limitations](./migrate-v1-v2.md#caveatslimitations).
 
 ### Is this article and the Azure PowerShell script applicable for Application Gateway WAF product as well?
 
 Yes.
 
 ### Does the Azure PowerShell script also switch over the traffic from my v1 gateway to the newly created v2 gateway?
 
-No. The Azure PowerShell script only migrates the configuration. Actual traffic migration is your responsibility and in your control.
+No, the Azure PowerShell script only migrates the configuration. Actual traffic migration is your responsibility and under your control.
 
-### Is the new v2 gateway created by the Azure PowerShell script sized appropriately to handle all of the traffic that is currently served by my v1 gateway?
+### Is the new v2 gateway created by the Azure PowerShell script sized appropriately to handle all of the traffic that is served by my v1 gateway?
 
-The Azure PowerShell script creates a new v2 gateway with an appropriate size to handle the traffic on your existing v1 gateway. Auto-scaling is disabled by default, but you can enable Auto-Scaling when you run the script.
+The Azure PowerShell script creates a new v2 gateway with an appropriate size to handle the traffic on your existing v1 gateway. Autoscaling is disabled by default, but you can enable autoscaling when you run the script.
 
 ### I configured my v1 gateway  to send logs to Azure storage. Does the script replicate this configuration for v2 as well?
 
-No. The script doesn't  replicate this configuration for v2. You must add the log configuration separately to the migrated v2 gateway.
+No, the script doesn't replicate this configuration for v2. You must add the log configuration separately to the migrated v2 gateway.
 
 ### Does this script support certificate uploaded to Azure Key Vault?
 
-Yes. You can download the certificate from Keyvault and provide it as input to the migration script .
+Yes, you can download the certificate from Keyvault and provide it as input to the migration script.
 
 ### I ran into some issues with using this script. How can I get help?
 
-You can contact Azure Support under the topic "Configuration and Setup/Migrate to V2 SKU". Learn more about [Azure support here](https://azure.microsoft.com/support/options/).
+You can contact Azure Support under the topic "Configuration and Setup/Migrate to V2 SKU." Learn more about [Azure support here](https://azure.microsoft.com/support/options/).

articles/application-gateway/retirement-faq.md

@@ -34,7 +34,7 @@ As a part of this effort, you can expect the following changes to Azure Cache fo
 | Date    | Description |
 |-------- |-------------|
 | September 2023 | TLS 1.0/1.1 retirement announcement |
-| March 1, 2024 | Beginning March 1, 2024, you will not be able to set the Minimum TLS version for any cache to 1.0 or 1.1. Existing cache instances won't be updated at this point.
+| March 1, 2024 | Beginning March 1, 2024, you will not be able to create new caches with the Minimum TLS version set to 1.0 or 1.1 and you will not be able to set the Minimium TLS version to 1.0 or 1.1 for your existing cache. The Minimum TLS version won't be 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
 | November 1, 2024 | Minimum TLS version for all cache instances is updated to 1.2. This means Azure Cache for Redis instances will reject connections using TLS 1.0 or 1.1.