Merge pull request #304619 from MicrosoftDocs/main

Auto Publish – main to live - 2025-08-23 05:00 UTC

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

articles/azure-functions/functions-bindings-event-grid-trigger.md

@@ -2,7 +2,7 @@
 title: Azure Event Grid trigger for Azure Functions
 description: Learn to run code when Event Grid events in Azure Functions are dispatched.
 ms.topic: reference
-ms.date: 04/02/2023
+ms.date: 08/20/2025
 ms.devlang: csharp
 # ms.devlang: csharp, java, javascript, powershell, python
 ms.custom: devx-track-csharp, fasttrack-edit, devx-track-python, devx-track-extended-java, devx-track-js, devx-track-ts
@@ -44,11 +44,11 @@ The type of the input parameter used with an Event Grid trigger depends on these
 
 When running your C# function in an isolated worker process, you need to define a custom type for event properties. The following example defines a `MyEventType` class.
 
-:::code language="csharp" source="~/azure-functions-dotnet-worker/samples/Extensions/EventGrid/EventGridFunction.cs" range="35-48":::
+:::code language="csharp" source="~/azure-functions-dotnet-worker/samples/Extensions/EventGrid/EventGridFunction.cs" range="33-45":::
 
 The following example shows how the custom type is used in both the trigger and an Event Grid output binding:
 
-:::code language="csharp" source="~/azure-functions-dotnet-worker/samples/Extensions/EventGrid/EventGridFunction.cs" range="11-33":::
+:::code language="csharp" source="~/azure-functions-dotnet-worker/samples/Extensions/EventGrid/EventGridFunction.cs" range="11-29":::
 
 # [In-process model](#tab/in-process)
 
@@ -342,7 +342,7 @@ Both [in-process](functions-dotnet-class-library.md) and [isolated worker proces
 
 Here's an `EventGridTrigger` attribute in a method signature:
 
-:::code language="csharp" source="~/azure-functions-dotnet-worker/samples/Extensions/EventGrid/EventGridFunction.cs" range="13-16":::
+:::code language="csharp" source="~/azure-functions-dotnet-worker/samples/Extensions/EventGrid/EventGridFunction.cs" range="11-14":::
 
 # [In-process model](#tab/in-process)
 

articles/dev-box/concept-dev-box-deployment-guide.md

@@ -79,7 +79,7 @@ To deploy Microsoft Dev Box involves creating and configuring multiple services,
 
 ### Step 1: Configure Azure subscription
 
-Subscriptions are a unit of management, billing, and scale within Azure. You can have one or more Azure subscriptions because of organization and governance design, resource quota and capacity, cost management, and more. Learn more about [considerations for creating Azure subscriptions](/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-subscriptions).
+Subscriptions are a unit of management, billing, and scale within Azure.  You can use one or more subscriptions to support your organization's structure, governance model, resource quotas, and cost controls. Dev Box enables flexible billing by allowing you to assign different subscriptions to different teams or departments. This helps align cloud costs with how your business operates. Learn more about [considerations for creating Azure subscriptions](/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-subscriptions).
 
 Each Azure subscription is linked to a single Microsoft Entra tenant, which acts as an identity provider (IdP) for your Azure subscription. The Microsoft Entra tenant is used to authenticate users, services, and devices.
 

articles/dev-box/index.yml

@@ -35,7 +35,7 @@ landingContent:
             url: https://learn.microsoft.com/training/modules/explore-microsoft-dev-box-deployment-guidelines-best-practices/
 
   # Card
-  - title: Dev Box deployment
+  - title: Dev Box deployment at scale
     linkLists:
       - linkListType: concept
         links:

articles/redis/overview.md

@@ -136,7 +136,7 @@ The following table helps describe some of the features supported by tier:
 
   \* These tiers are in Public Preview.
 
-- **High availability**: Azure Managed Redis provides multiple [high availability](high-availability.md) options. The SLA only covers connectivity to the cache endpoints. The SLA doesn't cover protection from data loss. For more information on the SLA, see the [SLA](https://azure.microsoft.com/support/legal/sla/cache/v1_0/). It's possible to disable high availability in an Azure Managed Redis instance. This lowers the price but results in data loss and downtime. We only recommend disabling high availability for dev/test scenarios.
+- **High availability**: Azure Managed Redis provides high availability. The SLA only covers connectivity to the cache endpoints. The SLA doesn't cover protection from data loss. For more information on the SLA, see the [SLA](https://azure.microsoft.com/support/legal/sla/cache/v1_0/). It's possible to disable high availability in an Azure Managed Redis instance. This lowers the price but results in data loss and downtime. We only recommend disabling high availability for dev/test scenarios.
 
 ### Other pricing considerations
 

articles/virtual-network-manager/concept-deployments.md

@@ -43,6 +43,8 @@ When you commit a configuration deployment, the API forms a POST operation. Once
 
 When you commit a deployment of configurations, you describe the goal state of your network manager in the targeted regions. This goal state is enforced during the next deployment. For example, when you commit configurations *Config1* and *Config2* into a region, these two configurations get applied and become the region's goal state. If you decided to commit configurations *Config1* and *Config3* into the same region, *Config2* would then be removed, and *Config3* would be added. To remove all configurations, you would deploy **None** to the regions where you no longer wish to have any configurations applied.
 
+You may have multiple connectivity configurations deployed simultaneously in a given region. The connectivity defined in each configuration is additive. If you modify one configuration, under this goal state model you must still deploy all connectivity configurations you want to take effect in that region. For example, given the *East US* region has *Config1* and *Config2* deployed there, if you modify *Config1*, you must deploy both *Config1* and *Config2* again in *East US* in order for both the changes from *Config1* and the behavior from *Config2* to take effect on the virtual networks in the region.
+
 ## Configuration availability
 
 A network manager is available in a region as long as the region is up and running. Should a region with a network manager go down, the network manager is no longer available to submit new configuration deployments or modify existing configurations. However, the configurations that were deployed to the targeted network groups' virtual networks in the targeted regions are still in effect unless those virtual networks are in the region that went down.