Dirty PR

Author: AbhishekMallick-MS

articles/api-management/private-endpoint.md

@@ -5,7 +5,7 @@ ms.service: azure-api-management
 author: dlepow
 ms.author: danlep
 ms.topic: how-to
-ms.date: 11/17/2025
+ms.date: 03/17/2026
 ms.custom:
   - build-2025
   - sfi-image-nochange
@@ -32,7 +32,9 @@ You can configure an inbound [private endpoint](../private-link/private-endpoint
 * Only the API Management instance's **Gateway endpoint** supports inbound Private Link connections. 
 * Each API Management instance supports at most 100 Private Link connections.
 * Connections aren't supported on the [self-hosted gateway](self-hosted-gateway-overview.md) or on a [workspace gateway](workspaces-overview.md#workspace-gateway). 
-* In the classic API Management tiers, private endpoints aren't supported in instances injected in an internal or external virtual network.
+* In the classic API Management tiers, private endpoints aren't supported in instances injected in an internal or external virtual network. 
+    > [!NOTE]
+    > In the Standard v2 and Premium v2 tiers, private endpoints are supported in instances with any supported virtual network configuration when fronted with [Azure Front Door Premium](../frontdoor/standard-premium/how-to-enable-private-link-apim.md).
 
 ## Typical scenarios
 
@@ -43,9 +45,6 @@ Supported configurations include:
 * Pass client requests through a firewall and configure rules to route requests privately to the API Management gateway.
 * Configure Azure Front Door (or Azure Front Door with Azure Application Gateway) to receive external traffic and then route traffic privately to the API Management gateway. For example, see [Connect Azure Front Door Premium to an Azure API Management with Private Link](../frontdoor/standard-premium/how-to-enable-private-link-apim.md).
 
-    > [!NOTE]
-    > Currently, routing traffic privately from Azure Front Door to an API Management Premium v2 instance isn't supported.
-
 ## Prerequisites
 
 - An existing API Management instance. [Create one if you haven't already](get-started-create-service-instance.md). 

articles/app-service/environment/how-to-upgrade-preference.md

@@ -5,7 +5,7 @@ description: Configure the upgrade preference for Azure App Service Environment
 author: seligj95
 ms.author: jordanselig
 ms.topic: how-to
-ms.date: 03/12/2026
+ms.date: 03/17/2026
 ms.service: azure-app-service
 ms.custom:
   - devx-track-azurecli
@@ -35,6 +35,8 @@ When you configure automatic upgrades, the platform upgrades your App Service En
 
 In smaller regions, the Early and Late upgrade preferences might be very close to each other.
 
+When automatic upgrades are enabled for an App Service Environment, upgrades from other Azure dependency services are permitted outside of the regional business hours. When manual upgrades are configured, these other service upgrades are gated with the App Service upgrade deployments.
+
 ## Review manual upgrade options
 
 When you configure manual upgrades, you receive a notification when an upgrade is available. The availability is also visible in the Azure portal. After the upgrade is available, you typically have 15 days to start the upgrade process. If you don't start the upgrade within the 15 days, the upgrade is processed with the remaining automatic upgrades in the region.

articles/app-service/overview-tls.md

@@ -40,7 +40,7 @@ App Service supports the following TLS versions for incoming requests to your we
 
 - **TLS 1.3**. The latest and most secure version, now fully supported.
 - **TLS 1.2**. The default minimum TLS version for new web apps.
-- **TLS 1.1 and TLS 1.0**. Versions supported for backward compatibility but not recommended.
+- **TLS 1.1 and TLS 1.0**. These are legacy protocols and are no longer considered secure.
 
 You can configure the *minimum TLS version* for incoming requests to your web app and its Source Control Manager (SCM) site. By default, the minimum is set to **TLS 1.2**.
 
@@ -71,12 +71,7 @@ App Service uses a secure set of TLS 1.2 cipher suites to help ensure encrypted
 
 ### TLS 1.1 and TLS 1.0
 
-TLS 1.1 and TLS 1.0 are legacy protocols and are no longer considered secure. These versions are supported on App Service only for backward compatibility and should be avoided when possible. The default minimum TLS version for new apps is TLS 1.2, and we recommend that you migrate apps that use TLS 1.1 or TLS 1.0.
-
-> [!IMPORTANT]
-> Incoming requests to web apps and incoming requests to Azure are handled differently. App Service continues to support TLS 1.1 and TLS 1.0 for incoming requests to web apps.
->
-> For incoming requests made directly to the Azure control plane, for example, through Azure Resource Manager or API calls, we don't recommend that you use TLS 1.1 or TLS 1.0.
+TLS 1.1 and TLS 1.0 are legacy protocols and are no longer considered secure. The default minimum TLS version for new apps is TLS 1.2, and we recommend that you migrate apps that use TLS 1.1 or TLS 1.0 to using TLS 1.2 or higher.
 
 ## Minimum TLS cipher suite
 

articles/app-service/webjobs-sdk-how-to.md

@@ -158,7 +158,7 @@ The following table shows built-in roles that we recommend when you use triggers
 [Azure Service Bus Data Receiver]: ../role-based-access-control/built-in-roles.md#azure-service-bus-data-receiver
 [Azure Service Bus Data Sender]: ../role-based-access-control/built-in-roles.md#azure-service-bus-data-sender
 [Azure Service Bus Data Owner]: ../role-based-access-control/built-in-roles.md#azure-service-bus-data-owner
-[role-assignment-scope]: ../service-bus-messaging/service-bus-managed-service-identity.md#resource-scope
+[role-assignment-scope]: ../service-bus-messaging/service-bus-managed-service-identity.md#choose-the-resource-scope
 
 #### Connection strings in version 2.*x*