Merge pull request #310198 from MicrosoftDocs/main

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

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

articles/active-directory-b2c/aad-sspr-technical-profile.md

@@ -64,7 +64,7 @@ The **InputClaimsTransformations** element may contain a collection of **InputCl
 
 ### Output claims
 
-The Microsoft Entra SSPR protocol provider does not return any **OutputClaims**, thus there is no need to specify output claims. You can, however, include claims that aren't returned by the Microsoft Entra SSPR protocol provider as long as you set the `DefaultValue` attribute.
+The Microsoft Entra SSPR protocol provider does not return any **OutputClaims**, thus, there is no need to specify output claims. You can, however, include claims that aren't returned by the Microsoft Entra SSPR protocol provider as long as you set the `DefaultValue` attribute.
 
 The **OutputClaimsTransformations** element may contain a collection of **OutputClaimsTransformation** elements that are used to modify the output claims or generate new ones.
 

articles/active-directory-b2c/access-tokens.md

@@ -85,7 +85,7 @@ Replace the values in the query string as follows:
 
 To get a feel of how the request works, paste the request into your browser and run it. 
 
-This's the interactive part of the flow, where you take action. You're asked to complete the user flow's workflow. This might involve entering your username and password in a sign in form or any other number of steps. The steps you complete depend on how the user flow is defined.
+This is the interactive part of the flow, where you take action. You're asked to complete the user flow's workflow. This might involve entering your username and password in a sign in form or any other number of steps. The steps you complete depend on how the user flow is defined.
 
 The response with the authorization code should be similar to this example:
 

articles/api-center/export-to-copilot-studio.yml

@@ -8,6 +8,8 @@ metadata:
   ms.service: azure-api-management
   ms.topic: how-to 
   ms.date: 04/28/2025
+  ms.collection: ce-skilling-ai-copilot
+  ms.update-cycle: 180-days
   ms.custom: template-how-to
 
   #customer intent: As an API program manager, I want to export an API from my API center inventory as a connector in Microsoft Copilot Studio for use in agents.
@@ -76,4 +78,4 @@ relatedContent:
       url: /microsoft-copilot-studio/nlu-gpt-overview
 
     - text: Get started with Microsoft Copilot Studio 
-      url: /training/modules/power-virtual-agents-bots
+      url: /training/modules/power-virtual-agents-bots

articles/api-management/TOC.yml

@@ -364,6 +364,7 @@
     href: api-management-howto-ca-certificates.md
   - name: Manage protocols and ciphers
     href: api-management-howto-manage-protocols-ciphers.md
+    displayName: TLS, TLS 1.3
   - name: Protect with Defender for APIs
     href: protect-with-defender-for-apis.md
   - name: Mitigate OWASP API threats

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

@@ -6,7 +6,7 @@ author: dlepow
 
 ms.service: azure-api-management
 ms.topic: how-to
-ms.date: 08/12/2025
+ms.date: 10/10/2025
 ms.author: danlep
 ---
 
@@ -21,7 +21,7 @@ Azure API Management supports multiple versions of Transport Layer Security (TLS
 
 API Management also supports multiple cipher suites used by the API gateway.
 
-Depending on the service tier, API Management supports TLS versions up to 1.2 or TLS 1.3 for client and backend connectivity and several supported cipher suites. This guide shows you how to manage protocols and ciphers configuration for an Azure API Management instance.
+API Management supports TLS versions up to TLS 1.3 for client and backend connectivity and several supported cipher suites. This guide shows you how to manage protocols and ciphers configuration for an Azure API Management instance.
 
 :::image type="content" source="media/api-management-howto-manage-protocols-ciphers/api-management-protocols-ciphers.png" alt-text="Screenshot of managing protocols and ciphers in the Azure portal.":::
 
@@ -33,7 +33,6 @@ Depending on the service tier, API Management supports TLS versions up to 1.2 or
 > [!NOTE]
 > Depending on the API Management service tier, changes can take 15 to 45 minutes or longer to apply. An instance in the Developer service tier has downtime during the process. Instances in the Basic and higher tiers don't have downtime during the process.  
 
-
 ## Prerequisites
 
 * An API Management instance. [Create one if you haven't already](get-started-create-service-instance.md).
@@ -42,27 +41,24 @@ Depending on the service tier, API Management supports TLS versions up to 1.2 or
 
 ## How to manage TLS protocols and cipher suites
 
-1. In the left navigation of your API Management instance, under **Security**, select **Protocols + ciphers**.  
+1. In the sidebar of your API Management instance, under **Security**, select **Protocols + ciphers**.  
 1. Enable or disable desired protocols or ciphers.
 1. Select **Save**.
 
 > [!NOTE]
 > Some protocols or cipher suites (such as backend-side TLS 1.2) can't be enabled or disabled from the Azure portal. Instead, you'll need to apply the REST API call. Use the `properties.customProperties` structure in the [Create/Update API Management Service](/rest/api/apimanagement/current-ga/api-management-service/create-or-update) REST API.
 
-## TLS 1.3 support in classic tiers
+## TLS 1.3 support
 
-TLS 1.3 support is available in the API Management classic service tiers (**Consumption**, **Developer**, **Basic**, **Standard**, and **Premium**). In most instances created in those service tiers, TLS 1.3 is permanently enabled by default for client-side connections. Enabling backend-side TLS 1.3 is optional. TLS 1.2 is also enabled by default on both client and backend sides.
+TLS 1.3 support is available in all API Management service tiers. In most instances created in those service tiers, TLS 1.3 is permanently enabled by default for client-side connections. Enabling backend-side TLS 1.3 is optional. TLS 1.2 is also enabled by default on both client and backend sides.
 
 TLS 1.3 is a major revision of the TLS protocol that provides improved security and performance. It includes features such as reduced handshake latency and improved security against certain types of attacks.
 
-> [!NOTE]
-> The [v2 tiers](v2-service-tiers-overview.md) of API Management and [workspace gateways](workspaces-overview.md) support TLS 1.2 by default for client-side and backend-side connections. They don't currently support TLS 1.3.
-
 ### Optionally enable TLS 1.3 when clients require certificate renegotiation
 
 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 we identified as reliant on client certificate renegotiation do not have TLS 1.3 enabled by default. 
+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. 
 
 > [!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.
@@ -71,15 +67,15 @@ To enable TLS 1.3 for client-side connections in these instances, configure sett
 
 1. On the **Protocols + ciphers** page, in the **Client protocol** section, next to **TLS 1.3**, select **View and manage configuration**.
 1. Review the list of **Recent client certificate renegotiations**. The list shows API operations where clients recently used client certificate renegotiation.
-1. If you choose to enable TLS 1.3 for client-side connections, select **Enable**.
+1. If you choose to enable TLS 1.3 for client-side connections, under **Change TLS 1.3 status**, select **Enable**.
 1. Select **Close**.
 
 After enabling TLS 1.3, review gateway request metrics or TLS-related exceptions in logs that indicate TLS connection failures. If necessary, disable TLS 1.3 for client-side connections and downgrade to TLS 1.2.
 
 If you need to disable TLS 1.3 for client-side connections in these instances, configure settings on the **Protocols + ciphers** page:
 
 1. On the **Protocols + ciphers** page, in the **Client protocol** section, next to **TLS 1.3**, select **View and manage configuration**.
-1. Select **Disable**.
+1. Under **Change TLS 1.3 status**, elect **Disable**.
 1. Select **Close**.
 
 ### Backend-side TLS 1.3
@@ -91,7 +87,8 @@ Enabling backend-side TLS 1.3 is optional. If you enable it, API Management uses
 
 You can enable backend-side TLS 1.3 from the **Protocols + ciphers** page:    
 
-1. On the **Protocols + ciphers** page, in the **Backend protocol** section, enable the **TLS 1.3** setting.
+1. On the **Protocols + ciphers** page, in the **Backend protocol** section, next to **TLS 1.3**, select **View and manage configuration**.
+1. Under **Change TLS 1.3 status**, select **Enable**.
 1. Select **Save**.
 
 ## Related content

articles/api-management/inject-vnet-v2.md

@@ -54,6 +54,29 @@ If you want to enable *public* inbound access to an API Management instance in t
 * Minimum: /27 (32 addresses)
 * Recommended: /24 (256 addresses) - to accommodate scaling of API Management instance
 
+### Examples
+
+The following table shows subnet sizing examples for API Management virtual network injection, illustrating how different CIDR blocks affect the number of scale-out units possible:
+
+| Subnet CIDR | Total IP addresses | Azure reserved IPs | API Management instance IPs | Internal load balancer IP | Remaining IPs for scale-out | Max scale-out units | Total max units |
+|-------------|---------------------|---------------------|------------------------------|----------------------------|-----------------------------|----------------------|------------------|
+| /27         | 32                  | 5                   | 2                            | 1                          | 24                          | 12                   | 13               |
+| /26         | 64                  | 5                   | 2                            | 1                          | 56                          | 28                   | 29               |
+| /25         | 128                 | 5                   | 2                            | 1                          | 120                         | 30*                  | 30*              |
+
+
+### Key Points
+
+- **Minimum subnet size**: /27 (provides 24 usable IP addresses for API Management)
+- **Azure reserved IPs**: 5 addresses per subnet (first and last for protocol conformance, plus 3 for Azure services)
+- **Scale-out requirement**: Each scale-out unit requires 2 IP addresses
+- **Internal load balancer**: Only required when API Management is deployed in internal virtual network mode
+- **Premium V2 limit**: * Currently supports up to 30 units maximum.
+
+> [!IMPORTANT]
+> API Management is a member of Azure Integration Services and is typically deployed as a pivotal service in enterprise architectures. It is prudent to err on the higher side of available IPs for the API Management subnet as changing it later can have far-reaching impact.
+> The private IP addresses of internal load balancer and API Management units are assigned dynamically. Therefore, it is impossible to anticipate the private IP of the API Management instance prior to its deployment. Additionally, changing to a different subnet and then returning might cause a change in the private IP address.
+
 ### Network security group
 
 [!INCLUDE [api-management-virtual-network-v2-nsg-rules](../../includes/api-management-virtual-network-v2-nsg-rules.md)]
@@ -76,8 +99,6 @@ You must have at least the following role-based access control permissions on th
 | Microsoft.Network/virtualNetworks/subnets/read | Read a virtual network subnet definition |
 | Microsoft.Network/virtualNetworks/subnets/join/action | Joins a virtual network |
 
-
-
 ## Inject API Management in a virtual network
 
 When you [create](get-started-create-service-instance.md) a Premium v2 instance using the Azure portal, you can optionally configure settings for virtual network injection. 

articles/batch/batch-container-isolation-task.md

@@ -2,7 +2,7 @@
 title: Configure container isolation in Azure Batch task
 description: Learn how to configure isolation at task level in Azure Batch.
 ms.topic: how-to
-ms.date: 04/02/2025
+ms.date: 01/06/2026
 ms.devlang: csharp
 ms.custom: batch
 # Customer intent: As an Azure Batch user, I want to configure task-level container isolation, so that I can customize data paths and enhance security by preventing data leakage between containers.
@@ -58,7 +58,7 @@ Refer to the listed data paths that you can choose to attach to the container. A
 
 > [!Note]
 > * If you use an empty list, the NodeAgent will not mount any data paths into the task's container. If you use null, the NodeAgent will mount the entire ephemeral disk (in Windows) or `AZ_BATCH_NODE_ROOT_DIR` (in Linux).
-> * If you don't mount the task data path into the container, you must set the task's property [workingDirectory](/rest/api/batchservice/task/add?tabs=HTTP#containerworkingdirectory) to containerImageDefault.
+> * If you don't mount the task data path into the container, you must set the task's property [workingDirectory](/rest/api/batchservice/tasks/create-task#containerworkingdirectory) to containerImageDefault.
 
 Before running a container isolation task, you must create a pool with a container. For more information on how to create it, see this guide [Docker container workload](batch-docker-container-workloads.md).