Merge branch 'main' into IoTFreshness_Row2

Author: DENKEN02MSFT

articles/active-directory-b2c/tutorial-create-user-flows.md

@@ -213,7 +213,7 @@ Next, specify that the application should be treated as a public client:
 1. Ensure that **"isFallbackPublicClient": true** is set in the application manifest:
     1. In the left menu, under **Manage**, select **Manifest** to open application manifest.
     1. Switch from the **Microsoft Graph App Manifest (New)** tab to the **AAD Graph App Manifest (Deprecating Soon)** tab.
-    1. Find **allowPublicClient** key and ensure its value is set to **true**.
+    1. Find **isFallbackPublicClient** key and ensure its value is set to **true**.
 
 
 Now, grant permissions to the API scope you exposed earlier in the *IdentityExperienceFramework* registration:

articles/app-service/deploy-staging-slots.md

@@ -1,5 +1,5 @@
 ---
-title: Set up Staging Environments in Azure App Service
+title: Set Up Staging Environments
 description: Learn how to deploy apps to a nonproduction slot and automatically swap into production. Increase the reliability and eliminate app downtime from deployments.
 ms.assetid: e224fc4f-800d-469a-8d6a-72bcde612450
 ms.topic: how-to

articles/app-service/manage-backup.md

@@ -329,6 +329,8 @@ The following table shows which app configurations are restored when you choose
 
 A custom backup (on-demand backup or scheduled backup) includes all content and configuration that's included in an [automatic backup](#whats-included-in-an-automatic-backup), plus any linked database, up to the allowable maximum size.
 
+Each backup contains a .zip file with backup data and an .xml file {siteName}-{dateTime}.xml, which lists the contents, including [custom domains](app-service-web-tutorial-custom-domain.md). When restoring a custom backup, custom domains from the .xml file will be added to the destination app if no DNS conflict exists (i.e., the domain is available for binding), and if the destination app has different custom domains than the .xml file's custom domain list, those custom domains will be removed.
+
 When [backing up over Azure Virtual Network](#back-up-and-restore-over-azure-virtual-network), you can't [back up the linked database](#back-up-and-restore-a-linked-database).
 
 ### Why is my linked database not backed up?

articles/app-service/overview-authentication-authorization.md

@@ -1,5 +1,5 @@
 ---
-title: Authentication and Authorization in Azure App Service and Azure Functions
+title: Authentication and Authorization
 description: Learn about the built-in authentication and authorization support in Azure App Service and Azure Functions, and how it can help secure your app against unauthorized access.
 ms.assetid: b7151b57-09e5-4c77-a10c-375a262f17e5
 ms.topic: conceptual

articles/app-service/overview-managed-identity.md

@@ -1,5 +1,5 @@
 ---
-title: Use managed identities for App Service and Azure Functions
+title: Managed Identities
 description: Learn how managed identities work in Azure App Service and Azure Functions, along with how to configure a managed identity and generate a token for a back-end resource.
 ms.topic: how-to
 ms.date: 09/30/2024

articles/app-service/overview-tls.md

@@ -64,7 +64,7 @@ These suites provide strong encryption and are automatically used when TLS 1.3 i
 
 ### TLS 1.2
 
-TLS 1.2 is the **default and recommended** TLS version for App Service. It provides strong encryption and broad compatibility while meeting compliance standards like PCI DSS. New web apps and SCM endpoints are automatically set to TLS 1.2 unless changed.
+TLS 1.2 is the **default** TLS version for App Service. It provides strong encryption and broad compatibility while meeting compliance standards like PCI DSS. New web apps and SCM endpoints are automatically set to TLS 1.2 unless changed.
 
 Azure App Service uses a secure set of TLS 1.2 cipher suites to ensure encrypted connections and protect against known vulnerabilities. While TLS 1.0 and 1.1 can be enabled for backward compatibility, they are not recommended.
 

articles/app-service/routine-maintenance.md

@@ -60,7 +60,7 @@ Maintenance operations upgrade machines iteratively while App Service monitors t
 
 ### Are business hours reflected?
 
-Yes, business hours are reflected for the time zone of the region. Maintenance operations are optimized to start outside the standard business hours of 9 AM to 5 PM. Statistically, that's the best time for any interruptions and restarts of workloads because there's less stress on the system (in customer applications and transitively on the platform itself). If resources are still upgrading by 9 AM in a given region, the upgrade will safely pause before the next critical step and until the end of business hours. 
+Yes, business hours are reflected for the time zone of the region. Maintenance operations are optimized to start outside the standard business hours of 9 AM to 5 PM. Statistically, that's the best time for any interruptions and restarts of workloads because there's less stress on the system (in customer applications and transitively on the platform itself). App Service maintenance makes a best effort to reduce maintenance operations during these business hours. If resources are still upgrading by 9 AM in a given region, the upgrade will continue until reaching a safe stopping point, pausing before the next critical step and until the end of business hours.
 
 ### What are my options to control routine maintenance?
 

articles/app-service/troubleshoot-diagnostic-logs.md

@@ -1,5 +1,5 @@
 ---
-title: Enable Diagnostic Logging for Apps in Azure App Service
+title: Enable Diagnostic Logging
 description: Learn how to enable diagnostic logging and add instrumentation to your application, along with how to access the information logged by Azure.
 ms.assetid: c9da27b2-47d4-4c33-a3cb-1819955ee43b
 ms.topic: how-to

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

@@ -0,0 +1,77 @@
+---
+title: TLS 1.0 and 1.1 retirement on Azure Application Gateway
+description: Guidance for managing your Application Gateway with the upcoming retirement of TLS 1.0 and 1.1.
+services: application gateway
+author: jaesoni
+ms.service: azure-application-gateway
+ms.topic: concept-article
+ms.date: 03/04/2025
+ms.author: greglin
+---
+
+# Managing your Application Gateway with TLS 1.0 and 1.1 retirement
+
+Starting **31st August 2025**, Azure Application Gateway will no longer support **TLS (Transport Layer Security) versions 1.0 and 1.1**. This change aligns with the [Azure-wide retirement](https://azure.microsoft.com/updates?id=update-retirement-tls1-0-tls1-1-versions-azure-services) of these TLS versions to enhance the security. As the owner of an Application Gateway resource, you should review both the Frontend clients and Backend servers TLS connections that may be using these older versions.
+
+## Frontend TLS connections
+
+With deprecation of TLS versions 1.0 and 1.1, the **older Predefined TLS policies** and certain cipher suites from the **Custom TLS policy** will be removed.
+
+### Predefined policies for V2 SKUs
+
+The predefined policies 20150501 and 20170401 that support TLS v1.0 and 1.1 will be discontinued and can no longer be associated with an Application Gateway resource after August 2025. It's advised to transition to one of the recommended TLS policies, 20220101 or 20220101S. Alternatively, the 20170401S policy may be used if specific cipher suites are required. 
+
+![A diagram showing predefined policies for V2 SKUs.](media/application-gateway-tls-version-retirement/v2-retiring-tls-policies.png)
+
+### Custom policies for V2 SKUs
+
+Azure Application Gateway V2 SKU offers two types of custom policies: Custom and CustomV2. The retirement of these TLS versions affects only the "Custom" policy. The newer "CustomV2" policy comes with TLS v1.3. Beyond August 2025, the older Custom policy will support only TLS v1.2 and the following cipher suites won't be supported.
+
+| Unsupported cipher suites |
+| ---------- |
+| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
+| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
+| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 |
+| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 |
+| TLS_DHE_RSA_WITH_AES_256_CBC_SHA |
+| TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
+| TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 |
+| TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 |
+| TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
+| TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
+| TLS_RSA_WITH_3DES_EDE_CBC_SHA |
+| TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA |
+
+### Predefined policies for V1 SKUs
+
+The V1 SKU will only support the 20170401S policy after the older policies with TLS versions 1.0 and 1.1 are discontinued. The newer 20220101 or 20220101S policies won't be available for the soon-to-be-retired V1 SKU.
+
+![A diagram showing predefined policies for V1 SKUs.](media/application-gateway-tls-version-retirement/v1-retiring-tls-policies.png)
+
+### Custom policies for V1 SKUs
+
+Application Gateway V1 SKU only supports the older "Custom" policy. Beyond August 2025, this older Custom policy will support only TLS v1.2 and the following cipher suites won't be supported.
+
+| Unsupported cipher suites |
+| ---------- |
+| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
+| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
+| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 |
+| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 |
+| TLS_DHE_RSA_WITH_AES_256_CBC_SHA |
+| TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
+| TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 |
+| TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 |
+| TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
+| TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
+| TLS_RSA_WITH_3DES_EDE_CBC_SHA |
+| TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA |
+
+## Backend TLS connections
+
+You don't need to configure anything on your Application Gateway for the backend connection's TLS version as the selection of TLS policy has no control over the backend TLS connections. After retirement, the connections to backend servers will always be with preferred TLS v1.3 and up to TLS v1.2. You must ensure that your servers in the backend pools are compatible with these updated protocol versions. This compatibility avoids any disruptions when establishing a TLS/HTTPS connection with those backend servers.
+
+## Next steps
+
+Learn about [TLS policy types and configurations](application-gateway-ssl-policy-overview.md)
+Visit Azure Updates for [retirement notice](https://azure.microsoft.com/updates?searchterms=application+gateway)

articles/application-gateway/configuration-http-settings.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
 ms.topic: concept-article
-ms.date: 10/03/2024
+ms.date: 03/19/2025
 ms.author: greglin
 ---
 
@@ -15,37 +15,40 @@ The application gateway routes traffic to the backend servers by using the confi
 
 ## Cookie-based affinity
 
-Azure Application Gateway uses gateway-managed cookies for maintaining user sessions. When a user sends the first request to Application Gateway, it sets an affinity cookie in the response with a hash value which contains the session details, so that the subsequent requests carrying the affinity cookie are routed to the same backend server for maintaining stickiness.
+Azure Application Gateway uses gateway-managed cookies for maintaining user sessions. When a user sends the first request to Application Gateway, it sets an affinity cookie in the response with a hash value that contains the session details. This process enables subsequent requests that carry the affinity cookie to be routed to the same backend server, thus maintaining stickiness.
 
 This feature is useful when you want to keep a user session on the same server and when session state is saved locally on the server for a user session. If the application can't handle cookie-based affinity, you can't use this feature. To use it, make sure that the clients support cookies.
+
 > [!NOTE]
-> Some vulnerability scans may flag the Application Gateway affinity cookie because the Secure or HttpOnly flags are not set. These scans do not take into account that the data in the cookie is generated using a one-way hash. The cookie doesn't contain any user information and is used purely for routing. 
+> Some vulnerability scans may flag the Application Gateway affinity cookie because the Secure or HttpOnly flags are not set. These scans don't take into account that the data in the cookie is generated using a one-way hash. The cookie doesn't contain any user information and is used purely for routing. 
 
 
 The [Chromium browser](https://www.chromium.org/Home) [v80 update](https://chromiumdash.appspot.com/schedule) brought a mandate where HTTP cookies without [SameSite](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-03#rfc.section.5.3.7) attribute have to be treated as SameSite=Lax. For CORS (Cross-Origin Resource Sharing) requests, if the cookie has to be sent in a third-party context, it has to use *SameSite=None; Secure* attributes and it should be sent over HTTPS only. Otherwise, in an HTTP only scenario, the browser doesn't send the cookies in the third-party context. The goal of this update from Chrome is to enhance security and to avoid Cross-Site Request Forgery (CSRF) attacks. 
 
 To support this change, starting February 17 2020, Application Gateway (all the SKU types) will inject another cookie called *ApplicationGatewayAffinityCORS* in addition to the existing *ApplicationGatewayAffinity* cookie. The *ApplicationGatewayAffinityCORS* cookie has two more attributes added to it (*"SameSite=None; Secure"*) so that sticky sessions are maintained even for cross-origin requests.
 
-Note that the default affinity cookie name is *ApplicationGatewayAffinity* and you can change it. If in your network topology, you deploy multiple application gateways in line, you must set unique cookie names for each resource. If you're using a custom affinity cookie name, an additional cookie is added with `CORS` as suffix. For example: *CustomCookieNameCORS*.
+The default affinity cookie name is *ApplicationGatewayAffinity* and you can change it. If in your network topology, you deploy multiple application gateways in line, you must set unique cookie names for each resource. If you're using a custom affinity cookie name, an additional cookie is added with `CORS` as suffix. For example: *CustomCookieNameCORS*.
 
 > [!NOTE]
-> If the attribute *SameSite=None* is set, it is mandatory that the cookie also contains the *Secure* flag, and must be sent over HTTPS.  If session affinity is required over CORS, you must migrate your workload to HTTPS. 
-Please refer to TLS offload and End-to-End TLS documentation for Application Gateway here – [Overview](ssl-overview.md), [Configure an application gateway with TLS termination using the Azure portal](create-ssl-portal.md), [Configure end-to-end TLS by using Application Gateway with the portal](end-to-end-ssl-portal.md).
+> If the attribute *SameSite=None* is set, it's mandatory that the cookie also contains the *Secure* flag, and must be sent over HTTPS. If session affinity is required over CORS, you must migrate your workload to HTTPS. Refer to TLS offload and End-to-End TLS documentation for Application Gateway. See the [SSL overview](ssl-overview.md), [Configure an application gateway with TLS termination](create-ssl-portal.md), and [Configure end-to-end TLS](end-to-end-ssl-portal.md).
 
 ## Connection draining
 
 Connection draining helps you gracefully remove backend pool members during planned service updates. It applies to backend instances that are 
 - explicitly removed from the backend pool, or
 - reported as unhealthy by the health probes.
 
-You can apply this setting to all backend pool members by enabling Connection Draining in the Backend Setting. It ensures that all deregistering instances in a backend pool don't receive any new requests/connections while maintaining the existing connections until the configured timeout value. This is also true for WebSocket connections.
+You can apply this setting to all backend pool members by enabling Connection Draining in the Backend Setting. It ensures that all deregistering instances in a backend pool don't receive any new requests/connections while maintaining the existing connections until the configured timeout value. This process is also true for WebSocket connections.
 
 | Configuration Type  | Value |
 | ---------- | ---------- |
-|Default value when Connection Draining is not enabled in Backend Setting| 30 seconds |
+|Default value when Connection Draining isn't enabled in Backend Setting| 30 seconds |
 |User-defined value when Connection Draining is enabled in Backend Setting | 1 to 3600 seconds |
 
-The only exception to this are requests bound for deregistering instances because of gateway-managed session affinity. These requests continue to be forwarded to the deregistering instances.
+The only exception to this process are requests bound for deregistering instances because of gateway-managed session affinity. These requests continue to be forwarded to the deregistering instances.
+
+> [!NOTE]
+> There's a limitation where a configuration update will terminate ongoing connections after the connection draining timeout. To address this limitation, you must increase the connection draining time-out in the backend settings to a value higher than the max expected client download time. 
 
 ## Protocol
 
@@ -100,11 +103,11 @@ This setting associates a [custom probe](application-gateway-probe-overview.md#c
 
 ## Configuring the host name
 
-Application Gateway allows for the connection established to the backend to use a *different* hostname than the one used by the client to connect to Application Gateway. While this configuration can be useful in some cases, exercise caution when overriding the hostname such that it is different between the application gateway and the client compared to the backend target.  
+Application Gateway allows for the connection established to the backend to use a *different* hostname than the one used by the client to connect to Application Gateway. While this configuration can be useful in some cases, exercise caution when overriding the hostname such that it's different between the application gateway and the client compared to the backend target.  
 
-In production, it is recommended to keep the hostname used by the client towards the application gateway as the same hostname used by the application gateway to the backend target. This avoids potential issues with absolute URLs, redirect URLs, and host-bound cookies.
+In production environments, it's a best practice to use the same hostname for the client to application gateway connection and application gateway to backend target connection. This practice avoids potential issues with absolute URLs, redirect URLs, and host-bound cookies.
 
-Before setting up Application Gateway that deviates from this, please review the implications of such configuration as discussed in more detail in Architecture Center: [Preserve the original HTTP host name between a reverse proxy and its backend web application](/azure/architecture/best-practices/host-name-preservation)
+Before setting up Application Gateway that deviates from this, review the implications of such configuration as discussed in more detail in Architecture Center: [Preserve the original HTTP host name between a reverse proxy and its backend web application](/azure/architecture/best-practices/host-name-preservation)
 
 There are two aspects of an HTTP setting that influence the [`Host`](https://datatracker.ietf.org/doc/html/rfc2616#section-14.23) HTTP header that is used by Application Gateway to connect to the backend:
 - "Pick host name from backend-address"
@@ -120,10 +123,10 @@ An example case is multi-tenant services as the back end. An app service is a mu
 
 By default, the custom domain name is *example.azurewebsites.net*. To access your app service by using an application gateway through a hostname that's not explicitly registered in the app service or through the application gateway's FQDN, you can override the hostname in the original request to the app service's hostname. To do this, enable the **pick host name from backend address** setting.
 
-For a custom domain whose existing custom DNS name is mapped to the app service, the recommended configuration is not to enable the **pick host name from backend address**.
+For a custom domain whose existing custom DNS name is mapped to the app service, the recommended configuration isn't to enable the **pick host name from backend address**.
 
 > [!NOTE]
-> This setting is not required for App Service Environment, which is a dedicated deployment.
+> This setting isn't required for App Service Environment, which is a dedicated deployment.
 
 ## Host name override