Merge pull request #302658 from MicrosoftDocs/main

Auto Publish – main to live - 2025-07-12 05:00 UTC

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

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

@@ -54,6 +54,8 @@ 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
 
+### Network security group
+
 [!INCLUDE [api-management-virtual-network-v2-nsg-rules](../../includes/api-management-virtual-network-v2-nsg-rules.md)]
 
 ### Subnet delegation

articles/api-management/integrate-vnet-outbound.md

@@ -46,8 +46,14 @@ If you want to inject a Premium v2 (preview) API Management instance into a virt
 * Minimum: /27 (32 addresses)
 * Recommended: /24 (256 addresses) - to accommodate scaling of API Management instance
 
+### Network security group
+
 [!INCLUDE [api-management-virtual-network-v2-nsg-rules](../../includes/api-management-virtual-network-v2-nsg-rules.md)]
 
+> [!IMPORTANT]
+> * Inbound NSG rules do not apply when a v2 tier instance is integrated in a virtual network for private outbound access. To enforce inbound NSG rules, use virtual network injection instead of integration.
+> * This differs from networking in the classic Premium tier, where inbound NSG rules are enforced in both external and internal virtual network injection modes. [Learn more](virtual-network-injection-resources.md)
+
 ### Subnet delegation
 
 The subnet needs to be delegated to the **Microsoft.Web/serverFarms** service.

articles/api-management/virtual-network-workspaces-resources.md

@@ -5,7 +5,7 @@ author: dlepow
 
 ms.service: azure-api-management
 ms.topic: concept-article
-ms.date: 06/18/2025
+ms.date: 07/08/2025
 ms.author: danlep
 ---
 
@@ -45,7 +45,6 @@ For information about configuring subnet delegation, see [Add or remove a subnet
 
 #### [Virtual network integration](#tab/external)
 
-
 For virtual network integration, the subnet needs to be delegated to the **Microsoft.Web/serverFarms** service.
 
 :::image type="content" source="media/virtual-network-injection-workspaces-resources/delegate-external.png" alt-text="Screenshot showing subnet delegation to Microsoft.Web/serverFarms in the portal.":::
@@ -65,21 +64,20 @@ For virtual network injection, the subnet needs to be delegated to the **Microso
 
 ---
 
+## Network security group
 
-## Network security group (NSG) rules
+#### [Virtual network integration](#tab/external)
 
-A network security group (NSG) must be attached to the subnet to explicitly allow certain inbound or outbound connectivity. Configure the following rules in the NSG. Set the priority of these rules higher than that of the default rules.
+[!INCLUDE [api-management-virtual-network-v2-nsg-rules](../../includes/api-management-virtual-network-v2-nsg-rules.md)]
 
-Configure other NSG rules to meet your organization's network access requirements.
 
-#### [Virtual network integration](#tab/external)
+#### [Virtual network injection](#tab/internal)
 
-| Direction | Source  | Source port ranges | Destination | Destination port ranges | Protocol |  Action | Purpose | 
-|-------|--------------|----------|---------|------------|-----------|-----|--------|
-| Inbound | AzureLoadBalancer | * | Workspace gateway subnet range  | 80 | TCP | Allow | Allow internal health ping traffic |
-| Inbound | Internet | * | Workspace gateway subnet range  | 80,443 | TCP | Allow | Allow inbound traffic |
+A network security group (NSG) must be associated with the subnet. To set up a network security group, see [Create a network security group](../virtual-network/manage-network-security-group.md). 
 
-#### [Virtual network injection](#tab/internal)
+* Configure the following rules in the NSG. Set the priority of these rules higher than that of the default rules.
+* Configure other outbound rules you need for the gateway to reach your API backends. 
+* Configure other NSG rules to meet your organization’s network access requirements. For example, NSG rules can also be used to block outbound traffic to the internet and allow access only to resources in your virtual network. 
 
 | Direction | Source  | Source port ranges | Destination | Destination port ranges | Protocol |  Action | Purpose | 
 |-------|--------------|----------|---------|------------|-----------|-----|--------|
@@ -89,6 +87,10 @@ Configure other NSG rules to meet your organization's network access requirement
 
 ---
 
+> [!IMPORTANT]
+> * Inbound NSG rules do not apply when you integrate a workspace gateway in a virtual network for private outbound access. To enforce inbound NSG rules, use virtual network injection instead of integration.
+> * This differs from networking in the classic Premium tier, where inbound NSG rules are enforced in both external and internal virtual network injection modes. [Learn more](virtual-network-injection-resources.md)
+
 ## DNS settings for virtual network injection
 
 For virtual network injection, you have to manage your own DNS to enable inbound access to your workspace gateway. 

articles/app-service/configure-authentication-provider-aad.md

@@ -265,7 +265,7 @@ The created app registration authenticates incoming requests for your Microsoft
 
 Your application code is often the best place to handle custom authorization logic. However, for common scenarios, the Microsoft identity platform provides built-in checks that you can use to limit access.
 
-This section shows how to enable built-in checks by using the [App Service authentication V2 API](./configure-authentication-api-version.md). Currently, the only way to configure these built-in checks is by using [Azure Resource Manager templates](/azure/templates/microsoft.web/sites/config-authsettingsv2) or the [REST API](/rest/api/appservice/web-apps/update-auth-settings-v2).
+This section shows how to enable built-in checks by using the [App Service authentication V2 API](./configure-authentication-api-version.md). Currently, the only way to configure these built-in checks is by using [Azure Resource Manager templates](/azure/templates/microsoft.web/sites/config-authsettingsv2) or the [REST API](/rest/api/appservice/web-apps/update-auth-settings-v-2).
 
 Within the API object, the Microsoft Entra identity provider configuration has a `validation` section that can include a `defaultAuthorizationPolicy` object, as shown in the following structure:
 

articles/connectors/connectors-create-api-servicebus.md

@@ -33,8 +33,7 @@ The Service Bus connector has different versions, based on [logic app workflow t
 | Logic app | Environment | Connector version |
 |-----------|-------------|-------------------|
 | **Consumption** | Multitenant Azure Logic Apps | Managed connector, which appears in the connector gallery under **Runtime** > **Shared**. <br><br>**Note**: Service Bus managed connector triggers follow the [*long polling trigger* pattern](#service-bus-managed-triggers), which means that the trigger periodically checks for messages in the queue or topic subscription. For more information, review the following documentation: <br><br>- [Service Bus managed connector reference](/connectors/servicebus/) <br>- [Managed connectors in Azure Logic Apps](managed.md) |
-| **Standard** | Single-tenant Azure Logic Apps and App Service Environment v3 (Windows plans only) | Managed connector (Azure-hosted), which appears in the connector gallery under **Runtime** > **Shared**, and built-in connector, which appears in the connector gallery under **Runtime** > **In App** and is [service provider based](../logic-apps/custom-connector-overview.md#service-provider-interface-implementation). <br><br>The Service Bus managed connector triggers follow the [*long polling trigger* pattern](#service-bus-managed-triggers), which means that the trigger periodically checks for messages in the queue or topic subscription. <br><br>The Service Bus built-in connector non-session triggers follow a *continuous polling trigger pattern* that is fully managed by the connector. This pattern has the trigger constantly check for messages in the queue or topic subscription. Session triggers follow the *long-polling trigger pattern*, but its configuration is governed by the Azure Functions setting named [**clientRetryOptions:tryTimeout**](../azure-functions/functions-bindings-service-bus.md#hostjson-settings). The built-in version usually provides better performance, capabilities, pricing, and so on.
-<br><br>For more information, review the following documentation: <br><br>- [Service Bus managed connector reference](/connectors/servicebus/) <br>- [Service Bus built-in connector operations](/azure/logic-apps/connectors/built-in/reference/servicebus) <br>- [Built-in connectors in Azure Logic Apps](built-in.md) |
+| **Standard** | Single-tenant Azure Logic Apps and App Service Environment v3 (Windows plans only) | Managed connector (Azure-hosted), which appears in the connector gallery under **Runtime** > **Shared**, and built-in connector, which appears in the connector gallery under **Runtime** > **In App** and is [service provider based](../logic-apps/custom-connector-overview.md#service-provider-interface-implementation). <br><br>The Service Bus managed connector triggers follow the [*long polling trigger* pattern](#service-bus-managed-triggers), which means that the trigger periodically checks for messages in the queue or topic subscription. <br><br>The Service Bus built-in connector non-session triggers follow a *continuous polling trigger pattern* that is fully managed by the connector. This pattern has the trigger constantly check for messages in the queue or topic subscription. Session triggers follow the *long-polling trigger pattern*, but its configuration is governed by the Azure Functions setting named [**clientRetryOptions:tryTimeout**](../azure-functions/functions-bindings-service-bus.md#hostjson-settings). The built-in version usually provides better performance, capabilities, pricing, and so on. <br><br>For more information, review the following documentation: <br><br>- [Service Bus managed connector reference](/connectors/servicebus/) <br>- [Service Bus built-in connector operations](/azure/logic-apps/connectors/built-in/reference/servicebus) <br>- [Built-in connectors in Azure Logic Apps](built-in.md) |
 
 ## Prerequisites
 
@@ -135,64 +134,67 @@ To increase the timeout for sending a message, [add the **ServiceProviders.Servi
   >
   > If you must change the concurrency on a Service Bus auto-complete trigger, don't make this change before 
   > you initially save your workflow. Create and save your workflow first before you edit the trigger to change the concurrency.
-    ```
 
 ### Service Bus built-in connector triggers
 
-For he Service Bus built-in connector, non-session triggers follow a *continuous polling trigger pattern* that is fully managed by the connector. This pattern has the trigger constantly check for messages in the queue or topic subscription. Session triggers follow the *long-polling trigger pattern*, with its configuration is governed by the Azure Functions setting named [**clientRetryOptions:tryTimeout**](../azure-functions/functions-bindings-service-bus.md#hostjson-settings). Currently, the configuration settings for the Service Bus built-in trigger are shared between the [Azure Functions host extension](../azure-functions/functions-bindings-service-bus.md#hostjson-settings), which is defined in your logic app's [**host.json** file](../logic-apps/edit-app-settings-host-settings.md), and the trigger settings defined in your logic app's workflow, which you can set up either through the designer or code view. This section covers both settings locations.
+For the Service Bus built-in connector, non-session triggers follow a *continuous polling trigger pattern* that is fully managed by the connector. This pattern has the trigger constantly check for messages in the queue or topic subscription. Session triggers follow the *long-polling trigger pattern*, with its configuration is governed by the Azure Functions setting named [**clientRetryOptions:tryTimeout**](../azure-functions/functions-bindings-service-bus.md#hostjson-settings). Currently, the configuration settings for the Service Bus built-in trigger are shared between the [Azure Functions host extension](../azure-functions/functions-bindings-service-bus.md#hostjson-settings), which is defined in your logic app's [**host.json** file](../logic-apps/edit-app-settings-host-settings.md), and the trigger settings defined in your logic app's workflow, which you can set up either through the designer or code view. This section covers both settings locations.
+
+* Some built-in triggers, such as the **When messages are available in a queue** trigger, can return one or more messages. When these triggers fire, they return between one and the number of messages.
 
-* In Standard workflows, some triggers, such as the **When messages are available in a queue** trigger, can return one or more messages. When these triggers fire, they return between one and the number of messages. For this type of trigger and where the **Maximum message count** parameter isn't supported, you can still control the number of messages received by using the **maxMessageBatchSize** property in the **host.json** file. To find this file, see [Edit host and app settings for Standard logic apps](../logic-apps/edit-app-settings-host-settings.md).
+  The built-in trigger named **When messages are available in a queue (V1)** doesn't support the parameter named **Maximum message batch size**. Make sure that you use the V2 version instead. To use a trigger where the parameter isn't supported, you can still control the number of messages received by adding the `maxMessageBatchSize` parameter to the trigger definition in the host.json file. To find this file, see [Edit host and app settings for Standard logic apps](../logic-apps/edit-app-settings-host-settings.md).
 
-  
   ```json
   "extensions": {
-    "serviceBus": {
+     "serviceBus": {
         "maxMessageBatchSize": 25
-    }
+     }
   }
   ```
 
-* You can also enable concurrency on the Service Bus trigger, either through the designer or in code:
+  You can also enable concurrency on the Service Bus trigger, either through the designer or in code, for example:
 
   ```json
   "runtimeConfiguration": {
-      "concurrency": {
-          "runs": 100
+     "concurrency": {
+          "runs": 50
       }
   }
   ```
 
-  When you set up concurrency using a batch, keep the number of concurrent runs larger than the overall batch size. That way, read messages don't go into a waiting state and are always picked up when they're read. In some cases, the trigger can have up to twice the batch size.
+  * If you set up concurrency using a batch, keep the number of concurrent runs larger than the overall batch size. That way, read messages don't go into a waiting state and are always picked up when they're read. In some cases, the trigger can have up to twice the batch size.
 
-* If you enable concurrency, the **SplitOn** limit is reduced to 100 items. This behavior is true for all triggers, not just the Service Bus trigger. Make sure the specified batch size is less than this limit on any trigger where you enable concurrency.
+  * If you enable concurrency on the trigger named **When messages are available in a queue (V1)**, and 100+ messages are sent to the queue, all messages are routed to the [dead-letter queue](../service-bus-messaging/service-bus-dead-letter-queues.md).
 
-* [Some scenarios exist where the trigger can exceed the concurrency settings](../logic-apps/logic-apps-workflow-actions-triggers.md#change-waiting-runs-limit). Rather than fail these runs, Azure Logic Apps queues them in a waiting state until they can be started. The [**maximumWaitingRuns** setting](../logic-apps/edit-app-settings-host-settings.md#trigger-concurrency) controls the number of runs allowed in the waiting state:
+  * If you enable concurrency, the **SplitOn** limit is reduced to 100 items. This behavior is true for all triggers, not just the Service Bus trigger. Make sure the specified batch size is less than this limit on any trigger where you enable concurrency.
 
-  ```json
-  "runtimeConfiguration": {
-      "concurrency": {
-          "runs": 100,
-          "maximumWaitingRuns": 50
-      }
-  }
-  ```
+  * If you enable concurrency, by default, a 30-second delay exists between batch reads. This delay slows down the trigger to achieve the following goals:
+
+    * Reduce the number of storage calls sent to check the number of runs on which to apply concurrency.
 
-  With the Service Bus trigger, make sure that you carefully test these changes so that runs don't wait longer than the message lock timeout. For more information about the default values, see [Concurrency and de-batching limits here](../logic-apps/logic-apps-limits-and-config.md#concurrency-and-debatching).
+    * Mimic the behavior of the Service Bus managed connector trigger, which has a 30-second long poll when no messages are found.
 
-* If you enable concurrency, a 30-second delay exists between batch reads, by default. This delay slows down the trigger to achieve the following goals:
+    You can change this delay, but make sure that you carefully test any changes to the default value:
 
-  - Reduce the number of storage calls sent to check the number of runs on which to apply concurrency.
+    ```json
+    "workflow": {
+       "settings": {
+          "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30"
+       }
+    }
+    ```
 
-  - Mimic the behavior of the Service Bus managed connector trigger, which has a 30-second long poll when no messages are found.
+  * [Some scenarios exist where the trigger can exceed the concurrency settings](../logic-apps/logic-apps-workflow-actions-triggers.md#change-waiting-runs-limit). Rather than fail these runs, Azure Logic Apps queues them in a waiting state until they can be started. The [`maximumWaitingRuns` setting](../logic-apps/edit-app-settings-host-settings.md#trigger-concurrency) controls the number of runs allowed in the waiting state:
 
-  You can change this delay, but make sure that you carefully test any changes to the default value:
+    ```json
+    "runtimeConfiguration": {
+       "concurrency": {
+          "runs": 100,
+          "maximumWaitingRuns": 50
+       }
+    }
+    ```
 
-  ```json
-  "workflow": {
-      "settings": {
-          "Runtime.ServiceProviders.FunctionTriggers.DynamicListenerEnableDisableInterval": "00:00:30"
-      }
-  }
+    With the Service Bus trigger, make sure that you carefully test these changes so that runs don't wait longer than the message lock timeout. For more information about the default values, see [Concurrency and de-batching limits here](../logic-apps/logic-apps-limits-and-config.md#concurrency-and-debatching).
 
 ## Step 1: Check access to Service Bus namespace
 

articles/connectors/enable-stateful-affinity-built-in-connectors.md

@@ -6,7 +6,7 @@ ms.suite: integration
 ms.reviewer: estfan, edwardhe, azla
 ms.topic: how-to
 ms.custom: devx-track-azurepowershell
-ms.date: 03/18/2025
+ms.date: 07/12/2025
 ---
 
 # Enable stateful mode for stateless built-in connectors in Azure Logic Apps
@@ -197,6 +197,13 @@ Set-AzResource :
 
 Resource scale-in events might cause the loss of context for built-in connectors with stateful mode enabled. To prevent this potential loss before such events can happen, fix the number of instances available for your logic app resource. This way, no scale-in events can happen to cause this potential context loss.
 
+> [!NOTE]
+>
+> For logic apps that doesn't use the App Service Environment v3 hosting option,
+> Azure Logic Apps waits up to 5 minutes before taking down a virtual machine during 
+> scale-in events. Built-in connectors might experience issues. For example,
+> Azure Service Bus can't complete messages during platform upgrades.
+
 1. On your logic app resource menu, under **Settings**, select **Scale out (App Service plan)**.
 
 1. On the **Scale out (App Service plan)** page, in the **App Scale out** section, follow these steps:
@@ -209,7 +216,7 @@ Resource scale-in events might cause the loss of context for built-in connectors
 
 1. When you're done, on the **Scale out** toolbar, select **Save**.
 
-## Next steps
+## Related content
 
 - [Connect to Azure Service Bus](/azure/connectors/connectors-create-api-servicebus)
 - [Connect to SAP](/azure/logic-apps/connectors/sap)