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

Author: gitName

articles/api-management/enable-availability-zone-support.md

@@ -37,7 +37,7 @@ When you create a new API Management instance in the **Premium** tier in a regio
 - **Manual:** API Management provides manual availability zone support when you explicitly specify which availability zones to use.
 
 > [!IMPORTANT]
-> To ensure the reliability of your API Management instance, we recommend that you use the automatic availability zone support. To achieve maximum zone redundancy, we recommend that you deploy a minimum of three units in each region where you deploy your API Management instances. For more information, see [Reliability in API Management](../reliability/reliability-api-management.md).
+> To ensure the reliability of your API Management instance, we recommend that you use the automatic availability zone support. To achieve maximum zone redundancy, we recommend that you deploy a minimum of two units in each region where you deploy API Management to ensure that an availability zone outage doesn't affect your instance. For more information, see [Reliability in API Management](../reliability/reliability-api-management.md).
 
 ## Manual availability zone support
 

articles/app-service/configure-authentication-provider-aad.md

@@ -23,7 +23,7 @@ This article shows you how to configure authentication for Azure App Service or
 
 Before your application can sign in users, you need to register it in a workforce tenant or an external tenant. If you're making your app available to employee or business guests, register your app in a workforce tenant. If your app is for consumers and business customers, register it in an external tenant.
 
-1. Sign in to the [Azure portal] and go to your app.
+1. Sign in to the [Azure portal] and go to your App Service app or Functions app.
 
 1. On your app's left menu, select **Settings** > **Authentication**, and then select **Add identity provider**.
 

articles/app-service/overview-vnet-integration.md

@@ -3,7 +3,7 @@ title: Integrate your app with an Azure virtual network
 description: Integrate your app in Azure App Service with Azure virtual networks.
 author: seligj95
 ms.topic: conceptual
-ms.date: 08/11/2025
+ms.date: 09/03/2025
 ms.update-cycle: 1095-days
 ms.author: jordanselig
 ms.custom:
@@ -110,7 +110,7 @@ You must have at least the following Role-based access control permissions on th
 |-|-|
 | Microsoft.Network/virtualNetworks/read | Read the virtual network definition |
 | Microsoft.Network/virtualNetworks/subnets/read | Read a virtual network subnet definition |
-| Microsoft.Network/virtualNetworks/subnets/write | Delegate the subnet. Only required when the subnet has not been delegated or has not already been used for virtual network integration |
+| Microsoft.Network/virtualNetworks/subnets/write | Delegate the subnet. Only required when the subnet hasn't been delegated or hasn't already been used for virtual network integration |
 | Microsoft.Network/virtualNetworks/subnets/join/action | Joins a virtual network |
 
 If the virtual network is in a different subscription than the app, you must ensure that the subscription with the virtual network is registered for the `Microsoft.Web` resource provider. You can explicitly register the provider [by following this documentation](../azure-resource-manager/management/resource-providers-and-types.md#register-resource-provider), but it also automatically registers when creating the first web app in a subscription.
@@ -131,7 +131,7 @@ Application routing applies to traffic that is sent from your app after it start
 Learn [how to configure application routing](./configure-vnet-integration-routing.md#configure-application-routing).
 
 > [!NOTE]
-> Outbound SMTP connectivity (port 25) is supported for App Service when the SMTP traffic is routed through the virtual network integration. The supportability is determined by a setting on the subscription where the virtual network is deployed. For virtual networks/subnets created before 1. August 2022 you need to initiate a temporary configuration change to the virtual network/subnet for the setting to be synchronized from the subscription. An example could be to add a temporary subnet, associate/dissociate an NSG temporarily or configure a service endpoint temporarily. For more information, see [Troubleshoot outbound SMTP connectivity problems in Azure](../virtual-network/troubleshoot-outbound-smtp-connectivity.md).
+> Outbound SMTP connectivity (port 25) is supported for App Service when the SMTP traffic is routed through the virtual network integration. The supportability is determined by a setting on the subscription where the virtual network is deployed. For virtual networks/subnets created before 1. August 2022 you need to initiate a temporary configuration change to the virtual network/subnet for the setting to be synchronized from the subscription. An example could be to add a temporary subnet, associate/dissociate an NSG temporarily, or configure a service endpoint temporarily. For more information, see [Troubleshoot outbound SMTP connectivity problems in Azure](../virtual-network/troubleshoot-outbound-smtp-connectivity.md).
 
 ### Configuration routing
 
@@ -181,7 +181,7 @@ Specifically for [Linux continuous deployment](https://github.com/microsoft/Oryx
 
 #### Health checks
 
-Azure uses UDP port 30,000 to do network health checks. If you block this traffic, it will not directly impact your app, but it will be more difficult for Azure support to detect and troubleshoot network related issues.
+Azure uses UDP port 30,000 to do network health checks. If you block this traffic, it doesn't directly affect your app, but it's more difficult for Azure support to detect and troubleshoot network related issues.
 
 #### Private ports
 
@@ -221,7 +221,7 @@ There are some limitations with using virtual network integration:
 * You can't have more than two virtual network integrations per App Service plan. Multiple apps in the same App Service plan can use the same virtual network integration.
 * You can't change the subscription of an app or a plan while there's an app that's using virtual network integration.
 * App Service Logs to private storage accounts is currently not supported. We recommend using Diagnostics Logging and allowing Trusted Services for the storage account.
-* Connectivity to public Azure Storage accounts might fail for VNet-integrated apps when VNet Route All is enabled and the app does not use service endpoints, private endpoints, or User-Defined Routes (UDRs). Traffic is expected to route via the default route (Internet). This scenario is common when the storage account is in a different region than the virtual network.
+* Connectivity to global Azure Storage accounts might fail for VNet-integrated apps when virtual network Route All is enabled and the app doesn't use service endpoints, private endpoints, or User-Defined Routes (UDRs). Traffic is expected to route via the default route (Internet). This scenario is common when the storage account is in a different region than the virtual network.
   * To restore or ensure connectivity, enable service endpoints for the storage account, configure private endpoints, or move the storage account to the same region as the virtual network. 
 
 ## Access on-premises resources
@@ -241,7 +241,7 @@ In the app view of your virtual network integration instance, you can disconnect
 The private IP assigned to the instance is exposed via the environment variable WEBSITE_PRIVATE_IP. Kudu console UI also shows the list of environment variables available to the web app. This IP is assigned from the address range of the integrated subnet. This IP is used by the web app to connect to the resources through the Azure virtual network.
 
 > [!NOTE]
-> The value of WEBSITE_PRIVATE_IP is bound to change. However, it will be an IP within the address range of the integration subnet, so you'll need to allow access from the entire address range.
+> The value of WEBSITE_PRIVATE_IP is bound to change. However, it's an IP within the address range of the integration subnet, so you need to allow access from the entire address range.
 >
 
 ## Pricing details
@@ -254,13 +254,35 @@ The feature is easy to set up, but that doesn't mean your experience is problem
 
 > [!NOTE]
 > * Virtual network integration isn't supported for Docker Compose scenarios in App Service.
-> * Access restrictions does not apply to traffic coming through a private endpoint.
+> * Access restrictions don't apply to traffic coming through a private endpoint.
 
-### Deleting the App Service plan or app before disconnecting the network integration
+### Cleaning up orphaned Service Association Links (SAL)
 
-If you deleted the app or the App Service plan without disconnecting the virtual network integration first, you aren't able to do any update/delete operations on the virtual network or subnet that was used for the integration with the deleted resource. A subnet delegation 'Microsoft.Web/serverFarms' remains assigned to your subnet and prevents the update and delete operations. 
+When an App Service is integrated with a virtual network, a Service Association Link (SAL) is created. If the App Service is deleted without properly disconnecting the virtual network, the SAL might remain orphaned, preventing subnet deletion or updates.
+
+#### Method 1: Purging orphaned Service Association Links (SAL)
+
+First, try to delete the orphan SAL using the following Azure CLI command. Replace the placeholders for `SUBSCRIPTION-ID`, `LOCATION`, and `SUBNET-RESOURCE-ID`. The location in the URI must match the location of the virtual network/subnet. You must have at a minimum the permissions associated with the [Network Contributor](../role-based-access-control/built-in-roles/networking.md#network-contributor) role on the subnet to execute this command.
+
+```bash
+az rest --method POST \
+  --uri "/subscriptions/<SUBSCRIPTION-ID>/providers/Microsoft.Web/locations/<LOCATION>/purgeUnusedVirtualNetworkIntegration?api-version=2024-04-01" \
+  --body "{'subnetResourceId': '<SUBNET-RESOURCE-ID>'}"
+```
+
+Successful execution of this command gives the following response:
+
+```bash
+{
+  "message": "Purged unused virtual network integration.",
+  "swiftVirtualNetwork": null
+}
+```
+
+#### Method 2: Re-creating and disconnecting the integration (if Method 1 fails)
+
+If the purge command doesn't resolve the issue and you still can't perform update/delete operations on the virtual network or subnet, a subnet delegation 'Microsoft.Web/serverFarms' might remain assigned to your subnet. In this case, you need to re-create the virtual network integration and then disconnect it:
 
-In order to do update/delete the subnet or virtual network again, you need to re-create the virtual network integration, and then disconnect it:
 1. Re-create the App Service plan and app (it's mandatory to use the exact same web app name as before).
 1. Navigate to **Networking** on the app in Azure portal and configure the virtual network integration. 
 1. After the virtual network integration is configured, select the 'Disconnect' button.

articles/application-gateway/application-gateway-tls-version-retirement.md

@@ -5,7 +5,7 @@ services: application gateway
 author: jaesoni
 ms.service: azure-application-gateway
 ms.topic: concept-article
-ms.date: 07/31/2025
+ms.date: 09/04/2025
 ms.author: mbender
 ms.custom:
   - build-2025
@@ -113,14 +113,16 @@ Once support for TLS versions 1.0 and 1.1 is discontinued, clients may encounter
 A default TLS policy for Application Gateway is a packaged set of supported TLS versions and cipher suites. This allows customers to begin using secured traffic by only configuring HTTPS or TLS listeners and backend settings, without any extra configuration for TLS version or ciphers. Application Gateway uses one of its predefined policies as the default.
 
 ### How will the default TLS policies be impacted after legacy TLS versions 1.0 and 1.1 retirement?
-Until September 2025, V2 SKUs utilize two [default TLS policies](application-gateway-ssl-policy-overview.md#default-tls-policy) based on the API version specified during resource deployment. Deployments using API version **2023-02-01 or later** apply `AppGwSslPolicy20220101` by default, while earlier API versions use `AppGwSslPolicy20150501`. With the deprecation of TLS 1.0 and 1.1, the older `AppGwSslPolicy20150501` policy, will be discontinued. So, `AppGwSslPolicy20220101` will become the default policy for all V2 gateways.
+Until September 2025, V2 SKUs utilize two [default TLS policies](application-gateway-ssl-policy-overview.md#default-tls-policy) based on the API version specified during resource deployment. Deployments using API version **2023-02-01 or later** apply `AppGwSslPolicy20220101` by default, while earlier API versions use `AppGwSslPolicy20150501`. 
+
+With the deprecation of TLS 1.0 and 1.1, the older `AppGwSslPolicy20150501` policy, will be discontinued. So, `AppGwSslPolicy20220101` will become the default policy for all V2 gateways. Once this change in default policy is implemented, a subsequent PUT operation will complete the configuration update. 
 
 The default policy for the V1 SKU will remain unchanged since `AppGwSslPolicy20220101` won't be introduced for this retiring SKU.
 
 > [!NOTE]
-> A default TLS policy is applied only when the "Default" option is selected in the Portal or when no TLS policy is specified within the resource configuration by means such as REST, PowerShell, or AzCLI.
+> * A default TLS policy is applied only when the "Default" option is selected in the Portal or when no TLS policy is specified within the resource configuration by means such as REST, PowerShell, or AzCLI. Accordingly, using a default policy in configuration isn't same as explicitly selecting `AppGwSslPolicy20150501` policy, even if `AppGwSslPolicy20150501` is the default policy for your API version.
 > 
-> Accordingly, using a default policy in configuration isn't same as explicitly selecting `AppGwSslPolicy20150501` policy, even if `AppGwSslPolicy20150501` is the default policy for your API version.
+> * The changes will be applied gradually across all Azure regions.
 
 ### Which TLS policies in Application Gateway are getting deprecated?
 The predefined policies `AppGwSslPolicy20150501` and `AppGwSslPolicy20170401` that support TLS versions 1.0 and 1.1 will be removed from the Azure Resource Manager configuration. Similarly, the Custom policy will stop supporting TLS versions 1.0 and 1.1 along with their associated cipher suites. This applies to both V1 and V2 SKUs.
@@ -134,7 +136,7 @@ If you have chosen any deprecating TLS policy in the configuration of your gatew
 A nonfunctional TLS configuration, such a SSLProfile not linked to any listener, won't have any impact on the control plane of the gateway.
 
 ### How is the release for this change planned?
-Given the scale of our fleet, after 30 August 2025, the deprecation of TLS versions will be implemented separately for the Data and Control Planes (in that order). Any region-specific details won't be available; therefore, we strongly advise you to take all necessary actions before this retirement date.
+Given the scale of our fleet, after 30 August 2025, the deprecation of TLS versions will be implemented separately for the Control and Data planes. Any region-specific details won't be available; therefore, we strongly advise you to take all necessary actions at the earliest.
 
 ### Is there any potential impact if I haven’t selected any TLS policy and my gateway uses only HTTP/TCP configurations?
 If your gateway doesn't use any TLS configuration—either through SSLPolicy, SSLProfile, HTTPS, or TLS Listeners—there will be no impact after August 2025.

articles/azure-maps/migrate-help-using-copilot.md

@@ -90,7 +90,7 @@ The second tip for using GitHub Copilot is to provide detailed, step-by-step ins
 <blockquote>
 Write an HTML program using Azure Maps Web SDK v3 to make a geocode request for the coordinates of '1 Microsoft Way, Redmond, WA' and then place a marker at that location.
 
-Step 1. Utilize the Geocode API endpoint: <https://atlas.microsoft.com/geocode?api-version=2023-06-01&subscription-key=${subscriptionKey}&query=${query}>. An example response is provided for reference.
+Step 1. Utilize the Geocode API endpoint: `<https://atlas.microsoft.com/geocode?api-version=2023-06-01&subscription-key=${subscriptionKey}&query=${query}>`. An example response is provided for reference.
 
 {"type":"FeatureCollection","features":[{"type":"Feature","properties":{"address":{"countryRegion":{"name":"United States"},"adminDistricts":[{"shortName":"WA"},{"shortName":"King County"}],"formattedAddress":"15127 NE 24th St, Redmond, WA 98052","locality":"Redmond","postalCode":"98052","addressLine":"15127 NE 24th St"},"type":"Address","confidence":"High","matchCodes":["Good"],"geocodePoints":[{"geometry":{"type":"Point","coordinates":[-122.138681,47.630358]},"calculationMethod":"Rooftop","usageTypes":["Display"]},{"geometry":{"type":"Point","coordinates":[-122.1386787,47.6302179]},"calculationMethod":"Rooftop","usageTypes":["Route"]}]},"geometry":{"type":"Point","coordinates":[-122.138681,47.630358]},"bbox":[-122.14632282407,47.626495282429325,-122.13103917593001,47.63422071757068]}]}
 
@@ -208,7 +208,7 @@ Step 6. Create and add a SymbolLayer to the map.
 
 Step 7. Create and add a LineLayer to the map.
 
-Step 8. Utilize the Route POST API: <https://atlas.microsoft.com/route/directions?api-version=2025-01-01&subscription-key=${subscriptionKey}> to find the route between the start and end points. Add the GeoJSON response to the DataSource and adjust the map's camera based on the bounding box of the response.
+Step 8. Utilize the Route POST API: `https://atlas.microsoft.com/route/directions?api-version=2025-01-01&subscription-key=${subscriptionKey}` to find the route between the start and end points. Add the GeoJSON response to the DataSource and adjust the map's camera based on the bounding box of the response.
 
 Example request body:
 

articles/azure-netapp-files/TOC.yml

@@ -79,6 +79,8 @@
       href: azure-netapp-files-network-topologies.md
     - name: Resource limits for Azure NetApp Files
       href: azure-netapp-files-resource-limits.md
+    - name: Migrating data into Azure NetApp Files
+      href: migrate-data.md
     - name: Understand large volumes 
       href: large-volumes.md
     - name: Requirements and considerations for large volumes
@@ -327,6 +329,8 @@
       items:
       - name: Create a dual-protocol volume 
         href: create-volumes-dual-protocol.md
+    - name: Migrate volumes to Azure NetApp Files
+      href: migrate-volumes.md
     - name: Manage volume access and encryption 
       items:
       - name: Configure export policy for NFS or dual protocol

articles/azure-netapp-files/application-volume-group-concept.md

@@ -56,7 +56,7 @@ Volume placement within the application volume group enables administrators to e
 
 #### Data locality and latency optimization
 
-Volume placement within the application volume group allows you to optimize data locality and minimize latency for applications with stringent performance requirements. By deploying volumes closer to compute resources, administrators can reduce data access latency and improve application responsiveness particularly for latency-sensitive workloads such as database applications.
+Optimizing data locality and minimizing latency for applications with stringent performance requirements can be achieved through volume placement using application volume group. By deploying volumes using application volume group rather than individually, you can significantly reduce data access latency and enhance application responsiveness. This approach is particularly beneficial for latency-sensitive workloads, such as database applications.
 
 #### Cost optimization
 
@@ -119,4 +119,4 @@ Application volume group is a pivotal concept in modern data management, providi
 * [Understand Azure NetApp Files application volume group for SAP HANA](application-volume-group-introduction.md)
 * [Requirements and considerations for application volume group for SAP HANA](application-volume-group-considerations.md)
 * [Understand application volume group for Oracle](application-volume-group-oracle-introduction.md)
-* [Requirements and considerations for application volume group for Oracle](application-volume-group-oracle-considerations.md)
+* [Requirements and considerations for application volume group for Oracle](application-volume-group-oracle-considerations.md)