Merge branch 'main' into release-aio-m3

Author: v-alje

articles/application-gateway/application-gateway-secure-flag-session-affinity.md

@@ -0,0 +1,55 @@
+---
+title: Setting HTTPOnly or Secure flag for Session Affinity cookie
+titleSuffix: Azure Application Gateway
+description: Learn how to set HTTPOnly or Secure flag for Session Affinity cookie
+services: application-gateway
+author: jaesoni
+ms.service: azure-application-gateway
+ms.topic: how-to
+ms.date: 10/22/2024
+ms.author: jaysoni 
+---
+
+# Setting HTTPOnly or Secure flag for Session Affinity cookie
+In this guide you learn to create a Rewrite set for your Application Gateway and configure Secure and HttpOnly [ApplicationGatewayAffinity cookie](configuration-http-settings.md#cookie-based-affinity).
+
+
+## Prerequisites
+* You must have an Azure subscription. You can create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.
+* An existing Application Gateway resource configured with at least one Listener, Rule, Backend Setting and Backend Pool configuration. If you don't have one, you can create one by following the [QuickStart guide](quick-create-portal.md).
+
+## Creating a Rewrite set
+
+1. Sign in to the Azure portal.
+1. Navigate to the required Application Gateway resource.
+1. Select Rewrites in the left pane.
+1. Select Rewrite set.
+1. Under the Name and Association tab
+    1. Specify a name for this new rewrite set.
+    1. Select the routing rules for which you wish to rewrite the ApplicationGatewayAffinity cookie's flag.
+    1. Select Next.
+1. Select "Add rewrite rule"
+    1. Enter a name for the rewrite rule.
+    1. Enter a numeric value for Rule Sequence field.
+1. Select "Add condition"
+1. Now open the "If" condition box and use the following details.
+    1. Type of variable to check - HTTP header
+    1. Header type - Response header
+    1. Header name - Common header
+    1. Common header - Set-Cookie
+    1. Case-sensitive - No
+    1. Operator - equal (=)
+    1. Pattern to match - (.*)
+    1. To save these details, select **OK**.
+1. Go to the **Then** box to specify action details.
+    1. Rewrite type - Response header
+    1. Action type - Set
+    1. Header name - Common header
+    1. Common header - Set-Cookie
+    1. Header value - {http_resp_Set-Cookie_1}; HttpOnly; Secure
+    1. Select **OK**
+1. Select Update to save the rewrite set configurations.
+
+
+## Next steps
+[Visit other configurations of a Backend Setting](configuration-http-settings.md)

articles/application-gateway/rewrite-http-headers-url.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: greg-lindsay
 ms.service: azure-application-gateway
 ms.topic: how-to
-ms.date: 4/05/2021
+ms.date: 10/22/2024
 ms.author: greglin
 ---
 
@@ -72,7 +72,7 @@ In the below example whenever the request URL contains */article*, the URL path
 
     f. Enter a regular expression pattern. In this example, we'll use the pattern `.*article/(.*)/(.*)`
 
-      ( ) is used to capture the substring for later use in composing the expression for rewriting the URL path. For more information, see [here](rewrite-http-headers-url.md#capturing).
+      ( ) is used to capture the substring for later use in composing the expression for rewriting the URL path. For more information, see [Pattern matching and capturing](rewrite-http-headers-url.md#pattern-matching-and-capturing).
 
     g. Select **OK**.
 

articles/application-gateway/rewrite-url-portal.md

@@ -267,6 +267,8 @@
           href: add-http-header-rewrite-rule-powershell.md
         - name: Create and rewrite HTTP headers
           href: tutorial-http-header-rewrite-powershell.md
+        - name: Add secure flag for cookies 
+          href: application-gateway-secure-flag-session-affinity.md       
     - name: URL rewrite
       items:
         - name: Azure portal

articles/application-gateway/toc.yml

@@ -94,10 +94,10 @@ To add a secret to the vault, you need to take just a few additional steps. In t
 
     ```json
     {
-    "clientId": "00000000-0000-0000-0000-000000000000",
-    "clientSecret": "00000000-0000-0000-0000-000000000000",
-    "subscriptionId": "00000000-0000-0000-0000-000000000000",
-    "tenantId": "00000000-0000-0000-0000-000000000000",
+    "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
+    "clientSecret": "aaaaaaaa-0b0b-1c1c-2d2d-333333333333",
+    "subscriptionId": "aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e",
+    "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
     "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
     "resourceManagerEndpointUrl": "https://management.azure.com/",
     "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",

articles/azure-app-configuration/use-key-vault-references-spring-boot.md

@@ -147,6 +147,7 @@ Keep these other considerations in mind when using Flex Consumption plan during
 + **Diagnostic settings**: Diagnostic settings are not currently supported.
 + **Certificates**: Loading certificates with the WEBSITE_LOAD_CERTIFICATES app setting is currently not supported.
 + **Key Vault References**: Key Vault references in app settings do not work when Key Vault is network access restricted, even if the function app has Virtual Network integration. The current workaround is to directly reference the Key Vault in code and read the required secrets.
++ **Azure Files file share mount**: [Mounting an Azure Files file share](./scripts/functions-cli-mount-files-storage-linux.md) does not work when the function app has Virtual Network integration. 
 
 ## Related articles
 

articles/azure-functions/flex-consumption-plan.md

@@ -159,7 +159,7 @@ You can also use the [Azure Key Vault solution in Azure Monitor](/azure/key-vaul
 #### Vault
 **[Vaults](/azure/key-vault/general/overview)** provide a multi-tenant, low-cost, easy to deploy, zone-resilient (where available), and highly available key management solution suitable for most common cloud application scenarios. Vaults can store and safeguard [secrets, keys, and certificates](/azure/key-vault/general/about-keys-secrets-certificates). They can be either software-protected (standard tier) or HSM-protected (premium tier). For a comparison between the standard and premium tiers, see the [Azure Key Vault pricing page](https://azure.microsoft.com/pricing/details/key-vault/). Software-protected secrets, keys, and certificates are safeguarded by Azure, using industry-standard algorithms and key lengths. If you require extra assurances, you can choose to safeguard your secrets, keys, and certificates in vaults protected by multi-tenant HSMs. The corresponding HSMs are validated according to the [FIPS 140 standard](/azure/compliance/offerings/offering-fips-140-2), and have an overall Security Level 2 rating, which includes requirements for physical tamper evidence and role-based authentication.
 
-Vaults enable support for [customer-managed keys](../security/fundamentals/encryption-models.md) (CMK) where you can control your own keys in HSMs, and use them to encrypt data at rest for [many Azure services](../security/fundamentals/encryption-models.md#supporting-services). As mentioned previously, you can [import or generate encryption keys](/azure/key-vault/keys/hsm-protected-keys) in HSMs ensuring that keys never leave the HSM boundary to support *bring your own key (BYOK)* scenarios.
+Vaults enable support for [customer-managed keys](../security/fundamentals/encryption-models.md) (CMK) where you can control your own keys in HSMs, and use them to encrypt data at rest for [many Azure services](../security/fundamentals/encryption-models.md#services-supporting-customer-managed-keys-cmks). As mentioned previously, you can [import or generate encryption keys](/azure/key-vault/keys/hsm-protected-keys) in HSMs ensuring that keys never leave the HSM boundary to support *bring your own key (BYOK)* scenarios.
 
 Key Vault can handle requesting and renewing certificates in vaults, including Transport Layer Security (TLS) certificates, enabling you to enroll and automatically renew certificates from supported public Certificate Authorities. Key Vault certificates support provides for the management of your X.509 certificates, which are built on top of keys and provide an automated renewal feature. Certificate owner can [create a certificate](/azure/key-vault/certificates/create-certificate) through Azure Key Vault or by importing an existing certificate. Both self-signed and Certificate Authority generated certificates are supported. Moreover, the Key Vault certificate owner can implement secure storage and management of X.509 certificates without interaction with private keys.
 
@@ -179,7 +179,7 @@ When a managed HSM is created, the requestor also provides a list of data plane
 > [!IMPORTANT]
 > Unlike with key vaults, granting your users management plane access to a managed HSM doesn't grant them any access to data plane to access keys or data plane role assignments managed HSM local RBAC. This isolation is implemented by design to prevent inadvertent expansion of privileges affecting access to keys stored in managed HSMs.
 
-As mentioned previously, managed HSM supports [importing keys generated](/azure/key-vault/managed-hsm/hsm-protected-keys-byok) in your on-premises HSMs, ensuring the keys never leave the HSM protection boundary, also known as *bring your own key (BYOK)* scenario. Managed HSM supports integration with Azure services such as [Azure Storage](../storage/common/customer-managed-keys-overview.md), [Azure SQL Database](/azure/azure-sql/database/transparent-data-encryption-byok-overview), [Azure Information Protection](/azure/information-protection/byok-price-restrictions), and others. For a more complete list of Azure services that work with Managed HSM, see [Data encryption models](../security/fundamentals/encryption-models.md#supporting-services).
+As mentioned previously, managed HSM supports [importing keys generated](/azure/key-vault/managed-hsm/hsm-protected-keys-byok) in your on-premises HSMs, ensuring the keys never leave the HSM protection boundary, also known as *bring your own key (BYOK)* scenario. Managed HSM supports integration with Azure services such as [Azure Storage](../storage/common/customer-managed-keys-overview.md), [Azure SQL Database](/azure/azure-sql/database/transparent-data-encryption-byok-overview), [Azure Information Protection](/azure/information-protection/byok-price-restrictions), and others. For a more complete list of Azure services that work with Managed HSM, see [Data encryption models](../security/fundamentals/encryption-models.md#services-supporting-customer-managed-keys-cmks).
 
 Managed HSM enables you to use the established Azure Key Vault API and management interfaces. You can use the same application development and deployment patterns for all your applications irrespective of the key management solution: multi-tenant vault or single-tenant managed HSM.
 

articles/azure-government/azure-secure-isolation-guidance.md

@@ -192,3 +192,13 @@ Specifically, if your application typically broadcasts to larger groups (size >1
 To ensure effective failover management, it is recommended to set each replica's unit size to handle all traffic. Alternatively, you could enable [autoscaling](signalr-howto-scale-autoscale.md) to manage this.
 
 For more performance evaluation, refer to [Performance](signalr-concept-performance.md).
+
+## Non-Inherited and Inherited Configurations
+Replicas inherit most configurations from the primary resource; however, some settings must be configured directly on the replicas. Below is the list of those configurations:
+
+1. **SKU**: Each replica has its own SKU name and unit size. The autoscaling rules for replicas must be configured separately based on their individual metrics.
+2. **Shared private endpoints**: While shared private endpoints are automatically replicated to replicas, separate approvals are required on target private link resources. To add or remove shared private endpoints, manage them on the primary resource. **Do not** enable the replica until its shared private endpoint has been approved.
+3. **Log Destination Settings**. If not configured on the replicas, only logs from the primary resource will be transferred.
+4. **Alerts**. 
+
+All other configurations are inherited from the primary resource. For example, access keys, identity, application firewall, custom domains, private endpoints, and access control.

articles/azure-signalr/howto-enable-geo-replication.md

@@ -200,4 +200,14 @@ To ensure effective failover management, it is recommended to set each replica's
 
 For more performance evaluation, refer to [Performance](concept-performance.md).
 
+## Non-Inherited and Inherited Configurations
+Replicas inherit most configurations from the primary resource; however, some settings must be configured directly on the replicas. Below is the list of those configurations:
+
+1. **SKU**: Each replica has its own SKU name and unit size. The autoscaling rules for replicas must be configured separately based on their individual metrics.
+2. **Shared private endpoints**: While shared private endpoints are automatically replicated to replicas, separate approvals are required on target private link resources. To add or remove shared private endpoints, manage them on the primary resource. **Do not** enable the replica until its shared private endpoint has been approved.
+3. **Log Destination Settings**. If not configured on the replicas, only logs from the primary resource will be transferred.
+4. **Alerts**. 
+
+All other configurations are inherited from the primary resource. For example, access keys, identity, application firewall, custom domains, private endpoints, and access control.
+
 

articles/azure-web-pubsub/howto-enable-geo-replication.md

@@ -146,7 +146,7 @@ Rooms are created and managed via rooms APIs or SDKs. Use the rooms API/SDKs in
 | Virtual Rooms SDKs | 2023-06-14 | Generally Available - Fully supported |
 | Virtual Rooms SDKs | 2023-10-30 | Public Preview - Fully supported |
 | Virtual Rooms SDKs | 2023-03-31 | Public Preview - retired |
-| Virtual Rooms SDKs | 2022-02-01 | Will be retired on April 30, 2024 |
+| Virtual Rooms SDKs | 2022-02-01 | Public Preview - retired |
 | Virtual Rooms SDKs | 2021-04-07 | Public Preview - retired |
 
 ## Predefined participant roles and permissions in Virtual Rooms calls