Update WCF Relay applications to use TLS 1.2 or later
WCF Relay listeners that still negotiate TLS 1.0 can stop passing traffic through Azure Relay. The symptom appears on the sender, which connected successfully before and now fails every call with System.ServiceModel.EndpointNotFoundException: None of the connected listeners accepted the connection within the allowed timeout. If you run a WCF Relay listener on the .NET Framework, and especially one built against an older version of the WindowsAzure.ServiceBus package or Microsoft.ServiceBus.dll, it is worth checking how it negotiates TLS. Azure Relay Hybrid Connections are not affected and need no action. They use HTTP and WebSockets through the Microsoft.Azure.Relay package, a different stack from the WCF Relay path described here. What is happening TLS 1.0 and TLS 1.1 are deprecated. We retired them across Azure services, and have since retired them at the operating system level as well. That operating system change is why a listener that had run until now can fail going forward. These failures come from a listener that still asks for TLS 1.0, which older .NET Framework defaults, application configuration, registry settings, or startup code can all cause. Relay requires TLS 1.2 or later and rejects the handshake. Where that rejection lands decides what the sender sees. A listener registers with Relay once, when it opens. Relay then asks that registered listener to open a separate rendezvous connection for each sender that arrives, and each of those is a new connection with its own handshake. In this case the rendezvous connection is the one that fails. Relay tries each registered listener until it runs out, none of them accepts, and the sender gets None of the connected listeners accepted the connection within the allowed timeout. The same failure can also surface as a timeout, when the sender's timeout elapses before Relay has finished trying the registered listeners. A listener whose handshake fails when it opens never registers at all. On a persistent relay the sender then gets There are no listeners connected for the endpoint. On a dynamic relay, which is the default for the WCF Relay bindings, the endpoint exists only while a listener is connected, so the sender gets Endpoint does not exist. All three arrive as EndpointNotFoundException, so the message text is what tells them apart, and all three are what the sender sees when the listener is the side still on TLS 1.0. The side that pins the protocol sees the failure directly instead. The trace below is a sender's, and a listener's differs in its lower frames, so search on the message rather than the frames: Exception Type: System.IO.IOException Authentication failed because the remote party has closed the transport stream. Server stack trace: at System.Net.Security.SslState.InternalEndProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.Security.SslState.EndProcessAuthentication(IAsyncResult result) at Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult result) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.ServiceBus.SecureSocketUtil.<>c.<InitiateSecureClientUpgradeIfNeededAsync>b__3_1(IAsyncResult a) at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization) Relay closes the connection when the handshake offers only TLS 1.0 or 1.1, so it surfaces as a closed stream rather than a protocol mismatch. A sender that pins the protocol fails on its own connection to Relay, before Relay looks for a listener at all, so this exception is all it gets and none of the three messages appear. Whichever side logs it, the trace points at how that application negotiates TLS. Recommended actions Start with whichever application pinned the protocol, which is usually the listener. That change is scoped to the one application and is normally enough to resolve this. Check whether it sets a TLS or SSL version explicitly in code or configuration, and if it does, remove the explicit setting so the operating system chooses the protocol, or set TLS 1.2 or later. The quickest change is configuration-only. Two AppContext switches in the application configuration file put that application back on a supported protocol, and both go in a single semicolon-delimited value attribute: <configuration> <runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false;Switch.System.Net.DontEnableSystemDefaultTlsVersions=false" /> </runtime> </configuration> Rebuilding against a current .NET Framework resolves it as well. Where startup code is easier to change than configuration, setting ServiceBusEnvironment.SystemConnectivity.Mode to ConnectivityMode.Https and ServicePointManager.SecurityProtocol to SecurityProtocolType.Tls12 moves the connection to HTTPS and TLS 1.2. Applications that target .NET Framework 3.5 and use TCP transport security are pinned to SSL 3.0 and TLS 1.0, so those need to be retargeted. Where the application cannot be changed, the same behavior can be set for the whole machine through two registry values, SchUseStrongCrypto and SystemDefaultTlsVersions, added as DWORD 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319, using v2.0.50727 in place of v4.0.30319 for .NET Framework 3.5. Both values must be created, and they apply to every .NET Framework application on the machine, so treat this as the fallback. The .NET Framework TLS best practices guidance covers both approaches in full. Once the change is in place, restart the application and confirm that the listener and sender both connect. The call that previously failed should complete as soon as the Relay connection negotiates a supported TLS version. For more about the service itself, see the Azure Relay overview, the Azure Relay API overview, and the Azure Relay port settings. Help and support If you have questions, get answers from community experts in Microsoft Q&A or GitHub. If you have a support plan and you need technical help, create a support request.Announcing Grafana 13 Support in Azure Managed Grafana
Enhanced Dashboarding and Visualization Experience Grafana 13 introduces a number of improvements that make dashboards easier to build, reuse, and manage at scale. Teams can create richer observability experiences while reducing duplication and improving consistency across environments. These improvements include Dynamic Dashboards, Saved Queries, enhanced filtering and grouping experiences, dashboard templates, and additional usability enhancements that streamline dashboard authoring and discovery. From enhanced dashboard authoring experiences and reusable queries to Git-based dashboard lifecycle management, Grafana 13 helps teams build and operate observability solutions more efficiently at scale. Git Sync: Manage Dashboards as Code One of the most anticipated capabilities associated with Grafana 13 is Git Sync: enabling organizations to manage Grafana dashboards using Git-based workflows. Dashboards can be stored as JSON files in a Git repository, making it easier to version, review, and automate dashboard changes using existing engineering practices. With Git Sync, teams can: Track dashboard changes through source control. Review updates through pull requests. Integrate dashboard deployments into CI/CD pipelines. Collaborate on dashboard development using familiar Git workflows. Git Sync supports bidirectional synchronization. Changes made in Grafana can be committed back to a repository, while changes committed to the repository are automatically synchronized to Grafana. Configuration is managed directly from the Grafana UI, with authentication supported through either a GitHub App or a Personal Access Token. For customers managing large observability estates, Git Sync helps bring dashboards into existing infrastructure-as-code and platform engineering workflows. Visit MSLearn to check out Git Sync on Azure Managed Grafana. Prometheus Authentication Changes in Grafana 13 One of the most important changes in Grafana 13: using Prometheus with Azure authentication. Starting with Grafana 13, Azure authentication is no longer supported in the standard open-source Prometheus data source. Instead, Azure authentication is exclusively available through the Azure Monitor Managed Service for Prometheus plugin. This change aligns with Grafana Labs' updated Prometheus data source strategy and deprecation guidance. Customers do not need to modify existing dashboards as part of this transition. Dashboards remain compatible across both plugin versions, and existing visualizations, imports, exports, and dashboard definitions continue to work as expected. Connectivity and query execution against Azure Monitor Workspaces and Azure Monitor Managed Service for Prometheus endpoints will use the Azure-specific plugin that now owns Azure authentication support. Prometheus data sources configured with non-Azure authentication methods are unaffected by this change and continue to operate without modification. We Recommend: You can start using Grafana 13 today by creating a new Azure Managed Grafana workspace and selecting Grafana 13. We encourage customers to explore the new dashboarding experiences introduced in Grafana 13 and review their Prometheus configurations to understand how Azure-authenticated data sources are transitioned to the Azure Monitor Managed Service for Prometheus plugin. Existing dashboards continue to work without changes. Customers do not need to: Recreate dashboards. Update visualizations. Modify dashboard JSON definitions. Reconfigure imports or exports. For additional guidance, see the Azure Managed Grafana documentation: Configure Bundled Prometheus (preview) in Azure Managed Grafana | Microsoft Learn Add an Azure Monitor workspace to Azure Managed Grafana | Microsoft Learn How to manage data sources for Azure Managed Grafana | Microsoft Learn Connect Grafana to Azure Monitor managed service for Prometheus - Azure Monitor | Microsoft Learn For additional details about Grafana 13, refer to the official Grafana Labs release announcement and release notes.Security Review for Microsoft Edge version 150
We have reviewed the new settings in Microsoft Edge version 150 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 150 introduced 8 new Computer and User settings; we have included a spreadsheet listing the new settings to make it easier for you to find. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baselines Discussion site or this post.
Introducing the Azure Maps Geocode Autocomplete API
We’re thrilled to unveil the public preview of Azure Maps Geocode Autocomplete API, a powerful REST service designed to modernize and elevate autocomplete capabilities across Microsoft’s mapping platforms. If you’ve ever started typing an address into a search bar and immediately seen a list of relevant suggestions—whether it’s for a landmark, or your own home—you’ve already experienced the convenience of autocomplete. What’s less obvious is just how complex it is to deliver those suggestions quickly, accurately, and in a format that modern applications can use. That’s exactly the challenge this new API is designed to solve. Why Autocomplete Matters More Than Ever The Azure Maps Geocode Autocomplete API is the natural successor to the Bing Maps Autosuggest REST API, designed to meet the growing demand for intelligent, real-time location suggestions across a wide range of applications. It’s an ideal solution for developers who need reliable and scalable autocomplete functionality—whether for small business websites or large-scale enterprise systems. Key use cases include: Store locators: When a customer starts typing “New Yo…” into store locator, autocomplete instantly suggests “New York, N.Y.” With just a click, the map centers on the right location—making it fast and effortless to find the nearest branch. Rideshare or dispatching platforms: A rideshare driver needs to pick up a passenger at “One Microsoft Way.” Instead of typing out the full address, the driver starts entering “One Micro…” and the app instantly offers the correct road segment in Redmond, Washington. Delivery services: A delivery app can limit suggestions to postal codes within a specific region, ensuring the addresses customers choose are deliverable and reducing the risk of failed shipments Any Web UIs requiring location input: From real estate search to form autofill, autocomplete enhances the user experience wherever accurate location entry is needed. What the API Can Do The Geocode Autocomplete API is designed to deliver fast, relevant, and structured suggestions as users type. Key capabilities include: Entity Suggestions: Supports both Place (e.g., administrative districts, populated places, landmarks, postal codes) and Address (e.g., roads, point addresses) entities. Ranking: Results can be ranked based on entity popularity, user location (coordinates), and bounding box (bbox). Structured Output: Returns suggestions with structured address formats, making integration seamless. Multilingual Support: Set up query language preferences via the Accept-Language parameter. Flexible Filtering: You can filter suggestions by specifying a country or region using countryRegion, or by targeting a specific entity subtype using resultType. This allows you to extract entities with precise categorization—for example, you can filter results to return only postal codes to match the needs of a location-based selection input in your web application. How It Works The Geocode Autocomplete API is accessed via the following endpoint: https://atlas.microsoft.com/geocode:autocomplete?api-version=2025-06-01-preview This endpoint provides autocomplete-style suggestions for addresses and places. With just a few parameters, like your Azure Maps subscription key, a query string, and optionally user coordinates or a bounding box, you can start returning structured suggestions instantly. Developers can further issue geocode service with the selected/ideal entity as query to locate the entity on map, which is a common scenario for producing interactive mapping experiences. Let’s look at below examples: Example 1: Place Entity Autocomplete GET https://atlas.microsoft.com/geocode:autocomplete?api-version=2025-06-01-preview &subscription-key={YourAzureMapsKey} &coordinates={coordinates} &query=new yo &top=3 A user starts typing “new yo.” The API quickly returns results like “New York City” and “New York State,” each complete with structured metadata you can plug directly into your app. { "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": { "typeGroup": "Place", "type": "PopulatedPlace", "geometry": null, "address": { "locality": "New York", "adminDistricts": [ { "name": "New York", "shortName": "N.Y." } ], "countryRegions": { "ISO": "US", "name": "United States" }, "formattedAddress": "New York, N.Y." } } }, { "type": "Feature", "properties": { "typeGroup": "Place", "type": "AdminDivision1", "geometry": null, "address": { "locality": "", "adminDistricts": [ { "name": "New York", "shortName": "N.Y." } ], "countryRegions": { "ISO": "US", "name": "United States" }, "formattedAddress": "New York" } } }, { "type": "Feature", "properties": { "typeGroup": "Place", "type": "AdminDivision2", "geometry": null, "address": { "locality": "", "adminDistricts": [ { "name": "New York", "shortName": "N.Y." }, { "name": "New York County" } ], "countryRegions": { "ISO": "US", "name": "United States" }, "formattedAddress": "New York County" } } } ] } Example 2: Address Entity Autocomplete GET https://atlas.microsoft.com/geocode:autocomplete?api-version=2025-06-01-preview &subscription-key={YourAzureMapsKey} &bbox={bbox} &query=One Micro &top=3 &countryRegion=US A query for “One Micro” scoped to the U.S. yields “NE One Microsoft Way, Redmond, WA 98052, United States.” That’s a complete, structured address ready to be mapped, dispatched, or stored. { "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": { "typeGroup": "Address", "type": "RoadBlock", "geometry": null, "address": { "locality": "Redmond", "adminDistricts": [ { "name": "Washington", "shortName": "WA" }, { "name": "King County" } ], "countryRegions": { "ISO": "US", "name": "United States" }, "postalCode": "98052", "streetName": "NE One Microsoft Way", "addressLine": "", "formattedAddress": "NE One Microsoft Way, Redmond, WA 98052, United States" } } } ] } Example 3: Integration with Web Application Below sample shows user enter query and autocomplete service provide a series of suggestions based on user query and location. Pricing and Billing The Geocode Autocomplete API uses the same metering model as the Azure Maps Search service. For billing purposes, every 10 Geocode Autocomplete API requests are counted as one billable transaction. This approach keeps usage and costs consistent with what developers are already familiar with in Azure Maps. Ready to Build Smarter Location Experiences? Whether you're powering a store locator, enhancing address entry, or building a dynamic dispatch system, the new Geocode Autocomplete API gives you the precision, flexibility, and performance needed to deliver seamless location intelligence. With real-world use cases already proving its value, now is the perfect time to integrate this service into your applications and unlock richer, more interactive mapping experiences. Let’s build what’s next—faster, smarter, and more intuitive. Resources to Get Started Geocode Autocomplete REST API Documentation Geocode Autocomplete Samples Migrate from Bing Maps to Azure Maps How to use Azure Maps APIsBuild Your AI Agent in 5 Minutes with AI Toolkit for VS Code
What if building an AI agent was as easy as filling out a form? No frameworks to install. No boilerplate to copy-paste from GitHub. No YAML to debug at midnight. Just VS Code, one extension, and an idea. AI Toolkit for VS Code turns agent development into something anyone can do — whether you're a seasoned developer who wants full code control, or someone who's never touched an AI framework and just wants to see something work. Let's build an agent. Then let's explore what else this toolkit can do. Getting Set Up You need two things: VS Code — download and install if you haven't already AI Toolkit extension — open VS Code, go to Extensions (Ctrl+Shift+X), search "AI Toolkit", and install it That's it. No terminal commands. No dependencies to wrangle. When AI Toolkit installs, it brings everything it needs — including the Microsoft Foundry integration and GitHub Copilot skills for agent development. Once installed, you'll see a new AI Toolkit icon in the left sidebar. Click it. That's your home base for everything we're about to do. Build an Agent — No Code Required Open the Command Palette (Ctrl+Shift+P) and type "Create Agent". You'll see a clean panel with two options side by side: Design an Agent Without Code — visual builder, perfect for getting started Create in Code — full project scaffolding, for when you want complete control Click "Design an Agent Without Code." Agent Builder opens up. Now fill in three things: Give it a name Something descriptive. For this example: "Azure Advisor" Pick a model Click the model dropdown. You'll see a list of available models — GPT-4.1, Claude Opus 4.6, and others. Foundry models appear at the top as recommended options. Pick one. Here's a nice detail: you don't need to know whether your model uses the Chat Completions API or the Responses API. AI Toolkit detects this automatically and handles the switch behind the scenes. Write your instructions This is where you tell the agent who it is and how to behave. Think of it as a personality brief: Hit Run That's it. Click Run and start chatting with your agent in the built-in playground. Want More Control? Build in Code The no-code path is great for prototyping and prompt engineering. But when you need custom tools, business logic, or multi-agent workflows — switch to code. From the Create Agent View, choose "Create in Code with Full Control." You get two options: Scaffold from a template Pick a pre-built project structure — single agent, multi-agent, or LangGraph workflow. AI Toolkit generates a complete project with proper folder structure, configuration files, and starter code. Open it, customize it, run it. Generate with GitHub Copilot Describe your agent in plain English in Copilot Chat: "Create a customer support agent that can look up order status, process returns, and escalate to a human when the customer is upset." Copilot generates a full project — agent logic, tool definitions, system prompts, and evaluation tests. It uses the microsoft-foundry skill, the same open-source skill powering GitHub Copilot for Azure. AI Toolkit installs and keeps this skill updated automatically — you never configure it. The output is structured and production-ready. Real folder structure. Real separation of concerns. Not a single-file script. Either way, you get a project you can version-control, test, and deploy. Cool Features You Should Know About Building the agent is just the beginning. Here's where AI Toolkit gets genuinely impressive. 🔧 Add Real Tools with MCP Your agent can do more than just talk. Click Add Tool in Agent Builder to connect MCP (Model Context Protocol) servers — these give your agent real capabilities: Search the web Query a database Read files Call external APIs Interact with any service that has an MCP server You control how much freedom your agent gets. Set tool approval to Auto (tool runs immediately) or Manual (you approve each call). Perfect for when you trust a read-only search tool but want oversight on anything that takes action. You can also delete MCP servers directly from the Tool Catalog when you no longer need them — no config file editing required. 🧠 Prompt Optimizer Not sure if your instructions are good enough? Click the Improve button in Agent Builder. The Foundry Prompt Optimizer analyzes your prompt and rewrites it to be clearer, more structured, and more effective. It's like having a prompt engineering expert review your work — except it takes seconds. 🕸️ Agent Inspector When your agent runs, open Agent Inspector to see what's happening under the hood. It visualizes the entire workflow in real time — which tools are called, in what order, and how the agent makes decisions. 💬 Conversations View Agent Builder includes a Conversations tab where you can review the full history of interactions with your agent. Scroll through past conversations, compare how your agent handled different scenarios, and spot patterns in where it succeeds or struggles. 📁 Everything in One Sidebar AI Toolkit puts everything in a single My Resources panel: Recent Agents — one-click access to agents you've been working on Local Resources — your local models, agents, and tools Foundry Resources — remote agents and models (if connected) Why AI Toolkit? There are other ways to build agents. What makes this different? Everything is in VS Code. You don't context-switch between a web UI, a CLI, and an IDE. Discovery, building, testing, debugging, and deployment all happen in one place. No-code and code-first aren't separate products. They're two views of the same agent. Start in Agent Builder, click View Code, and you have a full project. Or go the other way — build in code and test in the visual playground. Copilot is deeply integrated. Not as a chatbot bolted on the side — as an actual development tool that understands agent architecture and generates production-quality scaffolding. Wrapping Up: 📥 Install: AI Toolkit on the VS Code Marketplace 📖 Learn: AI Toolkit Documentation Open VS Code. Ctrl+Shift+P. Type "Create Agent." Five minutes from now, you'll have an agent running. 🚀
Simplify Virtual WAN Spoke Connectivity at Scale with Azure Virtual Network Manager
With Azure Virtual Network Manager (AVNM) integration, organizations using Virtual WAN for transitive connectivity can simplify spoke connectivity and policy management across large-scale hub-and-spoke deployments. By using a Virtual WAN hub as the hub in an AVNM hub-and-spoke topology, organizations can define connectivity and routing intent once at the network group level and apply it consistently across large numbers of spoke VNets. This reduces repetitive per-spoke connection and routing configuration, helps maintain operational consistency as deployments expand, and makes it easier to manage hub-and-spoke environments at scale. Together, AVNM’s centralized, group-based orchestration and Virtual WAN’s managed routing, security integration, and hybrid connectivity provide a more streamlined way to simplify operations and scale with confidence. What is Azure Virtual Network Manager? Azure Virtual Network Manager is a management service that lets you group, configure, and deploy network connectivity and security policies across virtual networks at scale. Instead of configuring VNet peering and access rules on each virtual network individually, you define network groups — logical collections of virtual networks based on static selection or dynamic Azure Policy conditions — and apply connectivity configurations and security admin rules to those groups. Key capabilities include: Hub-and-spoke and mesh topologies — Define how virtual networks in a network group connect to a central hub or to each other. Network groups — Group VNets statically or dynamically (using tags, subscriptions, resource group names, or other Azure Policy conditions). Security admin rules — Author and enforce access control lists across all VNets in a network group, providing a centralized layer of defense that complements NSGs and firewalls. Region-scoped deployment — Deploy configurations to specific Azure regions, enabling incremental rollout and controlled blast radius. AVNM operates as an overlay management layer — it orchestrates VNet peering, connectivity, and security rules without replacing the underlying networking primitives. What is Azure Virtual WAN? Azure Virtual WAN as a service brings together routing, security, VPN, ExpressRoute, and transitive connectivity in a hub-and-spoke architecture. A Virtual WAN hub is a managed regional resource that acts as a central transit point for branch connectivity, remote users, private enterprise connectivity, spoke virtual networks, and private traffic routing through security services. Site-to-site VPN connectivity (branch offices, SD-WAN devices) Point-to-site VPN connectivity (remote users) ExpressRoute private connectivity (on-premises datacenters) VNet-to-VNet transitive connectivity (spoke virtual networks) Routing, firewall, and encryption for private traffic All hubs in a Standard Virtual WAN are connected in a full mesh over the Microsoft backbone, enabling any-to-any connectivity between spokes, branches, and remote users across regions. Virtual WAN removes the need to manually manage complex route tables and transit VNets — routing is handled by the hub's built-in router. What this integration enables When you select a Virtual WAN hub as the hub in an AVNM connectivity configuration, AVNM handles the spoke-to-hub wiring for you. For each virtual network in your selected network groups: If the VNet is not yet connected to the Virtual WAN hub, AVNM creates the Virtual Network connection to Virtual WAN hub and applies a consistent routing configuration with Virtual WAN connection policy. If the VNet is already connected, AVNM updates the existing Virtual Network connection to utilize the routing properties in the Virtual WAN connection policy. A connection policy is a hub-level Virtual WAN resource that defines shared routing behavior for the virtual network connections it governs, including route table association and propagation, route maps, internet security settings, and propagated labels. Because the policy applies these settings consistently across governed connections, it helps standardize routing and overrides conflicting settings configured directly on individual connections. How it works The setup follows AVNM's standard workflow: Create a network group. Add virtual networks as members — either statically (by selecting specific VNets) or dynamically (using Azure Policy conditions such as tags or resource group names). Create a connectivity configuration. Choose hub-and-spoke topology, select your Virtual WAN hub as the hub, and select or create a connection policy. Deploy. Commit the configuration to your target regions. AVNM connects all VNets in the network groups to the Virtual WAN hub and applies the connection policy in parallel. You can also enable direct connectivity within a spoke network group. When enabled, VNet-to-VNet traffic within that group routes directly between virtual networks instead of transiting the Virtual WAN hub — useful for latency-sensitive or high-throughput east-west workloads. By default, direct connectivity is regional; enable global mesh to extend it across Azure regions. Key use cases Bulk spoke onboarding Connect many virtual networks to a Virtual WAN hub in one operation. All connections are orchestrated in parallel by AVNM, and the pre-defined routing configuration is automatically applied. Policy-based dynamic onboarding Use Azure Policy to define network group membership conditions. When a new virtual network matches those conditions—for example, a VNet tagged env:prod—it is automatically added to the network group. On the next deployment, AVNM connects it to the Virtual WAN hub with the correct routing configuration, reducing manual onboarding effort. Batch routing configuration updates Push routing changes to all virtual networks in a network group as a single, fully parallelized operation. This significantly reduces maintenance window duration for network-wide changes and makes rollback straightforward. Incremental deployment Segment your network into precise update domains by creating separate network groups — for example, by environment (staging, dev, production) or by region. Deploy connection policies to each group or region independently. This lets you test changes on a smaller subset before applying them broadly, minimizing blast radius. Mesh for selective inspection bypass If you use routing intent to send all private traffic through a firewall in the Virtual WAN hub, certain high-throughput or latency-sensitive flows (such as database replication) may benefit from bypassing that inspection. Enable direct connectivity in AVNM to create a mesh between selected spokes, allowing VNet-to-VNet traffic to route directly while all other traffic continues through the hub firewall. Security admin rules at scale Define network groups for your Virtual WAN spokes, then use AVNM security admin rules to author and deploy access control lists across those spokes. This provides an additional layer of defense alongside next-generation firewalls in the Virtual WAN hub. Getting started Prerequisites: An existing Azure Virtual Network Manager instance An existing Azure Virtual WAN and Virtual WAN hub One or more virtual networks to use as spoke members To configure: Go to your Network Manager instance in the Azure portal. Create a network group and add your spoke VNets. Create a connectivity configuration → select hub-and-spoke → select your Virtual WAN hub → select or create a connection policy → add spoke network groups. Deploy the configuration to your target regions. In your Virtual WAN resource, verify that the expected spoke VNet connections are in a connected state. Review effective routes in the virtual hub to confirm routing behavior matches the selected connection policy. For detailed step-by-step instructions, see Configure Azure Virtual WAN hub for Azure Virtual Network Manager. For more on connection policy, see Connection policy in Azure Virtual WAN. Learn more Azure Virtual Network Manager documentation Virtual WAN and Virtual Network Manager integration overview Azure Virtual WAN documentationScale limits in network security perimeter
Presently, network security perimeter functionality can be used to support deployments of PaaS resources with common public network controls with following scale limitations: Limitation Description Number of network security perimeters Supported up to 100 as recommended limit per subscription. Profiles per network security perimeters Supported up to 200 as recommended limit. Number of rule elements per profile Supported up to 200 for inbound and outbound each as hard limit. Number of PaaS resources across subscriptions associated with the same network security perimeter Supported up to 1000 as recommended limit. These limits were deployed as soft limits. The updated limits will be as given in the table below and will now be implemented as hard limits Limitation Description Number of network security perimeters Supported up to 1000 as hard limit per subscription. Profiles per network security perimeters Supported up to 200 as hard limit. Number of rule elements per profile Supported up to 200 for inbound and outbound each as hard limit. Number of PaaS resources across subscriptions associated with the same network security perimeter Supported up to 2500 as hard limit. What do the changes mean to users? Rule elements' creation limit will be capped at 200 for new customers. (presently at 500) Existing customers who have rule elements >200 per profile, will be allowed to continue above 200 with an option to replace/edit, decrease/reduce but not increase/add the current rule elements without any service interruption till 10/31/26. For example, scenario(s): A user has a profile with rule elements = 400 They cannot increase/add new rule elements and try to go above 400. They can replace/edit existing rule elements and continue at 400. They can decrease/reduce rule elements to anything till 200 and that will be their upper ceiling i.e. if they reduce to 250, that will be their new upper ceiling. If they decrease/reduce to <200, say 150, they can go till 200 but not back to the 400. After 10/31/26, profiles with rule elements above 200 will be allowed to continue above 200 but only with an option to reduce. There will be no replace/edit and increase options. For example, scenario(s): A user has a profile with rule elements = 400 They cannot increase/add new rule elements and try to go above 400. They cannot replace/edit existing rule elements but can continue at 400 without touch the rule-elements. They can decrease/reduce rule elements to anything till 200 but cannot stop above 200 or maintain above 200. If they decrease/reduce to <200, say 150, they can go till 200 but not back to the 400. For questions or clarifications, please reach out to nsppmvteam@microsoft.comBring Your Own Orchestrator to Azure Container Apps Jobs
Azure Container Apps Jobs are a good fit for batch processing, ETL, machine learning, reports, and other tasks that run to completion. But when those tasks have dependencies, retries, or fan-out, you still need an orchestrator. Many teams already have one. The community-maintained Bring Your Own Orchestrator collection provides 13 templates that connect existing workflow engines to Azure Container Apps Jobs. The collection is also listed in the Microsoft Azure Container Apps template index. The idea is simple: Your orchestrator manages schedules, dependencies, retries, and workflow history. Azure Container Apps Jobs runs each containerized task and reports the result. You keep the control plane your team knows while ACA Jobs provides the execution layer. How it works Each integration follows the same flow: The orchestrator authenticates to Azure. It starts an ACA Job execution. It waits for that execution to succeed or fail. It uses the result to continue, retry, or stop the workflow. Your orchestrator ---> Azure Container Apps Job ^ | +---- execution result ---+ The templates package this flow in the native model of each platform: an Airflow operator, a Temporal Activity, an Argo workflow template, a Camunda service task, or visual actions in Logic Apps and n8n. The workload container stays independent of the orchestrator that launched it. Choose the orchestrator that fits the workflow There is no single best orchestrator for every workload. The useful question is which control plane matches the way your team models work. When this describes your team Start with Why You already operate Airflow Airflow on ACA Jobs Adds an ACA Jobs operator without replacing your Airflow deployment You need a complete Airflow environment Airflow hosted on ACA Deploys the Airflow control plane and the ACA Jobs integration Your workflows are Kubernetes-native and run from AKS Argo Workflows Uses Argo workflow templates and AKS workload identity You model long-running business processes in BPMN Camunda 8 Connects Camunda service tasks to ACA Job executions You use JSON-defined microservice workflows Conductor Uses Conductor workers and native FORK_JOIN workflows You need durable replay, heartbeats, and resilient retries Temporal Keeps Temporal as the durable control plane while ACA Jobs runs the workload You build asset-centric Python data pipelines Dagster Uses Dagster resources, ops, and dynamic mapping You build general Python flows and task automation Prefect Uses Prefect tasks, flows, and mapped execution You prefer visual automation and SaaS integrations n8n Provides visual workflows for starting and observing ACA Jobs You use Azure-native data pipelines Azure Data Factory and Fabric Provides pipeline definitions for Azure data integration workflows You need connector-rich application integration Logic Apps Standard Uses stateful workflows, connectors, and native control flow You want Azure-native, code-first durable orchestration Durable Functions Uses durable orchestrations, activities, retries, and fan-out/fan-in You already operate a Dapr-enabled workflow host Dapr Workflow Demonstrates Dapr Workflow directing external ACA Job workloads The Bring Your Own Orchestrator catalog keeps this comparison current and links to deployment instructions for every option. Before production The existing-orchestrator templates are designed around managed identity, scoped Azure RBAC, failure handling, and native fan-out/fan-in examples. Their fan-out samples default to five shards and accept configurations from 1 to 50. Treat higher shard counts as configuration support, not a throughput guarantee. Test them against your Azure quotas, orchestrator limits, and downstream systems. Two template-specific boundaries are worth calling out: Dapr Workflow is a preview architecture Azure Container Apps Jobs do not host Dapr sidecars. The Dapr workflow runtime must run in a separate Dapr-enabled host and start ACA Jobs through Azure Resource Manager. The template is therefore labeled preview architecture. Fabric still needs a native workspace run The Azure Data Factory path has live validation. The included Fabric pipeline is structurally validated but still needs a native run in a Fabric workspace. Each repository README documents its validation scope and limitations. Get started Open the template catalog. Choose the orchestrator your team already uses. Review that template's prerequisites and validation notes. Deploy the sample ACA Job with azd up . Run the single-job example, then test fan-out and failure behavior. For example, if Airflow is already your standard: git clone https://github.com/hetvip2/airflow-on-aca-jobs cd airflow-on-aca-jobs azd up The exact setup differs by orchestrator, but the target remains ACA Jobs. Try the templates Compare all 13 orchestrator templates and choose the control plane that matches your team. Review the Azure Container Apps Jobs documentation for triggers, permissions, and platform limits. Browse the ACA community template collections to find the collection in the Microsoft Azure Container Apps repository. Closing thoughts Using Azure Container Apps Jobs should not require an orchestrator migration. Keep the workflow engine your team already trusts and use ACA Jobs for containerized task execution. Explore all 13 options in the Bring Your Own Orchestrator to Azure Container Apps Jobs collection. References Azure Container Apps Jobs overview Azure Container Apps Jobs management API Managed identities in Azure Container Apps Azure Developer CLI documentation Bring Your Own Orchestrator template catalog Azure Container Apps community template collections
