Merge branch 'main' of https://github.com/microsoftdocs/azure-docs-pr into thiago-quickstart-fixup

Author: ggailey777

articles/api-management/private-endpoint.md

@@ -5,7 +5,7 @@ ms.service: azure-api-management
 author: dlepow
 ms.author: danlep
 ms.topic: how-to
-ms.date: 11/17/2025
+ms.date: 03/17/2026
 ms.custom:
   - build-2025
   - sfi-image-nochange
@@ -32,7 +32,9 @@ You can configure an inbound [private endpoint](../private-link/private-endpoint
 * Only the API Management instance's **Gateway endpoint** supports inbound Private Link connections. 
 * Each API Management instance supports at most 100 Private Link connections.
 * Connections aren't supported on the [self-hosted gateway](self-hosted-gateway-overview.md) or on a [workspace gateway](workspaces-overview.md#workspace-gateway). 
-* In the classic API Management tiers, private endpoints aren't supported in instances injected in an internal or external virtual network.
+* In the classic API Management tiers, private endpoints aren't supported in instances injected in an internal or external virtual network. 
+    > [!NOTE]
+    > In the Standard v2 and Premium v2 tiers, private endpoints are supported in instances with any supported virtual network configuration when fronted with [Azure Front Door Premium](../frontdoor/standard-premium/how-to-enable-private-link-apim.md).
 
 ## Typical scenarios
 
@@ -43,9 +45,6 @@ Supported configurations include:
 * Pass client requests through a firewall and configure rules to route requests privately to the API Management gateway.
 * Configure Azure Front Door (or Azure Front Door with Azure Application Gateway) to receive external traffic and then route traffic privately to the API Management gateway. For example, see [Connect Azure Front Door Premium to an Azure API Management with Private Link](../frontdoor/standard-premium/how-to-enable-private-link-apim.md).
 
-    > [!NOTE]
-    > Currently, routing traffic privately from Azure Front Door to an API Management Premium v2 instance isn't supported.
-
 ## Prerequisites
 
 - An existing API Management instance. [Create one if you haven't already](get-started-create-service-instance.md). 

articles/app-service/app-service-plan-manage.md

@@ -6,7 +6,7 @@ ms.assetid: 4859d0d5-3e3c-40cc-96eb-f318b2c51a3d
 ms.topic: how-to
 ms.author: msangapu
 author: msangapu-msft
-ms.date: 11/17/2025
+ms.date: 03/19/2026
 ms.update-cycle: 1095-days
 ms.custom: "UpdateFrequency3"
 
@@ -102,6 +102,19 @@ When creating or manually scaling out an App Service Plan you may experience sit
 
 The preview of App Service Plan Asynchronous enables you to request your target number of instances and the platform scales out to the target number, without you having to modify your original request and retrying. The platform scales to the number of available instances and then triggers the underlying platform to make more instances available. You can make use of this functionality during scale-out operations or at plan creation time.  This functionality is supported for all Basic, Standard, and Premium pricing plans.
 
+> [!NOTE]
+> This behavior is NOT configurable for App Service Plans created in App Service Environments.  App Service Environments create and scale App Service Plans asynchronously by default.
+
+### Scaling up or down App Service Plan SKUs
+
+When using asynchronous scaling, it's possible to scale up or down to a larger or smaller SKU.  During this type of operation, no other properties of the App Service Plan can be changed. Scaling up or down to a new SKU may fail if there aren't enough App Service Plan instances available to fully satisfy the request, this is to prevent your App Service Plan having fewer workers than requested.
+
+If a scale up or down operation fails, you can either scale in or out within the current SKU or perform the operation with the minim number of acceptable workers and then scale out asynchronously to the desired target.
+
+### Cancelling an asynchronous scaling operation
+
+An in-progress asynchronous scale operation is canceled only when you explicitly change the TargetWorkerCount property. Changes to other App Service Plan properties don't cancel the operation, including changes to the SKU, or App Service Plan instance count. App Service Plan instance count changes that can't be completed synchronously are ignored unless the TargetWorkerCount is also changed. To explicitly cancel the scale operation, set the TargetWorkerCount to 0.
+
 ### [Scale-out (CLI)](#tab/asyncscaleout)
 ```azurecli-interactive
 az appservice plan update -g <resourceGroupName> -n <App Service Plan Name> --async-scaling-enabled true --number-of-workers <number of workers to scale out to>
@@ -111,7 +124,6 @@ az appservice plan update -g <resourceGroupName> -n <App Service Plan Name> --as
 ```azurecli-interactive
 az appservice plan create -g asyncasp -n asyncasplinuxexample --number-of-workers 25 --sku p1v3 --async-scaling-enabled true --location northeurope
 ```
-
 ---
 
 <a name="delete"></a>

articles/app-service/tutorial-nodejs-mongodb-app.md

@@ -25,7 +25,7 @@ ms.custom:
 
 # Tutorial: Deploy a Node.js + MongoDB web app to Azure
 
-This tutorial shows how to create a secure Node.js app in [Azure App Service](overview.md) that's connected to an [Azure Cosmos DB for MongoDB](/azure/cosmos-db/mongodb/mongodb-introduction) database. Azure App Service provides a highly scalable, self-patching web hosting service using the Linux operating system. When you're finished, you have an Express.js app running on Azure App Service on Linux.
+This tutorial shows how to create a secure Node.js app in [Azure App Service](overview.md) that's connected to an [Azure DocumentDB](https://learn.microsoft.com/azure/documentdb/) database. Azure App Service provides a highly scalable, self-patching web hosting service using the Linux operating system. When you're finished, you have an Express.js app running on Azure App Service on Linux.
 
 :::image type="content" source="./media/tutorial-nodejs-mongodb-app/azure-portal-browse-app-2.png" alt-text="Screenshot of Node.js application storing data in Cosmos DB.":::
 
@@ -125,7 +125,7 @@ Having issues? Check the [Troubleshooting section](#troubleshooting).
 
 ## Create App Service and Azure Cosmos DB
 
-In this step, you create the Azure resources. The steps used in this tutorial create a set of secure-by-default resources that include App Service and Azure Cosmos DB for MongoDB. For the creation process, you specify:
+In this step, you create the Azure resources. The steps used in this tutorial create a set of secure-by-default resources that include App Service and Azure DocumentDB. For the creation process, you specify:
 
 - The **Name** for the web app. It's part of the DNS name for your app.
 - The **Region** to run the app physically in the world. It's also part of the DNS name for your app.
@@ -171,7 +171,7 @@ Sign in to the [Azure portal](https://portal.azure.com/) and follow these steps
         - **Virtual network** → Integrated with the App Service app and isolates back-end network traffic.
         - **Private endpoint** → Access endpoint for the database resource in the virtual network.
         - **Network interface** → Represents a private IP address for the private endpoint.
-        - **Azure Cosmos DB for MongoDB** → Accessible only from behind the private endpoint. A database and a user are created for you on the server.
+        - **Azure DocumentDB** → Accessible only from behind the private endpoint. A database and a user are created for you on the server.
         - **Private DNS zone** → Enables DNS resolution of the Azure Cosmos DB server in the virtual network.
 
     :::column-end:::

articles/application-gateway/media/tutorial-ingress-controller-add-on-new/tutorial-ingress-controller-add-on-new.png

@@ -385,8 +385,8 @@ For the legacy cloning script, version 1.0.11 is the new version of the migratio
 ### Public IP retention script
 
 After you successfully migrate the configuration and thoroughly test your new V2 gateway, this step focuses on redirecting live traffic.
-
-We provide an Azure PowerShell script that *retains the public IP address from V1*. Here are important considerations for the script:
+> [!NOTE]
+> The IP migration script does not support public IP address resources that have name beginning with a numeric character. 
 
 - The script reserves the Basic public IP from V1, converts it to Standard, and attaches it to the V2 gateway. This action effectively redirects all incoming traffic to the V2 gateway.
 - This IP swap operation typically results in a brief *downtime of approximately one to five minutes*. Plan accordingly.

articles/application-gateway/migrate-v1-v2.md

@@ -388,4 +388,4 @@ az deployment group create \
 
 ## Security notice
 
-This solution is classified as **Microsoft Confidential**. Please ensure you follow your organization’s security and data handling best practices when deploying and managing this solution.
+Please ensure you follow your organization’s security and data handling best practices when deploying and managing this solution.

articles/application-gateway/mutual-authentication-arm-template.md

@@ -57,6 +57,27 @@ Deploying a new AKS cluster with the AGIC add-on enabled without specifying an e
 az aks create -n myCluster -g myResourceGroup --network-plugin azure --enable-managed-identity -a ingress-appgw --appgw-name myApplicationGateway --appgw-subnet-cidr "10.225.0.0/16" --generate-ssh-keys
 ```
 
+## Enable the add-on for the existing AKS cluster
+
+You already have an existing AKS cluster and will enable the AGIC add-on. The add-on can be enabled either through the Azure portal or by using the Azure CLI.
+
+# [Azure Portal](#tab/azure-portal)
+
+In this page in the screenshot, you can create it simply by selecting the checkbox. If you want to specify a subnet prefix, select *Create new* and configure it manually.
+
+:::image type="content" source="media/tutorial-ingress-controller-add-on-new/tutorial-ingress-controller-add-on-new.png" alt-text="Screenshot of enabling AGIC addon by Portal." lightbox="media/tutorial-ingress-controller-add-on-new/tutorial-ingress-controller-add-on-new.png":::
+
+# [Azure CLI](#tab/azure-cli)
+
+You can give the name of the application gateway as well as subnet CIDR by the command.
+appgw-subnet-cidr should be in the address prefixes in your virtual network. Please change *10.0.250.0/24* to your preferred application gateway subnet CIDR. This must always be within the address space range of your virtual network.
+
+```azurecli
+$ az aks enable-addons --resource-group ${RG_NAME} --name ${CLUSTER_NAME} --addons ingress-appgw --appgw-subnet-cidr "10.0.250.0/24"
+```
+
+In most cases, enabling the add-on automatically assigns the required permissions. However, depending on the environment, the permissions may not be granted automatically. In such cases, you should verify the permissions and assign them manually if necessary.
+
 > [!NOTE] 
 > Please ensure the identity used by AGIC has the proper permissions. A list of permissions needed by the identity can be found here: [Configure Infrastructure - Permissions](configuration-infrastructure.md#permissions). If a custom role is not defined with the required permissions, you may use the _Network Contributor_ role.
 

articles/application-gateway/tutorial-ingress-controller-add-on-new.md

@@ -279,7 +279,7 @@
       href: /security/benchmark/azure/baselines/functions-security-baseline?toc=/azure/azure-functions/toc.json&bc=/azure/azure-functions/breadcrumb/toc.json
   - name: Reliability
     items:
-    - name: Availability zones and disaster recovery
+    - name: Reliability in Azure Functions
       displayName: availability zones, high-availability, zone redundancy, disaster recovery
       href: /azure/reliability/reliability-functions?toc=/azure/azure-functions/toc.json&bc=/azure/azure-functions/breadcrumb/toc.json
     - name: Zone redundancy

articles/azure-functions/TOC.yml

@@ -240,6 +240,32 @@ module.exports = df.orchestrator(function*(context){
 });
 ```
 
+<br>
+<details>
+<summary><b>Node.js programming model v4 apps (including TypeScript)</b></summary>
+
+Use the same replay check pattern in your orchestration function:
+
+```typescript
+import * as df from "durable-functions";
+
+df.app.orchestration("FunctionChain", function* (context) {
+    if (!context.df.isReplaying) context.log("Calling F1.");
+    yield context.df.callActivity("F1");
+    if (!context.df.isReplaying) context.log("Calling F2.");
+    yield context.df.callActivity("F2");
+    if (!context.df.isReplaying) context.log("Calling F3.");
+    yield context.df.callActivity("F3");
+    context.log("Done!");
+});
+```
+
+> [!NOTE]
+> The `isReplaying` check suppresses duplicate logs caused by orchestrator replay. It doesn't suppress duplicate logs caused by full re-execution (for example, host restarts, long local debugging sessions, or queue message visibility timeouts). In those cases, you might still see repeated log lines with the same orchestration instance ID.
+
+</details>
+<br>
+
 # [Python](#tab/python)
 
 ```python
@@ -377,6 +403,25 @@ module.exports = df.orchestrator(function*(context){
 });
 ```
 
+<details>
+<summary><b>Node.js programming model v4 apps (including TypeScript)</b></summary>
+
+```typescript
+import * as df from "durable-functions";
+
+df.app.orchestration("FunctionChain", function* (context) {
+    if (!context.df.isReplaying) context.log("Calling F1.");
+    yield context.df.callActivity("F1");
+    if (!context.df.isReplaying) context.log("Calling F2.");
+    yield context.df.callActivity("F2");
+    if (!context.df.isReplaying) context.log("Calling F3.");
+    yield context.df.callActivity("F3");
+    context.log("Done!");
+});
+```
+
+</details>
+
 # [Python](#tab/python)
 
 ```python
@@ -484,6 +529,25 @@ module.exports = df.orchestrator(function*(context) {
 });
 ```
 
+<details>
+<summary><b>Node.js programming model v4 apps (including TypeScript)</b></summary>
+
+```typescript
+import * as df from "durable-functions";
+
+df.app.orchestration("SetStatusTest", function* (context) {
+    // ...do work...
+
+    // update the status of the orchestration with some arbitrary data
+    const customStatus = { completionPercentage: 90.0, status: "Updating database records" };
+    context.df.setCustomStatus(customStatus);
+
+    // ...do more work...
+});
+```
+
+</details>
+
 # [Python](#tab/python)
 
 ```python

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

@@ -151,13 +151,65 @@ public class Counter : TaskEntity<int>
 
 ### Deleting entities in the isolated model
 
-Deleting an entity in the isolated model is accomplished by setting the entity state to `null`, and this process depends on the entity implementation path used:
+Deleting an entity in the isolated model is accomplished by setting the entity state to `null`, and this process depends on the entity implementation path used.
+
+#### Delete with ITaskEntity or function-based syntax
+
+When deriving from `ITaskEntity` or using [function based syntax](#function-based-syntax), delete is accomplished by calling `TaskEntityOperation.State.SetState(null)`:
+
+```csharp
+// Inside a function-based entity dispatch
+switch (operation.Name.ToLowerInvariant())
+{
+    case "delete":
+        operation.State.SetState(null);
+        break;
+}
+```
+
+#### Delete with TaskEntity\<TState\>
+
+When deriving from `TaskEntity<TState>`, a delete operation is implicitly defined. However, it can be overridden by defining a method `Delete` on the entity. State can also be deleted from any operation via `this.State = null`.
+
+- To delete by setting state to `null` requires `TState` to be nullable.
+- The implicitly defined delete operation deletes non-nullable `TState`.
+
+The following example shows a `TaskEntity<int?>` with nullable state that overrides the default delete:
+
+```csharp
+public class Counter : TaskEntity<int?>
+{
+    public void Delete()
+    {
+        // Custom logic before deleting, such as logging
+        this.State = null;
+    }
+
+    [Function(nameof(Counter))]
+    public static Task Run([EntityTrigger] TaskEntityDispatcher dispatcher)
+        => dispatcher.DispatchAsync<Counter>();
+}
+```
+
+#### Delete with a POCO entity
+
+When using a POCO as your state (not deriving from `TaskEntity<TState>`), a delete operation is implicitly defined. It's possible to override the delete operation by defining a method `Delete` on the POCO. However, there isn't a way to set state to `null` in the POCO route, so the implicitly defined delete operation is the only true delete.
+
+```csharp
+public class Counter
+{
+    public int Value { get; set; }
+
+    // The implicit delete operation handles state removal.
+    // Defining a Delete method here overrides the implicit behavior,
+    // but you cannot set state to null from within a POCO entity.
+
+    [Function(nameof(Counter))]
+    public static Task Run([EntityTrigger] TaskEntityDispatcher dispatcher)
+        => dispatcher.DispatchAsync<Counter>();
+}
+```
 
-- When deriving from `ITaskEntity` or using [function based syntax](#function-based-syntax), delete is accomplished by calling `TaskEntityOperation.State.SetState(null)`.
-- When deriving from `TaskEntity<TState>`, delete is implicitly defined. However, it can be overridden by defining a method `Delete` on the entity. State can also be deleted from any operation via `this.State = null`.
-    - To delete by setting state to null requires `TState` to be nullable.
-    - The implicitly defined delete operation deletes non-nullable `TState`.
-- When using a POCO as your state (not deriving from `TaskEntity<TState>`), delete is implicitly defined. It's possible to override the delete operation by defining a method `Delete` on the POCO. However, there isn't a way to set state to `null` in the POCO route, so the implicitly defined delete operation is the only true delete.
 ::: zone-end
 
 ::: zone pivot="in-proc"