Merge pull request #309779 from MicrosoftDocs/main

Auto Publish – main to live - 2025-12-19 18:00 UTC

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

articles/api-management/api-management-howto-disaster-recovery-backup-restore.md

@@ -7,7 +7,7 @@ author: dlepow
 
 ms.service: azure-api-management
 ms.topic: how-to
-ms.date: 12/05/2025
+ms.date: 12/18/2025
 ms.author: danlep 
 ms.custom: devx-track-azurepowershell
 ---
@@ -29,7 +29,7 @@ This article shows how to automate backup and restore operations of your API Man
 > Each backup expires after 30 days. If you attempt to restore a backup after the 30-day expiration period has expired, the restore will fail with a `Cannot restore: backup expired` message.
 
 > [!IMPORTANT]
-> Restore operation doesn't change custom hostname configuration of the target service. We recommend to use the same custom hostname and TLS certificate for both active and standby services, so that, after restore operation completes, the traffic can be re-directed to the standby instance by a simple DNS CNAME change.
+> Restore operation doesn't change custom hostname configuration of the target service. We recommend using the same custom hostname and TLS certificate for both active and standby services, so that, after restore operation completes, the traffic can be re-directed to the standby instance by a simple DNS CNAME change.
 
 
 [!INCLUDE [updated-for-az](~/reusable-content/ce-skilling/azure/includes/updated-for-az.md)]
@@ -399,18 +399,7 @@ Restore is a long-running operation that may take several minutes to complete. I
 ## Storage networking constraints
 
 
-If the storage account is **[firewall][azure-storage-ip-firewall] enabled**, it's recommended to use the API Management instance's system-assigned managed identity for access to the account. Ensure that you have networking line of sight from API Management. Configure one of the following network access options on the resource:
-
-- Allow public access from all networks.
-
-- Set a network security rule to allow API Management traffic based on the IP address or virtual network connectivity.
-
-- Secure traffic from API Management with Private Link connectivity.
-
-- Use a [network security perimeter](/azure/private-link/network-security-perimeter-concepts#onboarded-private-link-resources) to secure the resource and allow traffic from API Management. 
-
-> [!IMPORTANT]
-> Starting March 2026, trusted service connectivity to Azure services from API Management by enabling the **Allow Trusted Microsoft Services to bypass this firewall** firewall setting will no longer be supported. To continue accessing these services from API Management after this change, ensure that you choose a supported network access option as described above. [Learn more](breaking-changes/trusted-service-connectivity-retirement-march-2026.md)
+If the storage account is **[firewall][azure-storage-ip-firewall] enabled**, it's recommended to use the API Management instance's system-assigned managed identity for access to the account. Ensure that the storage account [grants access to trusted Azure services](../storage/common/storage-network-security.md?tabs=azure-portal#grant-access-to-trusted-azure-services).
 
 ## What is not backed up
 -   **Usage data** used for creating analytics reports **isn't included** in the backup. Use [Azure API Management REST API][azure api management rest api] to periodically retrieve analytics reports for safekeeping.

articles/api-management/api-management-howto-use-managed-service-identity.md

@@ -6,7 +6,7 @@ author: dlepow
 
 ms.service: azure-api-management
 ms.topic: how-to
-ms.date: 05/19/2025
+ms.date: 12/18/2025
 ms.author: danlep
 ms.custom:
   - devx-track-azurepowershell
@@ -314,27 +314,17 @@ You can use the system-assigned identity to authenticate to a backend service vi
 
 ### Connect to Azure resources behind an IP firewall by using a system-assigned managed identity
 
-For certain scenarios, API Management can communicate with resources in the following services using a system-assigned managed identity configured with an appropriate role assignment:
+API Management is a trusted Microsoft service to the following resources. This trusted status enables the service to connect to the following resources behind a firewall when the firewall enables a setting to **Allow Trusted Microsoft Services to bypass this firewall**. After you explicitly assign the appropriate Azure role to the [system-assigned managed identity](../active-directory/managed-identities-azure-resources/overview.md) for a resource instance, the scope of access for the instance corresponds to the Azure role that's assigned to the managed identity.
 
-- Azure Key Vault
-- Azure Storage
-- Azure Service Bus
-- Azure Event Hubs
-- Azure Container Registry
-- Azure Managed HSM
 
-For resources in these services that are protected by an IP firewall, ensure that you have networking line of sight from API Management. Configure one of the following network access options on the resource:
+- [Trusted access for Key Vault](/azure/key-vault/general/overview-vnet-service-endpoints#trusted-services)
+- [Trusted access for Azure Storage](../storage/common/storage-network-security-trusted-azure-services.md?tabs=azure-portal#trusted-access-based-on-system-assigned-managed-identity)
+- [Trusted access for Azure Service Bus](../service-bus-messaging/service-bus-ip-filtering.md#trusted-microsoft-services)
+- [Trusted access for Azure Event Hubs](../event-hubs/event-hubs-ip-filtering.md#trusted-microsoft-services)
 
-- Allow public access from all networks.
-
-- Set a network security rule to allow API Management traffic based on the IP address or virtual network connectivity.
-
-- Secure traffic from API Management with Private Link connectivity.
-
-- Use a [network security perimeter](/azure/private-link/network-security-perimeter-concepts#onboarded-private-link-resources) to secure the resource and allow traffic from API Management. 
 
 > [!IMPORTANT]
-> Starting March 2026, trusted service connectivity to Azure services from API Management by enabling the **Allow Trusted Microsoft Services to bypass this firewall** firewall setting will no longer be supported. To continue accessing these services from API Management after this change, ensure that you choose a supported network access option as described above. [Learn more](breaking-changes/trusted-service-connectivity-retirement-march-2026.md)
+> Starting March 2026, trusted service connectivity to Azure services from the API Management gateway by enabling the **Allow Trusted Microsoft Services to bypass this firewall** firewall setting will no longer be supported. To continue accessing these services from the API Management gateway after this change, ensure that you choose a different supported network access option. For control-plane operations, you can continue to use trusted service connectivity. [Learn more](breaking-changes/trusted-service-connectivity-retirement-march-2026.md).
 
 ### Log events to an event hub
 

articles/api-management/backends.md

@@ -118,6 +118,9 @@ To add CA certificate details, follow these steps:
 > [!NOTE]
 > When you configure details of a custom CA certificate in the backend entity, API Management always validates the certificate name and certificate chain, regardless of whether you enable or disable validation settings in the backend's `backendTlsProperties`.
 
+> [!TIP]
+> You can also configure CA certificate details programmatically by using the API Management REST API. Set the `backendTlsProperties` in the [backend entity](/rest/api/apimanagement/backend/create-or-update?view=rest-apimanagement-2025-03-01-preview&preserve-view=true#backendtlsproperties).
+
 ## Reference backend using set-backend-service policy
 
 After creating a backend, you can reference the backend identifier (name) in your APIs. Use the [`set-backend-service`](set-backend-service-policy.md) policy to direct an incoming API request to the backend. If you already configured a backend web service for an API, you can use the `set-backend-service` policy to redirect the request to a backend entity instead. For example:

articles/api-management/breaking-changes/trusted-service-connectivity-retirement-march-2026.md

@@ -1,10 +1,10 @@
 ---
 title: Azure API Management - Trusted service connectivity retirement (March 2026)
-description: Azure API Management is retiring trusted service connectivity to supported Azure services as of March 2026. Use alternative networking options for secure connectivity.
+description: Azure API Management is retiring trusted service connectivity by the gateway to supported Azure services as of March 2026. Use alternative networking options for secure connectivity.
 #customer intent: As an Azure admin, I want to determine if my API Management service is affected by the trusted service connectivity retirement so that I can plan necessary changes.
 author: dlepow
 ms.author: danlep
-ms.date: 12/05/2025
+ms.date: 12/18/2025
 ms.topic: reference
 ms.service: azure-api-management
 ai-usage: ai-assisted
@@ -15,9 +15,9 @@ ai-usage: ai-assisted
 
 [!INCLUDE [api-management-availability-all-tiers](../../../includes/api-management-availability-all-tiers.md)]
 
-Effective 15 March 2026, Azure API Management is retiring trusted service connectivity to supported Azure services - Azure Storage, Key Vault, Key Vault Managed HSM, Service Bus, Event Hub, and Container Registry. If your API Management resource relies on this feature to communicate with these services after 15 March 2026, the communication will fail. Use alternative networking options to securely connect to those services.
+Effective 15 March 2026, Azure API Management is retiring trusted service connectivity by the API Management gateway to supported Azure services - Azure Storage, Key Vault, Key Vault Managed HSM, Service Bus, Event Hubs, and Container Registry. If your API Management gateway relies on this feature to communicate with these services after 15 March 2026, the communication will fail. Use alternative networking options to securely connect to those services.
 
-API Management services created on or after 1 December 2025 no longer support trusted service connectivity. Contact Azure support if you need to enable trusted service connectivity in those services until the retirement date.
+The gateway in API Management services created on or after 1 December 2025 no longer supports trusted service connectivity. Contact Azure support if you need to enable trusted service connectivity in those services until the retirement date.
 
 ## Is my service affected by this change?
 
@@ -27,19 +27,19 @@ First, check for an Azure Advisor recommendation:
 1. Select the **Recommendations > Operational excellence** category.
 1. Search for "**Disable trusted service connectivity in API Management**".
 
-**If you don't see a recommendation**, your API Management resource isn't affected by the change.
+**If you don't see a recommendation**, your API Management gateway isn't affected by the change.
 
-**If you see a recommendation**, your API Management resource is affected by the breaking change and you need to take action: 
+**If you see a recommendation**, your API Management gateway is affected by the breaking change and you need to take action: 
 
-1. Determine if your API Management resource relies on trusted service connectivity to Azure services. 
+1. Determine if your API Management gateway relies on trusted service connectivity to Azure services. 
 1. If it does, update the networking configuration to eliminate the dependency on trusted service connectivity. If it doesn’t, proceed to the next step. 
-1. Disable trusted service connectivity in API Management. 
+1. Disable trusted service connectivity in your API Management gateway. 
 
-### Step 1: Does my API Management resource rely on trusted service connectivity? 
+### Step 1: Does my API Management gateway rely on trusted service connectivity? 
 
-API Management should no longer rely on trusted service connectivity to Azure services. Instead, it should establish a networking line of sight. 
+Your API Management gateway should no longer rely on trusted service connectivity to Azure services. Instead, it should establish a networking line of sight. 
 
-To verify if API Management relies on trusted connectivity to Azure services, check the networking configuration of all Azure Storage, Key Vault, Key Vault Managed HSM, Service Bus, Event Hub, and Container Registry resources that API Management connects to: 
+To verify if your API Management gateway relies on trusted connectivity to Azure services, check the networking configuration of all Azure Storage, Key Vault, Key Vault Managed HSM, Service Bus, Event Hubs, and Container Registry resources that your API Management gateway connects to: 
 
 #### For Storage accounts
 
@@ -72,7 +72,7 @@ To verify if API Management relies on trusted connectivity to Azure services, ch
 
 ### Step 2: Eliminate dependency on trusted service connectivity  
 
-If you verified that API Management relies on trusted connectivity to Azure resources, you need to eliminate this dependency by establishing a networking line of sight for communication from API Management to the listed services. 
+If you verified that your API Management gateway relies on trusted connectivity to Azure resources, you need to eliminate this dependency by establishing a networking line of sight for communication from API Management to the listed services. 
 
 You can configure the networking of target resources to one of the following options:
 
@@ -88,11 +88,11 @@ You can configure the networking of target resources to one of the following opt
 
   - [Transition to a Network Security Perimeter in Azure](/azure/private-link/network-security-perimeter-transition)
 
-### Step 3: Disable trusted service connectivity in API Management 
+### Step 3: Disable trusted service connectivity in API Management gateway
 
-After ensuring that API Management doesn’t access other Azure services using trusted service connectivity, you must explicitly disable trusted connectivity in your API Management service to acknowledge you have verified that the service no longer depends on trusted connectivity.
+After ensuring that your API Management gateway doesn't access other Azure services using trusted service connectivity, you must explicitly disable trusted connectivity in your gateway to acknowledge you have verified that the service no longer depends on trusted connectivity.
 
-To do so, set a custom property `Microsoft.WindowsAzure.ApiManagement.Gateway.ManagedIdentity.DisableOverPrivilegedAccess` to `"True"` on the [API Management resource](/rest/api/apimanagement/api-management-service/create-or-update). For example: 
+To do so, set a custom property `Microsoft.WindowsAzure.ApiManagement.Gateway.ManagedIdentity.DisableOverPrivilegedAccess` to `"True"` on the [API Management gateway](/rest/api/apimanagement/api-management-service/create-or-update). For example: 
 
 
 ```json
@@ -116,11 +116,11 @@ To do so, set a custom property `Microsoft.WindowsAzure.ApiManagement.Gateway.Ma
 }
 ```
 
-The Azure Advisor recommendation should disappear within a day or two of disabling the trusted connectivity on the API Management service. 
+The Azure Advisor recommendation should disappear within a day or two of disabling the trusted connectivity on the API Management gateway. 
 
 ## What is the deadline for the change?
 
-After 15 March 2026, the trusted connectivity from API Management to supported Azure services - Azure Storage, Key Vault, Key Vault Managed HSM, Service Bus, Event Hubs, and Container Registry - is retired. If your API Management resource relies on this feature to establish communication with these services, the communication will start failing after that date.
+After 15 March 2026, the trusted connectivity from the API Management gateway to supported Azure services - Azure Storage, Key Vault, Key Vault Managed HSM, Service Bus, Event Hubs, and Container Registry - is retired. If your API Management gateway relies on this feature to establish communication with these services, the communication will start failing after that date.
 
 ## Help and support
 

articles/azure-vmware/introduction.md

@@ -3,7 +3,7 @@ title: Introduction
 description: Learn the features and benefits of Azure VMware Solution to deploy and manage VMware-based workloads in Azure.
 ms.topic: overview
 ms.service: azure-vmware
-ms.date: 10/30/2025
+ms.date: 12/19/2025
 ms.custom: engagement-fy23
 ---
 
@@ -64,6 +64,21 @@ When a customer has a deployed Azure VMware Solution private cloud, they can sca
 > [!NOTE]
 > All traffic from an AV64 host towards a customer network will utilize the IP address of the VMKernel Network Interface 1.
 
+### Enhanced vMotion Compatibility (EVC) with AV64 extension
+Adding AV64 nodes to an Azure VMware Solution private cloud creates a heterogeneous environment, which results in [Enhanced vMotion Compatibility](https://knowledge.broadcom.com/external/article/313545/vmware-evc-and-cpu-compatibility-faq.html) (EVC) issues between AV64 clusters and base SKU clusters using AV36, AV36P, or AV52 SKUs. AV64 clusters use the Icelake EVC mode due to their Intel Icelake CPUs, whereas AV36, AV36P, and AV52 clusters, built on older Intel CPUs, do not have explicit EVC mode enabled. Details on CPU generations for each SKU are provided above. 
+
+The heterogeneity of EVC modes across clusters presents challenges for live vMotion operations, as defined by Broadcom, based on the specific scenario and direction of migration. The following section provides a summary of the user experience when performing live vMotion between AV64 and the base clusters. 
+
+- vMotion to AV64 cluster from Base SKU cluster – this works fine as virtual machine is vMotioned from lower EVC mode cluster to higher EVC mode cluster.
+  
+- vMotion to base SKU cluster from AV64 cluster – two scenarios
+  
+	- If virtual machine was previously moved from base cluster and not power cycled, then the live vMotion succeeds.
+   
+ 	- If virtual machine was created on AV64 cluster or power cycled, even though it was previously vMotioned from the base SKU cluster, live vMotion will fail with EVC compatibility error.
+ 
+Customers can avoid live vMotion problems between base SKU and AV64 clusters by setting the VM-level EVC mode to match a lower base cluster EVC, or by powering off the virtual machine and doing a cold vMotion.
+
 ### AV64 Cluster vSAN fault domain (FD) design and recommendations
 
 The traditional Azure VMware Solution host clusters don't have explicit vSAN FD configuration. The reasoning is the host allocation logic ensures, within clusters, that no two hosts reside in the same physical fault domain within an Azure region. This feature inherently brings resilience and high availability for storage, which the vSAN FD configuration is supposed to bring. More information on vSAN FD can be found in the [VMware documentation](https://techdocs.broadcom.com/us/en/vmware-cis/vsan/vsan/8-0/vsan-administration/expanding-and-managing-a-vsan-cluster/managing-fault-domains-in-vsan-clusters.html).