Merge branch 'main' into release-defender-flip

Author: v-alje

articles/active-directory-b2c/media/analytics-with-application-insights/app-insights.png

@@ -41,7 +41,7 @@ The following environment variables are related to the app environment in genera
 | `WEBSITE_PROACTIVE_AUTOHEAL_ENABLED` | By default, a VM instance is proactively corrected when it uses more than 90% of allocated memory for more than 30 seconds, or when 80% of the total requests in the last two minutes take longer than 200 seconds. If a VM instance triggers one of these rules, the recovery process is an overlapping restart of the instance.<br/><br/>Set to `false` to disable this recovery behavior. The default is `true`.<br/><br/>For more information, see the [Introducing Proactive Auto Heal](https://azure.github.io/AppService/2017/08/17/Introducing-Proactive-Auto-Heal.html) blog post. |
 | `WEBSITE_PROACTIVE_CRASHMONITORING_ENABLED` | Whenever the w3wp.exe process on a VM instance of your app crashes due to an unhandled exception for more than three times in 24 hours, a debugger process is attached to the main worker process on that instance. The debugger process collects a memory dump when the worker process crashes again. This memory dump is then analyzed, and the call stack of the thread that caused the crash is logged in your App Service logs.<br/><br/>Set to `false` to disable this automatic monitoring behavior. The default is `true`.<br/><br/>For more information, see the [Proactive Crash Monitoring in Azure App Service](https://azure.github.io/AppService/2021/03/01/Proactive-Crash-Monitoring-in-Azure-App-Service.html) blog post. |
 | `WEBSITE_DAAS_STORAGE_SASURI` | During crash monitoring (proactive or manual), the memory dumps are deleted by default. To save the memory dumps to a storage blob container, specify the shared access signature (SAS) URI. |
-| `WEBSITE_CRASHMONITORING_ENABLED` | Set to `true` to enable [crash monitoring](https://azure.github.io/AppService/2020/08/11/Crash-Monitoring-Feature-in-Azure-App-Service.html) manually. You must also set `WEBSITE_DAAS_STORAGE_SASURI` and `WEBSITE_CRASHMONITORING_SETTINGS`. The default is `false`.<br/><br/>This setting has no effect if remote debugging is enabled. Also, if this setting is set to `true`, [proactive crash monitoring](https://azure.github.io/AppService/2021/03/01/Proactive-Crash-Monitoring-Feature-in-Azure-App-Service.html) is disabled. |
+| `WEBSITE_CRASHMONITORING_ENABLED` | Set to `true` to enable [crash monitoring](https://azure.github.io/AppService/2020/08/11/Crash-Monitoring-Feature-in-Azure-App-Service.html) manually. You must also set `WEBSITE_DAAS_STORAGE_SASURI` and `WEBSITE_CRASHMONITORING_SETTINGS`. The default is `false`.<br/><br/>This setting has no effect if remote debugging is enabled. Also, if this setting is set to `true`, [proactive crash monitoring](https://azure.github.io/AppService/2021/03/01/Proactive-Crash-Monitoring-in-Azure-App-Service.html) is disabled. |
 | `WEBSITE_CRASHMONITORING_SETTINGS` | JSON with the following format:`{"StartTimeUtc": "2020-02-10T08:21","MaxHours": "<elapsed-hours-from-StartTimeUtc>","MaxDumpCount": "<max-number-of-crash-dumps>"}`. Required to configure [crash monitoring](https://azure.github.io/AppService/2020/08/11/Crash-Monitoring-Feature-in-Azure-App-Service.html) if `WEBSITE_CRASHMONITORING_ENABLED` is specified. To log the call stack without saving the crash dump in the storage account, add `,"UseStorageAccount":"false"` in the JSON. |
 | `REMOTEDEBUGGINGVERSION` | Remote debugging version. |
 | `WEBSITE_CONTENTAZUREFILECONNECTIONSTRING` | By default, App Service creates a shared storage for you at app creation. To use a custom storage account instead, set to the connection string of your storage account. For functions, see [App settings reference for Azure Functions](../azure-functions/functions-app-settings.md#website_contentazurefileconnectionstring).<br/><br/>Example: `DefaultEndpointsProtocol=https;AccountName=<name>;AccountKey=<key>` |
@@ -180,6 +180,7 @@ This section shows the configurable runtime settings for each supported language
 | `WEBSITE_JAVA_MAX_HEAP_MB` | Java maximum heap, in megabytes. This setting is effective only when you use an experimental Tomcat version. |
 | `WEBSITE_DISABLE_JAVA_HEAP_CONFIGURATION` | Manually disable `WEBSITE_JAVA_MAX_HEAP_MB` by setting this variable to `true` or `1`. |
 | `WEBSITE_AUTH_SKIP_PRINCIPAL` | By default, the following Tomcat [HttpServletRequest interfaces](https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpServletRequest.html) are hydrated when you enable the built-in [authentication](overview-authentication-authorization.md): `isSecure`, `getRemoteAddr`, `getRemoteHost`, `getScheme`, `getServerPort`, `getLocalPort`, `getRequestURL`. To disable it, set the value to `1`. |
+| `WEBSITE_AUTH_EXPIRED_SESSION_LOGOFF` | If a webapp uses EasyAuth, set this to `true` or `1` to force a redirect to the EasyAuth logout page if the session associated to a request has expired (e.g. for webapps running on Tomcat, this is defined by the element `session-timeout` in the file `web.xml`). |
 | `WEBSITE_SKIP_FILTERS` | To disable all servlet filters that App Service added, set to `1`. |
 | `IGNORE_CATALINA_BASE` | By default, App Service checks if the Tomcat variable `CATALINA_BASE` is defined. If not, it looks for the existence of `%HOME%\tomcat\conf\server.xml`. If the file exists, it sets `CATALINA_BASE` to `%HOME%\tomcat`. To disable this behavior and remove `CATALINA_BASE`, set this variable to `1` or `true`. |
 | `PORT` | Read-only. For Linux apps, the port that the Java runtime listens to in the container. |

articles/app-service/reference-app-settings.md

@@ -1,20 +1,20 @@
 ---
-title: Routine maintenance for Azure App Service
+title: Routine Maintenance for Azure App Service
 description: Learn more about routine, planned maintenance to help keep the App Service platform up to date and secure.
 author: msangapu-msft
 tags: app-service
 
 ms.topic: article
-ms.date: 02/08/2023
+ms.date: 04/29/2025
 ms.author: msangapu
 ---
 
-# Routine (planned) maintenance for Azure App Service
+# Routine planned maintenance for Azure App Service
 
-Routine maintenance covers behind-the-scenes updates to Azure App Service. Types of maintenance can be performance improvements, bug fixes, new features, or security updates. App Service maintenance can be on the service itself or the underlying operating system.
+Routine maintenance covers behind-the-scenes updates to Azure App Service. Types of maintenance can be performance improvements, bug fixes, new features, or security updates. App Service maintenance can be on the service itself or on the underlying operating system.
 
 > [!IMPORTANT]
-> A breaking change or deprecation of functionality is not a part of routine maintenance. For more information, see [Modern Lifecycle Policy](/lifecycle/policies/modern).
+> A breaking change or deprecation of functionality isn't a part of routine maintenance. For more information, see [Modern Lifecycle Policy](/lifecycle/policies/modern).
 
 Microsoft service quality and uptime guarantees continue to apply during maintenance periods. Notifications mention maintenance periods to help customers get visibility into platform changes.
 
@@ -24,38 +24,38 @@ Like personal computers, mobile phones, and other devices, machines in the cloud
 
 Because a typical cloud solution consists of multiple applications, databases, storage accounts, functions, and other resources, parts of your solutions can undergo maintenance at different times. Some of this coordination is related to geography, region, datacenters, and availability zones. It can also be due to the cloud, where not everything is touched simultaneously. For more information, see [Safe deployment practices](/devops/operate/safe-deployment-practices).
 
-The following screenshot shows an example of a maintenance event:
+To find maintenance events, search for **Service Health** in the Azure portal. Under **Active Events**, select **Planned maintenance**.
 
-:::image type="content" source="./media/routine-maintenance/routine-maintenance.png" alt-text="Screenshot of a maintenance event in the Azure portal.":::
+:::image type="content" source="media/routine-maintenance/routine-maintenance.png" alt-text="Screenshot of a maintenance event in the Azure portal." lightbox="media/routine-maintenance/routine-maintenance.png":::
 
-In order from top to bottom, the example shows:
+From top to bottom, the example shows:
 
 - A descriptive title of the maintenance event.
 - Affected regions and subscriptions.
 - The expected maintenance window.
 
-The following screenshots show additional information available through the Impacted Resources dropdown:
+The following screenshots show additional information available through the **Impacted Resources** tab:
 
-:::image type="content" source="./media/routine-maintenance/routine-maintenance-first-page.png" alt-text="Screenshot of the Impacted Resources blade in the Azure portal.":::
+:::image type="content" source="media/routine-maintenance/routine-maintenance-first-page.png" alt-text="Screenshot of the Impacted Resources section in the Azure portal." lightbox="media/routine-maintenance/routine-maintenance-first-page.png":::
 
-In order from left to right, the example shows:
+From left to right, the example shows:
 
-- Selecting the "Impacted Resources" dropdown.
-- The "More info" option.
+- Selecting the **Impacted Resources** tab.
+- The **More info** option.
 
-:::image type="content" source="./media/routine-maintenance/routine-maintenance-more.png" alt-text="Screenshot of more info for a maintenance event in the Azure portal.":::
+:::image type="content" source="./media/routine-maintenance/routine-maintenance-more.png" alt-text="Screenshot of more info for a maintenance event in the Azure portal." lightbox="media/routine-maintenance/routine-maintenance-more.png":::
 
 This example shows:
 
 - The state of the maintenance, which can be pending, started, or completed.
-- Once maintenance starts, timestamps can be viewed under "More info."
+- Once maintenance starts, timestamps can be viewed under **More info**.
 
 
 ## Frequently asked questions
 
 ### Why is the maintenance taking so long?
 
-Fundamentally, routine maintenance delivers the latest updates to the platform and service. It's hard to predict how the maintenance will affect individual apps down to a specific time, so notifications tend to be more general. The time ranges in notifications don't reflect the experiences at the app level, but rather the overall operation across all resources. Apps that undergo maintenance instantly restart on freshly updated machines and continue working. There's no downtime when requests and traffic aren't served.
+Fundamentally, routine maintenance delivers the latest updates to the platform and service. It's hard to predict how the maintenance affects individual apps down to a specific time, so notifications tend to be more general. The time ranges in notifications don't reflect the experiences at the app level, but rather the overall operation across all resources. Apps that undergo maintenance instantly restart on freshly updated machines and continue working. There's no downtime when requests and traffic aren't served.
 
 ### Why am I getting so many notifications?
 
@@ -77,7 +77,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). 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.
+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 continues 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?
 
@@ -93,6 +93,6 @@ You can use health check to inform the platform that your application isn't read
 
 Updates and maintenance events have been happening to the platform since its inception. The frequency of updates decreased over time, so the number of interruptions also decreased and uptime increased. However, you now have more visibility into all changes. Increased visibility might cause the perception that more changes are happening.
 
-## Next steps
+## Related content
 
-Get more information about maintenance notifications by reading the blog post [Routine Planned Maintenance Notifications for Azure App Service](https://azure.github.io/AppService/2022/02/01/App-Service-Planned-Notification-Feature.html).
+- [Routine Planned Maintenance Notifications for Azure App Service](https://azure.github.io/AppService/2022/02/01/App-Service-Planned-Notification-Feature.html)