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

Author: pauljewellmsft

articles/app-service/configure-error-pages.md

@@ -0,0 +1,54 @@
+---
+title: Configure error pages on App Service
+description: Learn how to configure a custom error page on App Service
+author: jefmarti
+ms.topic: how-to
+ms.custom: linux-related-content
+ms.date: 10/14/2024
+ms.author: jefmarti
+---
+
+# Configure error pages on App Service (preview)
+
+This article explains how to configure custom error pages on your web app. With App Service you can configure an error page for specific errors that will be presented to users instead of the default error page. 
+
+### Prerequisite
+In this tutorial, we're adding a custom 403 error page to our web app hosted on App Service and test it with an IP restriction. To do so, you need the following:
+- a web app hosted on App Service w/ a Premium SKU
+- an html file under 10 kb in size
+
+## Upload an error page
+For this example, we're uploading and testing a 403 error page to present to the user. Name your html file to match the error code (for example, `403.hmtl`). Once you have your html file prepared, you can upload it to your web app. In the configuration blade, you should see an **Error pages (preview)** tab. Click on this tab to view the error page options. If the options are greyed out, you need to upgrade to at least a Premium SKU to use this feature.
+
+Select the error code that you'd like to upload an error page for and click **Edit**. On the next screen, click the folder icon to select your html file. The file must be in html format and within the 10 kb size limit. Find your .html file and click on the **Upload** button at the bottom of the screen. Notice the Status in the table updates from Not Configured to Configured. Then click **Save** to complete the upload. 
+
+## Confirm error page
+Once the custom error page is uploaded and saved, we can trigger and view the page. In this example, we can trigger the 403 error by using an IP restriction.
+
+To set an IP restriction, go to the **Networking** blade and click the **Enabled with access restrictions** link under **Inbound traffic configuration**.
+
+Under the **Site access and rules** section, select the **+Add** button to create an IP restriction.
+
+In the form that follows, you need to change the Action to **Deny** and fill out the **Priority** and **IP Address Block**. In this example, we use the **Inbound address** found on the Networking blade and we're setting it to /0 (for example, `12.123.12.123/0`). This disables all public access when visiting the site.
+
+Once the Add rule form is filled out, select the **Add rule** button. Then click **Save**.
+
+Once saved, you need to restart the site for the changes to take effect. Go to your overview page and select **browse**. You should now see your custom error page load.
+
+## Error codes
+App Service currently supports three types of error codes that are available to customize:
+
+| Error code  | description |
+| ------------- | ------------- |
+| 403  | Access restrictions |
+| 502  | Gateway errors  |
+| 503  | Service unavailable  |
+
+## FAQ
+1. I've uploaded my error page, why doesn't it show when the error is triggered?
+
+Currently, error pages are only triggered when the error is coming from the front end. Errors that get triggered at the app level should still be handled through the app. 
+
+2. Why is the error page feature greyed out?
+
+Error pages are currently a Premium feature. You need to use at least a Premium SKU to enable the feature. 

articles/app-service/includes/deploy-intelligent-apps/deploy-intelligent-apps-linux-dotnet-pivot.md

@@ -75,7 +75,7 @@ For OpenAI, see this [documentation](https://platform.openai.com/docs/api-refere
 - `apiKey`
 - `modelId`
 
-Since we are deploying to App Service, we can secure these secrets in **Azure Key Vault** for protection. Follow the [Quickstart](/azure/key-vault/secrets/quick-create-cli#create-a-key-vault) to set up your Key Vault and add the secrets you saved from earlier.
+Since we're deploying to App Service, we can secure these secrets in **Azure Key Vault** for protection. Follow the [Quickstart](/azure/key-vault/secrets/quick-create-cli#create-a-key-vault) to set up your Key Vault and add the secrets you saved from earlier.
 Next, we can use Key Vault references as app settings in our App Service resource to reference in our application. Follow the instructions in the [documentation](../../app-service-key-vault-references.md?source=recommendations&tabs=azure-cli) to grant your app access to your Key Vault and to set up Key Vault references.
 Then, go to the portal Environment Variables blade in your resource and add the following app settings:
 
@@ -190,11 +190,11 @@ var kernel = builder.Build();
 
 ### Secure your app with managed identity
 
-If you�re using Azure OpenAI, it's highly recommended to secure your application using [managed identity](../../overview-managed-identity.md) to authenticate your app to your Azure OpenAI resource. This enables your application to access the Azure OpenAI resource without needing to manage API keys. If you're not using Azure OpenAI, your secrets can remain secure using Azure Key Vault outlined above.
+If you're using Azure OpenAI, it's highly recommended to secure your application using [managed identity](../../overview-managed-identity.md) to authenticate your app to your Azure OpenAI resource. This enables your application to access the Azure OpenAI resource without needing to manage API keys. If you're not using Azure OpenAI, your secrets can remain secure using Azure Key Vault outlined above.
 
 Follow the steps below to secure your application with managed identity:
 
-Add the identity package `Azure.Identity`. This package enables using Azure credentials in your app.  Install the package using Nuget package manager and add the using statement to the top of the OpenAI.razor file.
+Add the identity package `Azure.Identity`. This package enables using Azure credentials in your app.  Install the package using NuGet package manager and add the using statement to the top of the OpenAI.razor file.
 
 ```c#
 @using Azure.Identity
@@ -215,7 +215,7 @@ var kernel = Kernel.CreateBuilder()
 Once the credentials are added to the application, you'll then need to enable managed identity in your application and grant access to the resource.
 
 1. In your web app resource, navigate to the **Identity** blade and turn on **System assigned** and click **Save**
-2. Once System assigned identity is turned on, it register's the web app with Microsoft Entra ID and the web app can be granted permissions to access protected resources.  
+2. Once System assigned identity is turned on, it registers the web app with Microsoft Entra ID and the web app can be granted permissions to access protected resources.  
 3. Go to your Azure OpenAI resource and navigate to the **Access control (IAM)** blade on the left pane.  
 4. Find the Grant access to this resource card and click on **Add role assignment**
 5. Search for the **Cognitive Services OpenAI User** role and click **Next**

articles/app-service/toc.yml

@@ -41,7 +41,9 @@
     - name: Use settings from App Configuration
       href: app-service-configuration-references.md
     - name: App settings reference
-      href: reference-app-settings.md      
+      href: reference-app-settings.md  
+    - name: Configure error pages
+      href: configure-error-pages.md   
     - name: Configure specific languages
       items:
         - name: Configure ASP.NET

articles/application-gateway/application-gateway-backend-health-troubleshooting.md

@@ -417,7 +417,7 @@ This behavior can occur for one or more of the following reasons:
    Next hop: Azure Firewall private IP address
 
 > [!NOTE]
-> If the application gateway is not able to access the CRL endpoints, it marks the backend health status as "unknown" and cause fast update failures. To prevent these issues, check that your application gateway subnet is able to access `crl.microsoft.com` and `crl3.digicert.com`. This can be done by configuring your Network Security Groups to send traffic to the CRL endpoints. 
+> If the application gateway is not able to access the CRL endpoints, it might mark the backend health status as "unknown". To prevent these issues, check that your application gateway subnet is able to access `crl.microsoft.com` and `crl3.digicert.com`. This can be done by configuring your Network Security Groups to send traffic to the CRL endpoints. 
 
 ## Next steps
 

articles/application-gateway/application-gateway-faq.yml

@@ -67,7 +67,7 @@ sections:
         answer: |
           `Keep-Alive` timeout governs how long the application gateway waits for a client to send another HTTP request on a persistent connection before reusing it or closing it. TCP idle timeout governs how long a TCP connection is kept open if there's no activity. 
           
-          The `Keep-Alive` timeout in the Application Gateway v1 SKU is 120 seconds and in the v2 SKU it's 75 seconds. For private IP addresses, the value is nonconfigurable with a TCP idle timeout of 5 minutes. The TCP idle timeout is a 4-minute default on the frontend virtual IP (VIP) of both v1 and v2 SKU of Application Gateway. You can configure the TCP idle timeout value on v1 and v2 Application Gateway instances to be anywhere between 4 minutes and 30 minutes. For both v1 and v2 Application Gateway instances, you need to go to the public IP of the application gateway and change the TCP idle timeout under the **Configuration** pane of the public IP in the portal. You can set the TCP idle timeout value of the public IP through PowerShell by running the following commands: 
+          For HTTP/1.1 connections, the `Keep-Alive` timeout in the Application Gateway v1 and v2 SKU is 120 seconds. For private IP addresses, the value is nonconfigurable with a TCP idle timeout of 5 minutes. The TCP idle timeout is a 4-minute default on the frontend virtual IP (VIP) of both v1 and v2 SKU of Application Gateway. You can configure the TCP idle timeout value on v1 and v2 Application Gateway instances to be anywhere between 4 minutes and 30 minutes. For both v1 and v2 Application Gateway instances, you need to go to the public IP of the application gateway and change the TCP idle timeout under the **Configuration** pane of the public IP in the portal. You can set the TCP idle timeout value of the public IP through PowerShell by running the following commands: 
           
           ```azurepowershell-interactive
           $publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
@@ -77,6 +77,8 @@ sections:
 
           For HTTP/2 connections to the frontend IP address on Application Gateway v2 SKU, the idle timeout is set to 180 seconds and is nonconfigurable.
           
+          To prevent conflict and unexpected behavior, make sure that the TCP idle timeout is set to be the same as or longer than the keep-alive timeout.
+          
       - question: Does Application Gateway reuse the TCP connection that's established with a backend server?
         answer: Yes. Application Gateway reuses the existing TCP connections with a backend server.
 

articles/automation/disable-local-authentication.md

@@ -3,8 +3,8 @@ title: Disable local authentication in Azure Automation
 description: This article describes disabling local authentication in Azure Automation.
 services: automation
 ms.subservice: process-automation
-ms.date: 11/20/2023
-ms.custom: engagement-fy23
+ms.date: 06/06/2024
+ms.custom: engagement-fy24
 ms.topic: how-to
 #Customer intent: As an administrator, I want disable local authentication so that I can enhance security.
 ms.service: azure-automation
@@ -40,7 +40,7 @@ The following table describes the behaviors or features that are prevented from
 |Starting a runbook using a webhook. | Start a runbook job using Azure Resource Manager template, which uses Microsoft Entra authentication. |
 |Using Automation Desired State Configuration.| Use [Azure Policy Guest configuration](../governance/machine-configuration/overview.md).  |
 |Using agent-based Hybrid Runbook Workers.| Use [extension-based Hybrid Runbook Workers](./extension-based-hybrid-runbook-worker-install.md).|
-|Using Azure Update Manager |Use [Azure Update Manager](../update-manager/overview.md)|
+|Using Automation Update Management |Use [Azure Update Manager](../update-manager/overview.md)|
 
 
 ## Next steps

articles/azure-netapp-files/data-plane-security.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-ahibbard
 ms.service: azure-netapp-files
 ms.topic: conceptual
-ms.date: 09/30/2024
+ms.date: 10/25/2024
 ms.author: anfdocs
 ---
 
@@ -114,9 +114,10 @@ For more information on data encryption at rest, see [Understand data encryption
 The data plane manages the encryption keys used to encrypt and decrypt data. These keys can be either platform-managed or customer-managed:
 
 - **Platform-managed keys** are automatically managed by Azure, ensuring secure storage and rotation of keys.
-- **Customer-managed keys** are stored in Azure Key Vault, allowing you to manage the lifecycle, usage permissions, and auditing of your encryption keys.
+- [**Customer-managed keys**](configure-customer-managed-keys.md) are stored in Azure Key Vault, allowing you to manage the lifecycle, usage permissions, and auditing of your encryption keys.
+- [**Customer-managed keys with managed Hardware Security Module (HSM)**](configure-customer-managed-keys-hardware.md) is an extension to customer-managed keys for Azure NetApp Files volume encryption feature. This HSM extension allows you to store your encryptions keys in a more secure FIPS 140-2 Level 3 HSM instead of the FIPS 140-2 Level 1 or Level 2 service used by Azure Key Vault (AKV).
 
-For more information about Azure NetApp Files key management, see [How are encryption keys managed](faq-security.md#how-are-encryption-keys-managed) or [Configure customer-managed keys](configure-customer-managed-keys.md).
+For more information about Azure NetApp Files key management, see [How are encryption keys managed](faq-security.md#how-are-encryption-keys-managed), [Configure customer-managed keys](configure-customer-managed-keys.md), or [customer-managed keys with managed HSM](configure-customer-managed-keys-hardware.md).
 
 ## Lightweight directory access protocol (LDAP) encryption
 

articles/azure-netapp-files/faq-security.md

@@ -5,7 +5,7 @@ ms.service: azure-netapp-files
 ms.topic: conceptual
 author: b-hchen
 ms.author: anfdocs
-ms.date: 08/07/2024
+ms.date: 10/24/2024
 ms.custom: references_regions
 ---
 # Security FAQs for Azure NetApp Files
@@ -30,12 +30,10 @@ Azure NetApp Files cross-region and cross-zone replication uses TLS 1.2 AES-256
 
 By default key management for Azure NetApp Files is handled by the service, using [platform-managed keys](../security/fundamentals/key-management.md). A unique XTS-AES-256 data encryption key is generated for each volume. An encryption key hierarchy is used to encrypt and protect all volume keys. These encryption keys are never displayed or reported in an unencrypted format. When you delete a volume, Azure NetApp Files immediately deletes the volume's encryption keys.
 
-Alternatively, [customer-managed keys for Azure NetApp Files volume encryption](configure-customer-managed-keys.md) can be used where keys are stored in [Azure Key Vault](/azure/key-vault/general/basic-concepts). With customer-managed keys, you can fully manage the relationship between a key's life cycle, key usage permissions, and auditing operations on keys. The feature is generally available (GA) in [supported regions](configure-customer-managed-keys.md#supported-regions).
+Alternatively, [customer-managed keys for Azure NetApp Files volume encryption](configure-customer-managed-keys.md) can be used where keys are stored in [Azure Key Vault](/azure/key-vault/general/basic-concepts). With customer-managed keys, you can fully manage the relationship between a key's life cycle, key usage permissions, and auditing operations on keys. The feature is generally available (GA) in [supported regions](configure-customer-managed-keys.md#supported-regions). [Azure NetApp Files volume encryption with customer-managed keys with the managed Hardware Security Module](configure-customer-managed-keys-hardware.md) is an extension to this feature, allowing you to store your encryption keys in a more secure FIPS 140-2 Level 3 HSM instead of the FIPS 140-2 Level 1 or Level 2 service used by Azure Key Vault.
 
 Azure NetApp Files supports the ability to move existing volumes using platform-managed keys to customer-managed keys. Once you complete the transition, you cannot revert back to platform-managed keys. For additional information, see [Transition an Azure NetApp Files volume to customer-managed keys](configure-customer-managed-keys.md#transition).
 
-<!-- Also, customer-managed keys using Azure Dedicated HSM is supported on a controlled basis. Support is currently available in the East US, South Central US, West US 2, and US Gov Virginia regions. You can request access [with the Azure NetApp Files feedback form](https://aka.ms/ANFFeedback). As capacity becomes available, requests will be approved. -->
-
 ## Can I configure the NFS export policy rules to control access to the Azure NetApp Files service mount target?
 
 Yes, you can configure up to five rules in a single NFS export policy.

articles/azure-netapp-files/performance-large-volumes-linux.md

@@ -13,7 +13,7 @@ ms.workload: storage
 ms.tgt_pltfrm: na
 ms.custom: linux-related-content
 ms.topic: conceptual
-ms.date: 10/24/2024
+ms.date: 10/25/2024
 ms.author: anfdocs
 ---
 # Azure NetApp Files large volume performance benchmarks for Linux
@@ -87,9 +87,9 @@ The following graphs compare the advantages of `nconnect` with an NFS-mounted vo
 
 ### Linux read throughput 
 
-The following graphs show 256-KiB sequential reads of ~10,000MiB/s with `nconnect`, which is roughly ten times the throughput achieved without `nconnect`.  
+The following graphs show 256-KiB sequential reads of approximately 10,000M iB/s with `nconnect`, which is roughly ten times the throughput achieved without `nconnect`.  
 
-Note that 10,000 MiB/s bandwidth is offered by a large volume in the Ultra service level. 
+Note that 10,000 MiB/s is roughly the line rate of the 100 Gbps network interface card attached to the E104id_v5.
 
 :::image type="content" source="./media/performance-large-volumes-linux/throughput-comparison-nconnect.png" alt-text="Bar chart comparison of read throughput with and without nconnect." lightbox="./media/performance-large-volumes-linux/throughput-comparison-nconnect.png":::
 

articles/azure-resource-manager/management/resource-name-rules.md

@@ -492,6 +492,7 @@ In the following tables, the term alphanumeric refers to:
 > | scheduledQueryRules | resource group | 1-260 | Can't use:<br>`*<>%{}&:\\?/#|` or control characters <br><br>Can't end with space or period.  |
 > | metricAlerts | resource group | 1-260 | Can't use:<br>`*#&+:<>?@%{}\/|` or control characters <br><br>Can't end with space or period.  |
 > | activityLogAlerts | resource group | 1-260 | Can't use:<br>`<>*%{}&:\\?+/#|` or control characters <br><br>Can't end with space or period.  |
+> | PrometheusAlerts | resource group | 1-260 | Can't use:<br>`<>*%{}&:\\?+/#|` or control characters <br><br>Can't end with space or period.  |
 
 ## Microsoft.IoTCentral