Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into appp

Author: gitName

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/application-gateway/toc.yml

@@ -12,7 +12,7 @@
   - name: Architecture best practices for Azure Application Gateway v2
     href: /azure/well-architected/service-guides/azure-application-gateway?toc=/azure/application-gateway/toc.json&bc=/azure/application-gateway/breadcrumb/toc.json
   - name: What is load balancing and content delivery?
-    href: /azure/networking/load-balancer-content-delivery/load-balancing-content-delivery-overview.md
+    href: /azure/networking/load-balancer-content-delivery/load-balancing-content-delivery-overview
   - name: Choose a load balancing solution
     href: /azure/architecture/guide/technology-choices/load-balancing-overview?toc=/azure/load-balancer/toc.json
   - name: Create Application Gateway - Portal

articles/azure-functions/durable/durable-functions-entities.md

@@ -131,7 +131,7 @@ For more information on the class-based syntax and how to use it, see [Defining
 
 ```csharp
 [Function(nameof(Counter))]
-public static Task DispatchAsync([EntityTrigger] TaskEntityDispatcher dispatcher)
+public static Task Counter([EntityTrigger] TaskEntityDispatcher dispatcher)
 {
     return dispatcher.DispatchAsync(operation =>
     {

articles/azure-functions/functions-create-first-function-resource-manager.md

@@ -30,7 +30,7 @@ Before you begin, you must have an Azure account with an active subscription. [C
 
 ## Review the template
 
-The template used in this quickstart is from [Azure Quickstart Templates](https://azure.microsoft.com/resources/templates/function-app-flex-managed-identities/).
+The template used in this quickstart is from [Azure Quickstart Templates](/samples/azure/azure-quickstart-templates/function-app-flex-managed-identities/).
 
 :::code language="json" source="~/quickstart-templates/quickstarts/microsoft.web/function-app-flex-managed-identities/azuredeploy.json":::
 

articles/azure-netapp-files/configure-access-control-lists.md

@@ -1,10 +1,10 @@
 ---
-title: Configure access control lists with Azure NetApp Files | Microsoft Docs
+title: Configure access control lists with Azure NetApp Files
 description: Learn how to configure access control lists (ACLs) on NFSv4.1 with Azure NetApp Files.
 author: b-ahibbard
 ms.service: azure-netapp-files
 ms.topic: how-to
-ms.date: 07/10/2025
+ms.date: 07/14/2025
 ms.author: anfdocs
 # Customer intent: "As a system administrator, I want to configure access control lists on NFSv4.1 volumes in Azure NetApp Files, so that I can manage fine-grained file permissions for users and groups to enhance security and control over shared resources."
 ---
@@ -58,10 +58,9 @@ To learn more about ACLs in Azure NetApp Files, see [Understand NFSv4.x ACLs](nf
     ```bash
     nfs4_setfacl -a A::[email protected]:RWX /nfsldap/engineering
     ```
-
     - If you're configuring an ACE for [file access logs](manage-file-access-logs.md), you must use the `U:` prefix to denote the ACE is an audit ACE. The following example configures an audit log for everyone for successful and failed access attempts:
-    `nfs4_setfacl -a U:fdiSF:EVERYONE@:rwaDdxtTnNcCoy /<mount_point>`
-
+    `nfs4_setfacl -a U:fdiSF:EVERYONE@:rwaDdxtTnNcCoy /<mount_point>`.
+    - To apply ACLs recursively on a directory and its contents, use the `-R` option with the `nfs4_setfacl` command. This option ensures the ACL changes are applied to all files and subdirectories within the specified directory.
 
 ## Next steps
 

articles/azure-netapp-files/configure-kerberos-encryption.md

@@ -1,5 +1,5 @@
 ---
-title: Configure NFSv4.1 Kerberos encryption for Azure NetApp Files | Microsoft Docs
+title: Configure NFSv4.1 Kerberos encryption for Azure NetApp Files 
 description: Describes how to configure NFSv4.1 Kerberos encryption for Azure NetApp Files and the performance impact.
 services: azure-netapp-files
 author: b-hchen

articles/azure-netapp-files/configure-network-features.md

@@ -1,5 +1,5 @@
 ---
-title: Configure network features for an Azure NetApp Files volume | Microsoft Docs
+title: Configure network features for an Azure NetApp Files volume
 description: Describes the options for network features and how to configure the Network Features option for a volume.
 services: azure-netapp-files
 author: b-hchen
@@ -41,7 +41,7 @@ Two settings are available for network features:
 * When you change the network features option of existing volumes from Basic to Standard network features, access to existing Basic networking volumes might be lost if your UDR or NSG implementations prevent the Basic networking volumes from connecting to DNS and domain controllers. You might also lose the ability to update information, such as the site name, in the Active Directory connector if all volumes can’t communicate with DNS and domain controllers. For guidance about UDRs and NSGs, see [Configure network features for an Azure NetApp Files volume](azure-netapp-files-network-topologies.md#udrs-and-nsgs).
 
 >[!NOTE]
-> The networking features of the DP volume are not affected by changing the source volume from Basic to Standard network features.
+> The networking features of the data protection volume aren't affected by changing the source volume from Basic to Standard network features.
 
 ## <a name="set-the-network-features-option"></a>Set network features option during volume creation
 
@@ -108,7 +108,7 @@ You can edit the network features option of existing volumes from *Basic* to *St
 
 If your Azure NetApp Files volume is managed using Terraform, editing the network features requires additional steps. Terraform-managed Azure resources store their state in a local file, which is in your Terraform module or in Terraform Cloud. 
 
-Updating the network features of your volume alters the underlying network sibling set of the NIC utilized by that volume. This NIC can be utilized by other volumes you own, and other NICs can share the same network sibling set. **If not performed correctly, updating the network features of one Terraform-managed volume can inadvertently update the network features of several other volumes.**
+Updating the network features of your volume alters the underlying network sibling set of the NIC utilized by that volume. This NIC can be utilized by other volumes you own, and other NICs can share the same network sibling set. **If performed incorrectly, updating the network features of one Terraform-managed volume can inadvertently update the network features of several other volumes.**
 
 >[!IMPORTANT]
 >A discontinuity between state data and remote Azure resource configurations--notably, in the `network_features` argument--can result in the destruction of one or more volumes and possible data loss upon running `terraform apply`. Carefully follow the workaround outlined here to safely update the network features from Basic to Standard of Terraform-managed volumes. 
@@ -120,7 +120,7 @@ The name of the state file in your Terraform module is `terraform.tfstate`. It c
 
 :::image type="content" source="./media/configure-network-features/terraform-module.png" alt-text="Screenshot of Terraform module." lightbox="./media/configure-network-features/terraform-module.png":::
 
-Do _not_ manually update the `terraform.tfstate` file. Likewise, the `network_features` argument in the `*.tf` and `*.tf.json` configuration files should also not be updated until you follow the steps outlined here as this would cause a mismatch in the arguments of the remote volume and the local configuration file representing that remote volume. When Terraform detects a mismatch between the arguments of remote resources and local configuration files representing those remote resources, Terraform can destroy the remote resources and reprovision them with the arguments in the local configuration files. This can cause data loss in a volume.
+Do ***not*** manually update the `terraform.tfstate` file. Likewise, the `network_features` argument in the `*.tf` and `*.tf.json` configuration files should also not be updated until you follow the steps outlined here as this would cause a mismatch in the arguments of the remote volume and the local configuration file representing that remote volume. When Terraform detects a mismatch between the arguments of remote resources and local configuration files representing those remote resources, Terraform can destroy the remote resources and reprovision them with the arguments in the local configuration files. This can cause data loss in a volume.
 
 By following the steps outlined here, the `network_features` argument in the `terraform.tfstate` file is automatically updated by Terraform to have the value of "Standard" without destroying the remote volume, thus indicating the network features has been successfully updated to Standard.
 
@@ -141,7 +141,7 @@ Changing the network features for an Azure NetApp Files Volume can impact the ne
 All Terraform configuration files that define these volumes need to be updated, meaning you need to find the Terraform configuration files that define these volumes. The configuration files representing the affected volumes might not be in the same Terraform module.
 
 >[!IMPORTANT]
->With the exception of the single volume you know is managed by Terraform, additional affected volumes might not be managed by Terraform. An additional volume that is listed as being in the same network sibling set does not mean that this additional volume is managed by Terraform.
+>With the exception of the single volume you know is managed by Terraform, additional affected volumes might not be managed by Terraform. Another volume that's listed as being in the same network sibling set doesn't mean this other volume is managed by Terraform.
 
 #### Modify the affected volumes’ configuration files
 
@@ -151,7 +151,7 @@ You must modify the configuration files for each affected volume managed by Terr
 >Depending on your volume’s lifecycle configuration block settings in your Terraform configuration file, your volume can be destroyed, including possible data loss upon running `terraform apply`. Ensure you know which affected volumes are managed by Terraform and which are not.
 
 1. Locate the affected Terraform-managed volumes configuration files.
-1. Add the `ignore_changes = [network_features]` to the volume's `lifecycle` configuration block. If the `lifecycle` block does not exist in that volume’s configuration, add it.
+1. Add the `ignore_changes = [network_features]` to the volume's `lifecycle` configuration block. If the `lifecycle` block doesn't exist in that volume’s configuration, add it.
 
     :::image type="content" source="./media/configure-network-features/terraform-lifecycle.png" alt-text="Screenshot of the lifecycle configuration." lightbox="./media/configure-network-features/terraform-lifecycle.png":::
 
@@ -174,7 +174,7 @@ The `ignore_changes` feature is intended to be used when a resource’s referenc
     :::image type="content" source="./media/configure-network-features/terraform-plan-output.png" alt-text="Screenshot of terraform plan command output." lightbox="./media/configure-network-features/terraform-plan-output.png":::
 
     >[!IMPORTANT]
-    > As a safety precaution, execute `terraform plan` before executing `terraform apply`. The command `terraform plan` allows you to create a “plan” file, which contains the changes to your remote resources. This plan allows you to know if any of your affected volumes will be destroyed by running `terraform apply`.
+    > As a safety precaution, execute `terraform plan` before executing `terraform apply`. The command `terraform plan` allows you to create a “plan” file, which contains the changes to your remote resources. This plan allows you to know if any of your affected volumes can be destroyed by running `terraform apply`.
 
 1. Run `terraform apply` to update the `terraform.tfstate` file.
 
@@ -194,7 +194,7 @@ Once you've update the volumes' network features, you must also modify the `netw
 
 1. Repeat for each affected Terraform-managed volume. 
 1. Verify that the updated configuration files accurately represent the configuration of the remote resources by running `terraform plan`. Confirm the output reads "No changes."
-1. Run `terraform apply` to complete the update. 
+1. To complete the update, run `terraform apply`. 
 
 ## Next steps