Merge pull request #311851 from MicrosoftDocs/main

Auto Publish – main to live - 2026-02-16 12:00 UTC

Author: learn-build-service-prod[bot]

articles/application-gateway/ssl-overview.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: mbender-ms
 ms.service: azure-application-gateway
 ms.topic: concept-article
-ms.date: 10/09/2025
+ms.date: 02/16/2026
 ms.author: mbender
 
 # Customer intent: "As a cloud architect, I want to configure end to end TLS on the application gateway, so that I can ensure secure communication and compliance for sensitive data transmitted between clients and backend servers."
@@ -125,10 +125,22 @@ The following tables outline the differences in SNI between the v1 and v2 SKU in
 | --- | --- | --- |
 | If the client specifies SNI header and all the multi-site listeners are enabled with "Require SNI" flag | Returns the appropriate certificate and if the site doesn't exist (according to the server_name), then the connection is reset. | Returns appropriate certificate if available, otherwise, returns the certificate of the first HTTPS listener according to the order specified by the request routing rules associated with the HTTPS listeners|
 | If the client doesn't specify a SNI header and if all the multi-site headers are enabled with "Require SNI" | Resets the connection | Returns the certificate of the first HTTPS listener according to the order specified by the request routing rules associated with the HTTPS listeners
-| If the client doesn't specify SNI header and if there's a basic listener configured with a certificate | Returns the certificate configured in the basic listener to the client (default or fallback certificate) | Returns the certificate configured in the basic listener |
+| If the client doesn't specify SNI header and if there's a basic listener configured with a certificate | Returns the certificate configured in the basic listener to the client (default or fallback certificate) | Returns the certificate of the HTTPS listener with the highest priority routing rule. The basic listener certificate is **not** used as a fallback. |
+
+> [!IMPORTANT]
+> **V2 SKU default certificate behavior:** When a client connects without an SNI header (for example, using an IP address), Application Gateway V2 does **not** fall back to a basic listener's certificate. Instead, it always returns the certificate from the HTTPS listener whose associated request routing rule has the **highest priority** (lowest priority number). This behavior differs from the V1 SKU, which returns the basic listener's certificate as a fallback.
+
+> [!TIP]
+> **Controlling the default certificate with an SNI hole:** To prevent Application Gateway V2 from exposing a production site certificate when clients connect by IP address without SNI, you can configure an "SNI hole":
+>
+> 1. Create a **multi-site HTTPS listener** with a dummy hostname that doesn't match any real site (for example, `sni-hole.invalid`).
+> 2. Upload a **self-signed certificate** to this listener.
+> 3. Create a **request routing rule** associated with this listener and assign it the **highest priority** (lowest priority number) among all your rules.
+>
+> With this configuration, any connection without a matching SNI header receives the self-signed certificate instead of a valid site certificate. This prevents IP-only connections from obtaining information about your hosted sites.
 
 > [!NOTE]
-> When the client does not specify an SNI header, it is recommended that the user add a basic listener and rule to present a default SSL/TLS certificate.
+> For the V1 SKU, when the client doesn't specify an SNI header, it's recommended that the user add a basic listener and rule to present a default SSL/TLS certificate.
 
 > [!TIP]
 > The SNI flag can be configured with PowerShell or by using an ARM template. For more information, see [RequireServerNameIndication](/powershell/module/az.network/set-azapplicationgatewayhttplistener#-requireservernameindication) and [Quickstart: Direct web traffic with Azure Application Gateway - ARM template](quick-create-template.md#review-the-template).
@@ -140,7 +152,7 @@ The following tables outline the differences in SNI between the v1 and v2 SKU in
 
 |Scenario | v1 | v2 |
 | --- | --- | --- |
-| When an FQDN or SNI is configured | Set as FQDN from the backend pool. As per [RFC 6066](https://tools.ietf.org/html/rfc6066), literal IPv4 and IPv6 addresses aren't permitted in SNI hostname. | The SNI value is set based on the [TLS validation type](configuration-http-settings.md?tabs=backendhttpsettings#backend-https-validation-settings) in the Backend Settings.<br><br> 1. **Complete validation** – The probes uses the SNI in the following order of precedence:<br> a) Custom Health Probe's hostname <br> b) Backend Setting's hostname (as per Overridden value or Pick from backend server) <br><br> 2.	**Configurable** <br> Use specific SNI: The probes use this fixed hostname for validation.<br> Skip SNI: No Subject Name validation.
+| When an FQDN or SNI is configured | Set as FQDN from the backend pool. As per [RFC 6066](https://tools.ietf.org/html/rfc6066), literal IPv4 and IPv6 addresses aren't permitted in SNI hostname. | The SNI value is set based on the [TLS validation type](configuration-http-settings.md?tabs=backendhttpsettings#backend-https-validation-settings) in the Backend Settings.<br><br> 1. **Complete validation** – The probe uses the SNI in the following order of precedence:<br> a) Custom Health Probe's hostname <br> b) Backend Setting's hostname (as per Overridden value or Pick from backend server) <br><br> 2.	**Configurable** <br> Use specific SNI: The probes use this fixed hostname for validation.<br> Skip SNI: No Subject Name validation.
 | When an FQDN or SNI is NOT configured (only IP address is available)  | SNI (server_name) won’t be set. <br> **Note:** In this case, the backend server should be able to return a default/fallback certificate and this should be allow-listed in HTTP settings under authentication certificate. If there’s no default/fallback certificate configured in the backend server and SNI is expected, the server might reset the connection and will lead to probe failures | If the Custom Probe or Backend Settings use an IP address in the hostname field, the SNI is not set, in accordance with [RFC 6066](https://tools.ietf.org/html/rfc6066). This includes cases where the default probe uses 127.0.0.1. |
 
 #### For live traffic

articles/backup/backup-azure-arm-userestapi-createorupdatepolicy.md

@@ -2,7 +2,7 @@
 title: Create backup policies via REST API in Azure Backup
 description: In this article, you'll learn how to create and manage backup policies (schedule and retention) using REST API.
 ms.topic: how-to
-ms.date: 02/25/2025
+ms.date: 02/16/2026
 ms.assetid: 5ffc4115-0ae5-4b85-a18c-8a942f6d4870
 ms.service: azure-backup
 ms.custom: engagement-fy24
@@ -16,7 +16,7 @@ This article describes how to create policies for the backup of Azure VM, SQL da
 
 Learn more about [creating or modifying a backup policy for an Azure Recovery Services vault by using REST API](/rest/api/backup/protection-policies/create-or-update). 
 
-## Create or update a policy
+## Create or update a policy in Azure Recovery Services vault
 
 To create or update an Azure Backup policy, use the following *PUT* operation.
 
@@ -26,7 +26,7 @@ PUT https://management.azure.com/Subscriptions/{subscriptionId}/resourceGroups/{
 
 The `{policyName}` and `{vaultName}` are provided in the URI. Additional information is provided in the request body.
 
-## Create the request body
+## Create the request body for Azure VM backup policy
 
 If you want to create a policy for Azure VM backup, the request body needs to have the following components:
 
@@ -685,7 +685,7 @@ This policy:
 
 ---
 
-## Responses
+## Responses for backup policy creation or update
 
 The backup policy creation/update is a [asynchronous operation](../azure-resource-manager/management/async-operations.md). It means this operation creates another operation that needs to be tracked separately.
 

articles/backup/backup-azure-backup-faq.yml

@@ -4,7 +4,7 @@ metadata:
   description: 'Answers to common questions about'
   ms.topic: faq
   ms.service: azure-backup
-  ms.date: 01/07/2025
+  ms.date: 01/07/2026
   author: AbhishekMallick-MS
   ms.author: v-mallicka
   ms.custom: engagement-fy24

articles/backup/tutorial-configure-backup-aks.md

@@ -2,7 +2,7 @@
 title: "Tutorial: Configure item-level backup for an Azure Kubernetes Service cluster"
 description: Learn how to configure backup for an Azure Kubernetes Service (AKS) cluster, and use Azure Backup to back up specific items from the cluster.
 ms.topic: tutorial
-ms.date: 01/21/2025
+ms.date: 01/09/2026
 ms.service: azure-backup
 ms.custom:
   - ignite-2023

articles/frontdoor/front-door-faq.yml

@@ -127,6 +127,10 @@ sections:
           Can AFD provide protection from ‘HTTP/2 Rapid Reset’ DDoS attacks?
         answer:  |
           Yes. For more information, see [Microsoft response to DDoS attacks against HTTP/2](front-door-ddos.md).
+      - question: |
+          Can I force traffic from one country/region to use a specific Azure Front Door POP in another country/region?
+        answer:  |
+          No. Azure Front Door can't force client traffic to a specific POP. Requests are routed to the nearest available edge location for performance and reliability. If you need to restrict access by geography, use Azure Web Application Firewall (WAF) custom rules with `GeoMatch` conditions. This approach allows or blocks requests based on client country/region, but it doesn't reroute those clients to a different POP in another country/region. For example, if you block country/region A, requests from clients in country/region A are blocked regardless of which POP would have served them. For more information, see [Geo-filtering in Azure WAF for Azure Front Door](../web-application-firewall/afds/waf-front-door-geo-filtering.md).
       - question: |
           Does Azure Front Door preserve `x-forwarded-for` headers?
         answer: |
@@ -138,6 +142,21 @@ sections:
         answer:  |
           To use Azure Front Door Standard, or (classic) tier, you need a public IP or a DNS name that can be resolved publicly. This requirement of a public IP or a DNS name that can be resolved publicly allows Azure Front Door to route traffic to your backend resources. You can use Azure resources like Application Gateways or Azure Load Balancers to route traffic to resources in a virtual network. If you use Front Door Premium tier, you can use Private Link to connect to origins behind an internal load balancer with a private endpoint. For more information, see [Secure origins with Private Link](private-link.md).
 
+      - question: |
+          Can I use Private Link to connect Azure Front Door to Azure Key Vault?
+        answer: |
+          No. For security, Azure Front Door supports only managed identity-based authentication when accessing certificates in Key Vault. For more information, see [Use managed identities in Azure Front Door](managed-identity.md).
+
+      - question: |
+          Does Azure Front Door support managed identity with Azure Event Hub?
+        answer: |
+          No. Azure Front Door doesn't currently support managed identity integration with Azure Event Hub.
+
+      - question: |
+          Does Azure Front Door support custom error pages?
+        answer: |
+          No. Azure Front Door doesn't currently support custom error pages.
+
   - name: Deploying Front Door with other services
     questions:
       - question: |
@@ -244,7 +263,7 @@ sections:
       - question: |
            Azure Front Door Privatelink integration is not supported in the region where my origin is located. What do I do?
         answer:  |   
-           Azure Front Door Private Link feature is region agnostic and will work even if you choose a region that is different from the region where your origin is located. In such cases, to ensure lower latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. We are in the process of enabling support for more regions. Once a new region is supported, you can follow these [instructions](blue-green-deployment.md) to gradually shift traffic to the new region.
+          The Azure Front Door Private Link feature is region agnostic but for the best latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. If your origin's region isn't supported in the list of regions Front Door Private Link supports, pick the next nearest region. Traffic flows from the client to the Azure Front Door Private Link endpoint in the supported region, then traverses the Microsoft backbone network to your origin, maintaining private connectivity. Be aware that this configuration introduces additional latency due to the extra network hop between regions. You can use [Azure network round-trip latency statistics](../networking/azure-network-latency.md) to determine the additional latency due to choosing the next nearest region.  Once a new region is supported, you can follow these [instructions](blue-green-deployment.md) to gradually shift traffic to the new region.
 
   - name: Performance
     questions:

articles/frontdoor/private-link.md

@@ -72,7 +72,12 @@ Azure Front Door private link is available in the following regions:
 | US Sec East | | | | |
 | US Sec West | | | | |
 
-The Azure Front Door Private Link feature is region agnostic but for the best latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. If your origin's region isn't supported in the list of regions Front Door Private Link supports, pick the next nearest region. You can use [Azure network round-trip latency statistics](../networking/azure-network-latency.md) to determine the next nearest region in terms of latency. We are in the process of enabling support for more regions. Once a new region is supported, you can follow these [instructions](blue-green-deployment.md) to gradually shift traffic to the new region.
+> [!NOTE]
+> Azure Front Door Private Link is only available in regions with Availability Zone support. This is to ensure zonal resiliency for region based feature like Private link.
+
+The Azure Front Door Private Link feature is region agnostic but for the best latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. If your origin's region isn't supported in the list of regions Front Door Private Link supports, pick the next nearest region. Traffic flows from the client to the Azure Front Door Private Link endpoint in the supported region, then traverses the Microsoft backbone network to your origin, maintaining private connectivity. Be aware that this configuration introduces additional latency due to the extra network hop between regions.
+
+You can use [Azure network round-trip latency statistics](../networking/azure-network-latency.md) to determine the additional latency due to choosing the next nearest region.  Once a new region is supported, you can follow these [instructions](blue-green-deployment.md) to gradually shift traffic to the new region.
 
 ## Association of a private endpoint with an Azure Front Door profile
 

articles/hdinsight/hdinsight-with-entra-authentication/manage-entra-id-enabled-azure-hdinsight-clusters-with-arm-templates.md

@@ -264,6 +264,27 @@ To create a Microsoft.HDInsight/clusters resource, add the following JSON to you
 				  }
 				}
 ```
+## Troubleshooting
+
+### Issue
+The problem occurs with the restAuthEntraUsers value in the gateway configuration. Azure Resource Manager (ARM) treats any string that starts with [ as an ARM expression. As a result, when ARM encounters the JSON array value, it attempts to interpret it as an ARM function, which causes the deployment to fail.
+
+### Resolution
+To prevent ARM from interpreting the value as an expression, escape the opening bracket by using [[ instead of [. This forces ARM to treat the value as a literal string and pass it through correctly to HDInsight.
+
+### Example
+Before (deployment fails):
+```json
+	"restAuthEntraUsers": "[{\"displayName\":\"John Doe\",\"objectId\":\"<Object ID>\",\"upn\":\"[email protected]\"},{\"displayName\":\"Jane Doe\",\"objectId\":\"<Object ID>\",\"upn\":\"[email protected]\"},{\"displayName\":\"abc\",\"objectId\":\"<Object ID>\",\"upn\":\"[email protected]\"}]"
+```
+
+After (deployment succeeds):
+
+```json
+"restAuthEntraUsers": "[[{\"displayName\":\"John Doe\",\"objectId\":\"<Object ID>\",\"upn\":\"[email protected]\"},{\"displayName\":\"Jane Doe\",\"objectId\":\"<Object ID>\",\"upn\":\"[email protected]\"},{\"displayName\":\"abc\",\"objectId\":\"<Object ID>\",\"upn\":\"[email protected]\"}]"
+```
+> [!NOTE]
+> The only required change is the additional "[" at the beginning of the value.
 
 ## Property Values
 

articles/migrate/best-practices-least-privileged-account.md

@@ -19,6 +19,9 @@ The Azure Migrate appliance is a lightweight tool that discovers on-premises ser
 
 To use these features, you add server and guest credentials in the appliance configuration manager. Following the principle of least privilege helps keep the setup secure and efficient.
 
+>[!IMPORTANT]
+> In addition to configuring least‑privileged credentials for the Azure Migrate appliance, ensure that users are assigned the appropriate Azure Migrate built‑in roles in Azure. These roles provide the minimum required permissions for discovery, assessment, and migration activities. [Learn more](prepare-azure-accounts.md).
+
 ## Discovery of the VMware estate
 
 To discover the basic settings of servers running in the VMware estate, you need the following permissions.

articles/migrate/create-project.md

@@ -27,8 +27,10 @@ Ensure you have the correct permissions to create a project using the following
 
 1. In the Azure portal, open the relevant subscription, and select **Access control (IAM)**.
 2. In **Check access**, find the relevant account, and select it and view permissions. You should have *Azure Migrate Owner* or a role with higher permissions. [Learn more](prepare-azure-accounts.md). 
- > [!Note]
- > Starting November 2025, only users assigned the **Azure Migrate Owner** or a higher privileged role will be able to create Azure Migrate projects. Users without these role assignments will no longer have the required permissions to create new projects.
+
+ > [!NOTE]
+ > - Starting November 2025, only users assigned the **Azure Migrate Owner** or a higher privileged role will be able to create Azure Migrate projects. Users without these role assignments will no longer have the required permissions to create new projects.
+> - For the required Azure Migrate built‑in roles and permission details to create a project and run discovery, assessments, and migrations, see [Prepare Azure accounts for Azure Migrate](prepare-azure-accounts.md).
 
 ::: moniker range="migrate"
 

articles/migrate/discovered-metadata.md

@@ -298,6 +298,8 @@ Published date | `apt-get -s dist-upgrade, yum -q check-update, zypper list-upda
 
 > [!NOTE]
 > If your Red Hat Enterprise Linux (RHEL) servers use `yum` and aren't patched regularly, pending updates data can consume storage in the cache under `var\tmp\yum\-<username>`. To manage disk space, it is recommended to clear the cache regularly.
+>
+> To disable discovery of pending updates, visit 'HKLM:\SOFTWARE\Microsoft\AzureAppliance' and set the registry of type 'REG_DWORD EnablePendingUpdatesDiscovery' to 0. You must restart the appliance after setting the registry to ensure changes are reflected. To re-enable discovery of pending updates, set the registry 'EnablePendingUpdatesDiscovery' to 1.
 
 ## SQL Server instance and database data