Merge pull request #310248 from MicrosoftDocs/main

Auto Publish – main to live - 2026-01-08 06:00 UTC

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

articles/api-management/api-management-howto-manage-protocols-ciphers.md

@@ -1,12 +1,12 @@
 ---
-title: Manage protocols and ciphers in Azure API Management | Microsoft Learn
+title: Manage Protocols and Ciphers in Azure API Management
 description: Learn how to manage transport layer security (TLS) protocols and cipher suites in Azure API Management.
 services: api-management
 author: dlepow
 
 ms.service: azure-api-management
 ms.topic: how-to
-ms.date: 10/10/2025
+ms.date: 01/06/2026
 ms.author: danlep
 ---
 
@@ -41,7 +41,7 @@ API Management supports TLS versions up to TLS 1.3 for client and backend connec
 
 ## How to manage TLS protocols and cipher suites
 
-1. In the sidebar of your API Management instance, under **Security**, select **Protocols + ciphers**.  
+1. In the sidebar menu of your API Management instance, under **Security**, select **Protocols + ciphers**.  
 1. Enable or disable desired protocols or ciphers.
 1. Select **Save**.
 
@@ -58,7 +58,7 @@ TLS 1.3 is a major revision of the TLS protocol that provides improved security
 
 TLS 1.3 doesn't support certificate renegotiation. Certificate renegotiation in TLS allows client and server to renegotiate connection parameters mid-session for authentication without terminating the connection.
 
-Services that API Management identifies as reliant on client certificate renegotiation do not have TLS 1.3 enabled by default. You can choose to enable TLS 1.3 manually. 
+API Management instances that are detected as reliant on client certificate renegotiation do not have TLS 1.3 enabled by default. In these instances, you can choose to enable TLS 1.3 manually. 
 
 > [!WARNING]
 > If your APIs are accessed by TLS-compliant clients that rely on certificate renegotiation, enabling TLS 1.3 for client-side connections will cause those clients to fail to connect. Review APIs that recently used certificate renegotiation before enabling client-side TLS 1.3 in any service that doesn't have it enabled by default.

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

@@ -21,9 +21,16 @@ The gateway in API Management services created on or after 1 December 2025 no lo
 
 ## Is my service affected by this change?
 
+Trusted service connectivity retirement affects scenarios where the API Management gateway needs to communicate with Azure Storage, Key Vault, Key Vault Managed HSM, Service Bus, Event Hubs, or Container Registry services when they're configured as backends or accessed through policies such as `send-request`.
+
+> [!IMPORTANT]
+> Trusted service connectivity remains supported for API Management control plane operations. The following scenarios continue to work without changes when using trusted service connectivity:
+> - Accessing Azure Storage for backup and restore
+> - Accessing Azure Key Vault for managing named values, backend credentials, or custom hostname certificates
+
 First, check for an Azure Advisor recommendation:
 
-1. In the Azure portal, go to [Advisor](https://ms.portal.azure.com/#view/Microsoft_Azure_Expert/AdvisorMenuBlade/~/overview)
+1. In the Azure portal, go to [Advisor](https://ms.portal.azure.com/#view/Microsoft_Azure_Expert/AdvisorMenuBlade/~/overview).
 1. Select the **Recommendations > Operational excellence** category.
 1. Search for "**Disable trusted service connectivity in API Management**".
 

articles/azure-netapp-files/create-short-term-clone.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-ahibbard
 ms.service: azure-netapp-files
 ms.topic: how-to
-ms.date: 10/09/2025
+ms.date: 01/08/2026
 ms.author: anfdocs
 ---
 # Create a short-term clone volume in Azure NetApp Files 
@@ -36,26 +36,6 @@ By default, short-term clones convert to regular volumes after 32 days.
 * During the clone operation, the parent volume is accessible; you can capture new snapshots of the parent volume. 
 * You can create five short-term clones per regular volume.
 
-## Register the feature
-
-To take advantage of the feature, you must first register it. 
-
-1. Register the feature:
-
-    ```azurepowershell-interactive
-    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFShortTermClone
-    ```
-
-1. Registration for short-term clones isn't automatic and may take up to a week. Check the registration status with the command: 
-
-    ```azurepowershell-interactive
-    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFShortTermClone
-    ```
-
-    When the `RegistrationState` field output displays "Registered", you can create a short-term clone. 
-
-    You can also use [Azure CLI commands](/cli/azure/feature) `az feature register` and `az feature show` to register the feature and display the registration status. 
-
 ## Create a short-term clone
 
 >[!NOTE]

articles/azure-netapp-files/migrate-volumes.md

@@ -5,7 +5,7 @@ services: azure-netapp-files
 author: b-ahibbard
 ms.service: azure-netapp-files
 ms.topic: how-to
-ms.date: 11/05/2025
+ms.date: 01/08/2026
 ms.author: anfdocs
 ---
 # Migrate volumes to Azure NetApp Files 
@@ -22,7 +22,8 @@ With Azure NetApp Files' migration assistant, you can peer and migrate volumes f
 * The delegated subnet address space should be sized appropriately to accommodate more Azure NetApp Files network interfaces. Review [Guidelines for Azure NetApp Files network planning](azure-netapp-files-network-topologies.md) to ensure you meet the requirements for delegated subnet sizing. 
 * With the migration assistant, Azure NetApp Files volumes must be using Standard networking features. For more information about setting network features, see [Configure network features](configure-network-features.md).
 * After issuing the peering request, the request must be accepted within 60 minutes. Peer requests expire if not accepted within 60 minutes.
-* You should complete migrations from a single source cluster using one Azure subscription before migrating volumes destined for another subscription. Cluster peering fails when using a second Azure subscription and the same external source clusters. 
+* You should complete migrations from a single source cluster using one Azure subscription before migrating volumes destined for another subscription. Cluster peering fails when using a second Azure subscription and the same external source clusters.
+* You should ensure that the earlier cluster peering request are deleted and are not displaying on the source cluster before initiating a new cluster peering request.
 * If you use Azure RBAC to separate the role of Azure NetApp Files storage management with the intention of separating volume management tasks where volumes reside on the same network sibling set, be aware that externally connected ONTAP systems peered to that sibling set don't adhere to these Azure-defined roles. The external storage administrator might have limited visibility to all volumes in the sibling set showing storage level metadata details.
 * When creating each migration volume, the Azure NetApp Files volume placement algorithm attempts to reuse the same Azure NetApp Files storage system as any previously created volumes in the subscription to reduce the number of network interface cards (NICs) or IPs consumed in the delegated subnet. If this isn't possible, an additional seven NICs are consumed.
 * You should ensure that there are no external FlexGroup volumes as they can't be migrated to Azure NetApp Files large volumes.

articles/communication-services/how-tos/calling-sdk/active-call-transfer.md

@@ -19,8 +19,6 @@ ms.custom: template-how-to
 
 During an active call, you may want to transfer the call to device that you are signed in on. Let's learn how. 
 
-
-
 ## Prerequisites
 
 - An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/pricing/purchase-options/azure-account?cid=msft_learn). 

articles/communication-services/how-tos/calling-sdk/includes/active-call-transfer/active-call-transfer.md

@@ -9,29 +9,47 @@ ms.author: dmceachern
 [!INCLUDE [Install SDK](../install-sdk/install-sdk-web.md)]
 
 ## Active Call Management
-Active Call Transfer is a feature of the core `CallAgent` API. This guide talks about how you can manage and track any ongoing calls for your users and how to transfer their client to that active call.
+Active Call Transfer is a feature of the `CallAgent` on its `feature` API. This guide talks about how you can manage and track any ongoing calls for your users and how to transfer their client to that active call.
 
-**Note:** This feature is also enabled for the `TeamsCallAgent` as this feature is supported for Teams users as well.
+> [!NOTE] 
+> This feature is also enabled for the `TeamsCallAgent` as this feature is supported for Teams users as well. This feature is not supported for [Teams Phone Extensibility](../../../../quickstarts/tpe/teams-phone-extensibility-quickstart.md) users.
 
 This guide assumes you went through the QuickStart or that you implemented an application that is able to make and receive calls. If you didn't complete the getting starting guide, refer to our [Quickstart](../../../../quickstarts/voice-video-calling/getting-started-with-calling.md).
 
-### Fetch your Active Call
+### Create CallAgentFeature for Active Call Transfer
 
-When your user signs to the `CallAgent` there is a new method that you can use to fetch the ongoing calls `getActiveCallDetails` the response will return to you the active call, or active meeting that your users are in.
+The first thing you need to do when setting up Active Call Transfer is you need to create the `CallAgentFeature` for it. Creating this feature does the setup needed to start using the underlying APIs for the functionality of Active Call Transfer. It also holds all the functions and events for Active Call Transfer. 
 
 ```js
-const activeCallDetails = await callAgent.getActiveCallDetails();
+const activeCallTransferFeature = callAgent.feature(ActiveCallTransfer);
 ```
 
-The function `getActiveCallDetails` a way that you can manually query for this data. Once you have the active call details, you can use it to switch the client to the call that was found. This function returns `undefined` if there is no active call ongoing for your user. You can use `getActiveCallDetails` to fetch any ongoing calls when you first sign into the `CallAgent` to pick up on any calls that are already ongoing.
+### Fetch your Active Calls
+
+After you create the feature API, there is a method that you can use to fetch the ongoing calls `getActiveCallDetails`. The response returns the active calls, or active meetings that your users are in.
+
+```js
+const activeCallTransferFeature = callAgent.feature(ActiveCallTransfer);
+const activeCallDetails = await activeCallTransferFeature.getActiveCallDetails();
+```
+
+The function `getActiveCallDetails` is a way that you can manually query for this data. Once you have the active call details, you can use it to switch the client to any of the calls that were found. If there are ongoing calls this returns an array of `ActiveCallDetails` and `ActiveMeetingDetails`. To be considered in an active call the user can also be in a call that is on hold. This function returns `undefined` if there is no active call ongoing for your user. Best practice is to use `getActiveCallDetails` to fetch any ongoing calls when you first sign into the `CallAgent` to pick up on any calls that are already ongoing.
 
 ### Switch your Active Call
 
-Once you have your active call data, you can switch the client over to the new call. This call switching behavior can be done with the `activeCallTransfer` function.
+Once you have your active call data, you can switch the client over to the new call. This call switching behavior can be done with the `activeCallTransfer` function. Here you can also pass in your `joinCallOptions` to choose the [device configuration](../../../../how-tos/calling-sdk/manage-video.md) of the joining client.
+
+> [!NOTE] 
+> When transferring a client that is already in a call to a different call it is important to make sure you put the ongoing call for the client on hold before initiating the transfer.
 
 ```js
-const activeCallDetails = await callAgent.getActiveCallDetails();
-const call = await callAgent.activeCallTransfer(activeCallDetails, {isTransfer: true});
+const joinCallOptions = {
+    audioOptions: { isMuted: false },
+    videoOptions: { localVideoStreams: [yourLocalVideoStream]}
+}
+const activeCallTransferFeature = callAgent.feature(ActiveCallTransfer);
+const activeCallDetails = await activeCallTransferFeature.getActiveCallDetails();
+const call = await activeCallTransferFeature.activeCallTransfer(activeCallDetails[0], {isTransfer: true, joinCallOptions});
 ```
 
 This function returns the call object for your applications state.
@@ -41,24 +59,27 @@ This function returns the call object for your applications state.
 When transferring the active call to your client, you can just bring the client into the call without hanging up on the device that initiated the call the user is in.
 
 ```js
-const activeCallDetails = await callAgent.getActiveCallDetails();
-const call = await callAgent.activeCallTransfer(activeCallDetails, {isTransfer: false}); // <-- isTransfer: false - does not remove the original client. 
+const activeCallTransferFeature = callAgent.feature(ActiveCallTransfer);
+const activeCallDetails = await activeCallTransferFeature.getActiveCallDetails();
+const call = await activeCallTransferFeature.activeCallTransfer(activeCallDetails[0], { isTransfer: false }); // <-- isTransfer: false - does not remove the original client. 
 ```
 
 ### Subscribe to Active Call Notification events
 
-There are two new events that you can subscribe to so you can receive events notifying you of your user joining a call on another client. The first event notifies the application that the user is in a call on another device. This event is also emitted when the user logs into the `CallAgent` if they are on a call already elsewhere.
+There are two new events that you can subscribe to so you can receive events notifying you of your user joining a call on another client. The first event `"activeCallsUpdated"` notifies the application that the user is in a call on another device. Since the feature needs to be initialized to get these events best practice is to manually fetch the active calls after creating the `CallAgent` with `getActiveCallDetails`. The third case where this event fires is when a call ends for the user but they are still in another call. In all of the cases the event fires it returns an array of `ActiveCallDetails` and `ActiveMeetingDetails` representing the calls that the user is in. 
 
 ```js
-callAgent.on("activeCallsUpdated", (args) => {
+const activeCallTransferFeature = callAgent.feature(ActiveCallTransfer);
+activeCallTransferFeature.on("activeCallsUpdated", (args) => {
     // show UI indicating that the user is in another call on another device
-    await callAgent.activeCallTransfer(args.activeCallDetails, {isTransfer: true});
+    await activeCallTransferFeature.activeCallTransfer(args.activeCallDetails[0], { isTransfer: true });
 });
 ```
-The second event notifies the application that the user is no longer in an active call anywhere else. This event is to be used to hide any UI indicating that they are in a call elsewhere, and any controls to manually transfer the call over.
+The second event `"NoActiveCalls"` notifies the application that the user is no longer in an active call anywhere else. This event is to be used to hide any UI indicating that they are in a call elsewhere, and any controls to manually transfer the call over.
 
 ```js
-callAgent.on("NoActiveCalls", () => {
+const activeCallTransferFeature = callAgent.feature(ActiveCallTransfer);
+activeCallTransferFeature.on("NoActiveCalls", () => {
     // hide UI indicating that the user is in a call elsewhere
 });
 ```

articles/frontdoor/end-to-end-tls.md

@@ -101,7 +101,6 @@ For the Azure Front Door Standard/Premium managed certificate option, the certif
 
 > [!IMPORTANT]
 > - For Azure Front Door Classic and Azure CDN Classic, managed certificates will no longer be supported starting August 15, 2025. To avoid service disruption, either switch to **Bring Your Own Certificate (BYOC)** or migrate to Azure Front Door Standard/Premium before this date. Existing managed certificates will continue to autorenew until August 15, 2025, and remain valid until April 14, 2026. However, it's highly recommended to switch to **BYOC** or migrate to Front Door Standard/Premium before August 15, 2025, to avoid unexpected certificate revocation.
-> - Auto-rotation for managed certificates fails if your domains don't have direct CNAME mapping to Azure Front Door Classic or Azure CDN Classic endpoints. See [Azure CDN Classic HTTPS for custom domains](/azure/cdn/cdn-custom-ssl?tabs=option-1-default-enable-https-with-a-cdn-managed-certificate#tlsssl-certificates) and [Azure Front Door Classic HTTPS for custom domains](/azure/frontdoor/front-door-custom-domain-https?tabs=powershell#option-1-default-use-a-certificate-managed-by-front-door).
 > - Azure Front Door (AFD) Standard and Premium use DigiCert‑issued managed TLS certificates, and DigiCert is retiring the G1 root certificate that expires on April 14, 2026, replacing it with the G2 root certificate. Azure Front Door will automatically rotate AFD‑managed certificates before expiration for custom domains that directly CNAME to the Azure Front Door endpoint, and no customer action is required. Customers whose domains do not directly CNAME to Azure Front Door must manually rotate their certificates to use the DigiCert G2 root certificate before April 14, 2026 to avoid TLS connectivity issues.
 
 For your own custom TLS/SSL certificate:
@@ -111,7 +110,7 @@ For your own custom TLS/SSL certificate:
 1. If a specific version is selected, autorotation isn’t supported. You'll have to reselect the new version manually to rotate certificate. It takes up to 24 hours for the new version of the certificate/secret to be deployed.
 
     > [!NOTE]
-    > Azure Front Door (Standard and Premium) managed certificates are automatically rotated if the domain CNAME record points directly to a Front Door endpoint or points indirectly to a Traffic Manager endpoint. Otherwise, you need to re-validate the domain ownership to rotate the certificates.
+    > Azure Front Door (AFD) Standard and Premium automatically rotate managed certificates only when the custom domain CNAME points directly to the AFD endpoint; for indirect CNAME configurations, we strongly recommend using a bring‑your‑own certificate, as AFD will attempt domain validation via file‑based token validation when traffic reaches AFD but successful validation is not guaranteed.
  
     The service principal for Front Door must have access to the key vault. The updated certificate rollout operation by Azure Front Door won't cause any production downtime, as long as the subject name or subject alternate name (SAN) for the certificate hasn't changed.