Merge pull request #289311 from dominicbetts/release-aio-m3-fix-conflict

Dirty PR - AIO [M3]: Fix merge conflict with main

Author: rmca14

articles/api-management/api-management-subscriptions.md

@@ -6,7 +6,7 @@ author: dlepow
 
 ms.service: azure-api-management
 ms.topic: conceptual
-ms.date: 08/02/2023
+ms.date: 09/03/2024
 ms.author: danlep
 ms.custom: engagement-fy23
 ---
@@ -133,7 +133,7 @@ After the subscription requirement is disabled, the selected API or APIs can be
 
 When API Management receives an API request from a client with a subscription key, it handles the request according to these rules: 
 
-1. Check if it's a valid key associated with an active subscription, either:
+1. Check first if it's a valid key associated with an active subscription, either:
 
     * A subscription scoped to the API
     * A subscription scoped to a product that's assigned to the API
@@ -142,13 +142,15 @@ When API Management receives an API request from a client with a subscription ke
 
     If a valid key for an active subscription at an appropriate scope is provided, access is allowed. Policies are applied depending on the configuration of the policy definition at that scope.
 
+1. If the key isn't valid but a product exists that includes the API but doesn't require a subscription (an *open* product), ignore the key and handle as an API request without a subscription key (see below). 
+
 1. Otherwise, access is denied (401 Access denied error).
 
 ### API request without a subscription key
 
 When API Management receives an API request from a client without a subscription key, it handles the request according to these rules: 
 
-1. Check first for the existence of a product that includes the API but doesn't require a subscription (an *open* product). If the open product exists, handle the request in the context of the APIs, policies, and access rules configured for the product. An API can be associated with at most one open product.
+1. Check first for the existence of a product that includes the API but doesn't require a subscription (an *open* product). If the open product exists, handle the request in the context of the APIs, policies, and access rules configured for the open product. An API can be associated with at most one open product.
 1. If an open product including the API isn't found, check whether the API requires a subscription. If a subscription isn't required, handle the request in the context of that API and operation.
 1. If no configured product or API is found, then access is denied (401 Access denied error).
 
@@ -160,16 +162,16 @@ The following table summarizes how the gateway handles API requests with or with
 |All products assigned to API require subscription  |API requires subscription  |API call with subscription key  |API call without subscription key  | Typical scenarios |
 |---------|---------|---------|---------|----|
 |✔️     | ✔️     | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/><br/>Access denied:<br/><br/>• Other key not scoped to applicable product or API        | Access denied        | Protected API access using product-scoped or API-scoped subscription  |
-|✔️     |  ❌    | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/><br/>Access denied:<br/><br/>• Other key not scoped to applicable product or API        |  Access allowed (API context)   | • Protected API access with product-scoped subscription<br/><br/>• Anonymous access to API. If anonymous access isn’t intended, configure API-level policies to enforce authentication and authorization. |
+|✔️     |  ❌    | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/>• Other key not scoped to applicable product or API        |  Access allowed (API context)   | • Protected API access with product-scoped subscription<br/><br/>• Anonymous access to API. If anonymous access isn’t intended, configure API-level policies to enforce authentication and authorization. |
 |❌<sup>1</sup>     | ✔️    | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/><br/>Access denied:<br/><br/>• Other key not scoped to applicable product or API        |    Access allowed (open product context)     | •	Protected API access with API-scoped subscription<br/><br/>•	Anonymous access to API. If anonymous access isn’t intended, configure with product policies to enforce authentication and authorization  |
-|❌<sup>1</sup>     |  ❌      | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/><br/>Access denied:<br/><br/>• Other key not scoped to applicable product or API        | Access allowed (open product context)        | Anonymous access to API. If anonymous access isn’t intended, configure with product policies to enforce authentication and authorization  |
+|❌<sup>1</sup>     |  ❌      | Access allowed:<br/><br/>• Product-scoped key<br/>• API-scoped key<br/>• All APIs-scoped key<br/>• Service-scoped key<br/>• Other key not scoped to applicable product or API        | Access allowed (open product context)        | Anonymous access to API. If anonymous access isn’t intended, configure with product policies to enforce authentication and authorization  |
 
 <sup>1</sup> An open product exists that's associated with the API. 
 
 ### Considerations
 
 -	API access in a product context is the same, whether the product is published or not. Unpublishing the product hides it from the developer portal, but it doesn’t invalidate new or existing subscription keys.
--	Even if a product or API doesn't require a subscription, a valid key from an active subscription that enables access to the product or API can still be used.
+-   If an API doesn't require subscription authentication, any API request that includes a subscription key is treated the same as a request without a subscription key. The subscription key is ignored.
 -	API access "context" means the policies and access controls that are applied at a particular scope (for example, API or product).
 
 ## Next steps

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/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