Is there no way to get better support for Azure - esp for SEV A tickets
We have had a sev A ticket open for over 5 days, and are incurring thousands in losses every day, and despite assurances from the Azure Support that it is being solved in hours and then having confirmations that it is solved, the issue is still not solved. I have asked numerous times to get our teams in touch with actual microsoft employees, not front end contractors, who is more like level 1 support, and just running messages between customer and back end team, and really are powerless to handle any suport issues themselves, and they are on complete mercy of "other teams" yet as a customer, apparantly we cant even get on a call with these other teams, and the poor front end contractors are getting the brunt of our pain. Absolutely are in the dark, as to what is actually happening in the back end, other than "trust me bro" we are working on it. No eta, no explanation.. hard to fathom how this can go on like thisFrom Scale to Breakthrough: Azure NetApp Files Sets a New Cloud Benchmark for EDA Performance
This article spotlights the newest leap in Azure NetApp Files: large volume breakthrough mode performance – independently validated by SPECstorage® Solution 2020 benchmarks. Azure NetApp Files is setting a new record for enterprise-scale Electronic Design Automation (EDA) workloads in the cloud. Backed by benchmark results at enterprise scale, it further reduces the traditional tradeoff between massive scale and uncompromising storage performance. For EDA teams, this means storage can keep pace with design cycles – enabling faster iteration, supporting cloud-first workflows, and reducing time spent waiting on infrastructure.Building AI Agents with Microsoft Foundry: A Progressive Lab from Hello World to Self-Hosted
AI agent development has a steep on-ramp. The combination of new SDKs, tool-calling patterns, model selection decisions, retrieval-augmented generation, and deployment concerns means most developers spend more time wiring things together than actually building anything useful. The Microsoft Foundry Agent Lab is a structured, open-source demo series designed to change that — nine self-contained demos, each adding exactly one new concept, all built on the same Microsoft Foundry SDK and a single model deployment. This post walks through what the lab contains, how each demo works under the hood, and the architectural decisions that make it a useful reference for AI engineers building production agents. Why a Progressive Lab? Agent frameworks can be overwhelming. A developer who opens a rich example with RAG, tool-calling, streaming, and a custom UI all at once has no clear line of sight to which parts are essential and which are embellishments. The Foundry Agent Lab takes the opposite approach: start with the absolute minimum and introduce one new primitive per demo. By the time you reach Demo 8, you have seen every major capability — not in one monolithic sample, but in a layered sequence where each addition is visible and understandable. # Demo New Concept Tool Used UX 0 hello-demo Agent creation, Responses API, conversations None Terminal 1 tools-demo Function calling, tool-calling loop, live API FunctionTool Terminal 2 desktop-demo UI decoupling — same agent, different surface None Desktop (Tkinter) 3 websearch-demo Server-side built-in tools, no client loop WebSearchTool Terminal 4 code-demo Code execution in sandbox, Gradio web UI CodeInterpreterTool Web (Gradio) 5 rag-demo Document upload, vector stores, RAG grounding FileSearchTool Terminal 6 mcp-demo MCP servers, human-in-the-loop approval MCPTool Terminal 7 toolbox-demo Centralized tool governance, Toolbox versioning Toolbox Terminal 8 hosted-demo Self-hosted agent with Responses protocol Custom server Terminal + Agent Inspector The Model Router: One Deployment to Rule Them All Before diving into the demos, it is worth understanding the one architectural decision that ties the entire lab together: every agent uses model-router as its model deployment. MODEL_DEPLOYMENT=model-router Model Router is a Microsoft Foundry capability that inspects each request at inference time and routes it to the optimal available model — weighing task complexity, cost, and latency. A simple factual question goes to a fast, cheap model. A complex tool-calling chain with code generation gets routed to a frontier model. You write zero routing logic. The lab's MODEL-ROUTER.md file contains empirical observations from running all nine demos. A sample of what the router selected: Demo Query Task Type Model Selected hello "What's the capital of WA state?" Factual recall grok-4-1-fast-reasoning hello "Summarize our conversation" Summarization gpt-5.2-chat-2025-12-11 tools "What's the weather in Seattle?" Tool-using gpt-5.4-mini-2026-03-17 code Data analysis with code generation Code generation + execution gpt-5.4-2026-03-05 rag HR policy document question Retrieval + synthesis gpt-5.3-chat-2026-03-03 This is the strongest signal in the lab: you do not need to reason about model selection. You declare what your agent needs to do; the router handles the rest, and it chooses correctly. Demo 0: The Minimum Viable Agent The hello-demo establishes the baseline pattern used by every subsequent demo. Two files: one to register the agent, one to chat with it. Registering the agent from azure.identity import DefaultAzureCredential from azure.ai.projects import AIProjectClient from azure.ai.projects.models import PromptAgentDefinition credential = DefaultAzureCredential() project = AIProjectClient(endpoint=PROJECT_ENDPOINT, credential=credential) agent = project.agents.create_version( agent_name=AGENT_NAME, definition=PromptAgentDefinition( model=MODEL_DEPLOYMENT, instructions="You are a helpful, friendly assistant.", ), ) Authentication uses DefaultAzureCredential , which works with az login locally and with managed identity in production — no API keys anywhere in the code. Chatting with the agent # Create a server-side conversation (persists history across turns) conversation = openai.conversations.create() # Each turn sends the user message; the agent sees full history response = openai.responses.create( input=user_input, conversation=conversation.id, extra_body={"agent_reference": {"name": AGENT_NAME, "type": "agent_reference"}}, ) print(response.output_text) The conversation object is server-side. You pass its ID on every turn; the history lives in Foundry, not in a local list. This is the Responses API pattern — distinct from the older Completions or Chat Completions APIs. Demo 1: Function Tools and the Tool-Calling Loop Demo 1 adds function calling against a real weather API. The key insight here is that the model does not execute the function — it requests the execution, and your code executes it locally, then feeds the result back. Declaring a function tool from azure.ai.projects.models import FunctionTool, PromptAgentDefinition func_tool = FunctionTool( name="get_weather", description="Get the current weather for a given city.", parameters={ "type": "object", "properties": {"city": {"type": "string", "description": "City name"}}, "required": ["city"], }, strict=True, ) agent = project.agents.create_version( agent_name=AGENT_NAME, definition=PromptAgentDefinition( model=MODEL_DEPLOYMENT, tools=[func_tool], instructions="You are a weather assistant...", ), ) The tool-calling loop response = openai.responses.create(input=user_input, conversation=conversation.id, ...) # Loop while the model is requesting tool calls while any(item.type == "function_call" for item in response.output): input_list = [] for item in response.output: if item.type == "function_call": args = json.loads(item.arguments) result = get_weather(args["city"]) # execute locally input_list.append(FunctionCallOutput(call_id=item.call_id, output=result)) # Send results back to the agent response = openai.responses.create(input=input_list, conversation=conversation.id, ...) print(response.output_text) The strict=True parameter on FunctionTool enforces structured outputs — the model must return arguments that match the declared JSON schema exactly. This eliminates argument parsing errors in production. Demo 2: UI Is Not Your Agent Demo 2 runs the exact same agent as Demo 1 but surfaces it in a Tkinter desktop window. The point is pedagogical: your agent definition, conversation management, and tool-calling logic are entirely independent of your UI layer. Swapping from terminal to desktop requires changing only the presentation code — nothing in the agent or conversation path changes. This is a principle worth internalising early: agent logic and UI logic should never be entangled. The lab enforces this separation structurally. Demo 3: Server-Side Built-In Tools The web search demo introduces a sharp contrast with Demo 1. With WebSearchTool , the tool-calling loop disappears entirely from client code: from azure.ai.projects.models import WebSearchTool agent = project.agents.create_version( agent_name="Search-Agent", definition=PromptAgentDefinition( model=MODEL_DEPLOYMENT, tools=[WebSearchTool()], instructions="You are a research assistant...", ), ) The agent decides when to search, executes the search server-side, and returns a grounded response with citations. Your client code looks identical to Demo 0 — a simple responses.create() call with no tool loop. The distinction matters architecturally: Function tools (Demo 1) — tool execution happens on your client; you control the code, the API call, the error handling. Built-in tools (Demo 3+) — tool execution happens inside Foundry; you get results without managing execution. Demo 4: Code Interpreter and the Gradio Web UI Demo 4 attaches CodeInterpreterTool , which gives the agent a sandboxed Python execution environment inside Foundry. The agent can write code, run it, observe output, and iterate — all server-side. Combined with a Gradio web interface, this demo shows an agent that can perform data analysis, generate charts, and explain results through a browser UI. Model Router is particularly interesting here: the empirical data shows it selects a more capable frontier model ( gpt-5.4-2026-03-05 ) for code-generation tasks, while simpler conversational turns stay on lighter models. Demo 5: Retrieval-Augmented Generation with FileSearchTool Demo 5 introduces RAG. The setup phase uploads a document, creates a vector store, and attaches it to the agent: # Upload document and create a vector store vector_store = openai.vector_stores.create(name="employee-handbook-store") with open("data/employee-handbook.md", "rb") as f: openai.vector_stores.files.upload_and_poll( vector_store_id=vector_store.id, file=f ) # Attach the vector store to the agent agent = project.agents.create_version( agent_name="RAG-Agent", definition=PromptAgentDefinition( model=MODEL_DEPLOYMENT, tools=[FileSearchTool(vector_store_ids=[vector_store.id])], instructions="Answer questions using only the provided documents...", ), ) At query time, the agent embeds the question, searches the vector store semantically, retrieves matching chunks, and generates an answer grounded in the retrieved content — entirely server-side. The client code remains a plain responses.create() call. An important detail: the .vector_store_id file is written to disk during setup and read back during the chat session, so the demo survives process restarts without re-uploading the document. The .gitignore excludes this file from source control. Demo 6: Model Context Protocol Demo 6 connects the agent to a GitHub MCP server, giving it access to repository and issue data via the open Model Context Protocol standard. MCP servers expose tools over a standardised wire protocol; the agent discovers and calls them without any client-side function declarations. The demo also demonstrates human-in-the-loop approval: before executing any MCP tool call, the agent surfaces the proposed action and waits for the user to confirm. This is an important safety pattern for agents that can trigger side effects on external systems. Demo 7: Toolbox — Centralised Tool Governance Where Demo 6 connects to a single MCP server directly, Demo 7 uses a Toolbox — a managed Microsoft Foundry resource that bundles multiple tools into a single, versioned, MCP-compatible endpoint. The Toolbox in this demo exposes both GitHub Issues and GitHub Repos tools, curated into an immutable versioned snapshot. This pattern is significant for production multi-agent systems: Centralised governance — one team owns the tool definitions; all agents consume them via a single endpoint. Versioned snapshots — promoting a new Toolbox version is explicit; agents pin to a version and upgrade intentionally. MCP compatibility — any MCP-capable agent or framework can connect, not just Foundry SDK agents. from azure.ai.projects.models import McpTool toolbox_tool = McpTool( server_label="toolbox", server_url=TOOLBOX_ENDPOINT, allowed_tools=[], # empty = all tools in the Toolbox version headers={"Authorization": f"Bearer {token}"}, ) Demo 8: Self-Hosted Agent with the Responses Protocol The final demo departs from the prompt-agent pattern. Instead of registering a declarative agent in Foundry, Demo 8 implements a custom agent server using the Responses protocol. The server exposes a streaming HTTP endpoint; Foundry's Agent Inspector can connect to it and route user turns to it just as it would to a hosted prompt agent. This demo includes a Dockerfile and an agent.yaml , enabling deployment to Foundry's container hosting service. It uses gpt-4.1-mini directly rather than the model router, because the custom server owns the entire inference path. When to consider this pattern: Your agent requires custom pre- or post-processing logic that cannot be expressed in a system prompt. You need to integrate with infrastructure that is not reachable through MCP or built-in tools. You want to own the inference call for cost control, A/B testing, or compliance reasons. You are building a multi-agent orchestrator that needs to expose itself as an agent to other orchestrators. Getting Started The lab requires Python 3.10 or higher, an Azure subscription with a Microsoft Foundry project, and the Azure CLI. 1. Clone and set up the virtual environment git clone https://github.com/microsoft-foundry/Foundry-Agent-Lab.git cd Foundry-Agent-Lab # Create and activate the virtual environment python -m venv .venv # Windows Command Prompt .venv\Scripts\activate.bat # Windows PowerShell .venv\Scripts\Activate.ps1 # macOS / Linux source .venv/bin/activate pip install -r requirements.txt 2. Configure a demo copy hello-demo\.env.sample hello-demo\.env # Edit hello-demo\.env and set PROJECT_ENDPOINT Your PROJECT_ENDPOINT is on the Overview page of your Foundry project in the Azure portal. It takes the form https://your-resource.ai.azure.com/api/projects/your-project . 3. Run the demo az login 0-hello-demo Each numbered batch file at the root activates the virtual environment, runs create_agent.py , and launches chat.py . Append log to capture the full session transcript: 0-hello-demo log Reset between runs hello-demo\reset.bat Every demo includes a reset.bat that deletes the registered agent and any associated resources (vector stores, uploaded files). Demos are fully repeatable. Architecture Principles Demonstrated Across the nine demos, the lab illustrates a set of design principles that apply directly to production agent systems: Keyless authentication throughout Every demo uses DefaultAzureCredential . No API keys appear anywhere in the code. Locally, az login provides credentials. In production, managed identity takes over automatically — same code, no secrets to rotate. Server-side conversation state The Responses API stores conversation history server-side. Your application passes a conversation ID; Foundry maintains the thread. This eliminates the common bug of truncating history due to local list management and makes multi-process or multi-instance deployments straightforward. Client-side vs server-side tool execution The lab makes the distinction explicit. Function tools execute in your process — you control the code, the external call, and the error handling. Built-in tools (WebSearch, CodeInterpreter, FileSearch) execute inside Foundry — you get results without managing execution infrastructure. MCP tools (Demo 6, 7) fall between these: they execute in a separately deployed server, with the protocol mediating the call. Progressive tool introduction Each demo's create_agent.py registers the agent once. The chat.py file handles the conversation loop. These two responsibilities are always separate, making it easy to update agent definitions without modifying conversation logic, and vice versa. Security Considerations When building agents for production, keep the following in mind: Never commit .env files. The .gitignore excludes them, but verify this before pushing. Use Azure Key Vault or environment variable injection in CI/CD pipelines. Use managed identity in production. DefaultAzureCredential automatically picks up managed identity when deployed to Azure, eliminating the need for any stored credentials. Apply human-in-the-loop for side-effecting tools. Demo 6 demonstrates this pattern for MCP tool calls. Any agent that can modify external state (create issues, send emails, write files) should surface proposed actions for confirmation. Validate tool outputs before use. Treat data returned by external tools (weather APIs, search results, document retrieval) as untrusted input. Prompt injection through tool results is a real attack surface; grounding instructions in your system prompt reduce but do not eliminate this risk. Scope Toolbox permissions narrowly. When using a Toolbox (Demo 7), use allowed_tools to restrict which tools the agent can call, rather than granting access to all tools in a Toolbox version. Key Takeaways Start with the minimum. A prompt agent with no tools requires fewer than 30 lines of code using the Foundry SDK. Add tools only when the use case demands them. Use model-router unless you have a specific reason not to. The empirical data in the lab shows the router selects appropriate models across all task types — factual, creative, tool-calling, RAG, and code generation. Understand the client/server tool boundary. Function tools give you control; built-in tools give you simplicity. MCP and Toolbox give you governance and interoperability. Choose based on where you need control and where you need scale. Conversation state belongs on the server. Do not maintain conversation history in application memory if you can avoid it. The Responses API conversation object is designed for this. The hosted-demo pattern is for when you need to own the inference path. For most use cases, a declarative prompt agent is sufficient and far simpler to operate. Next Steps Explore the repo: github.com/microsoft-foundry/Foundry-Agent-Lab Microsoft Foundry SDK documentation: learn.microsoft.com/azure/ai-studio/ Responses API quickstart: Prompt agent quickstart Model Router conceptual documentation: Model Router for Microsoft Foundry Model Context Protocol: modelcontextprotocol.io Azure Identity SDK (DefaultAzureCredential): azure-identity Python SDK The Foundry Agent Lab is open source under the MIT licence. Contributions, bug reports, and feature requests are welcome through GitHub Issues. See CONTRIBUTING.md for guidelines.
OIDC vs SPN: Securing Azure Deployments with GitHub Actions & Terraform
From Secrets to Trust: Modernizing CI/CD Authentication When building infrastructure pipelines on Microsoft Azure using GitHub Actions and Terraform, one design choice quietly determines your entire security posture: How does your pipeline authenticate to Azure? For years, the answer was simple: Use a Service Principal (SPN) Store a client secret in GitHub Authenticate using credentials It works—but it doesn’t scale securely. This article walks through a real, production-ready implementation comparing: SPN (Client Secret – legacy pattern) OIDC (Federated Identity – modern standard) Backed by a working repo: WorkFlowBasedDeployment Architecture Overview This repository implements a workflow-driven Terraform deployment model with modular Azure infrastructure. Repository Structure .github/workflows/ deploy-infrastructure.yml # OIDC deployment deploy-infrastructure-spn.yml # SPN deployment destroy-infrastructure.yml # OIDC destroy destroy-infrastructure-spn.yml # SPN destroy Deployment/ main.tf providers.tf variables.tf terraform.tfvars modules/ Azure Resources Provisioned Resource Module Resource Group Virtual Network + NSGs vnet rg-network Storage Account sa rg-data Container Apps containerapps rg-compute AI Foundry aifoundry rg-data AI Search aisearch rg-data Azure Container Registry acr rg-compute Key Vault azkeyvault rg-data Monitoring azmonitor rg-compute Private Endpoints private_endpoints rg-network Authentication Models Service Principal (SPN) – The Traditional Way How it works Create App Registration Generate client secret Store it in GitHubTerraform authenticates using environment variables env: ARM_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }} ARM_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }} ARM_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }} The problem Risk Impact Long-lived secrets Can be leaked Manual rotation Operational burden Repo compromise Full environment exposure This model is still supported—but increasingly considered legacy for secure pipelines. OIDC (OpenID Connect) – The Modern Approach How it works GitHub Actions generates a short-lived identity token Microsoft Entra ID validates it Azure issues a temporary access token Terraform executes using that token No secrets. No storage. No rotation. Authentication Models Compared OIDC Flow (Mental Model) Think of OIDC like this: GitHub → Identity Provider Azure → Trust Authority Workflow → Temporary Identity OIDC Implementation (From the Repo) Workflow Configuration permissions: id-token: write contents: read env: ARM_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }} ARM_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }} ARM_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }} ARM_USE_OIDC: true Azure Login - name: Azure Login (OIDC) uses: azure/login@v2 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} Backend (Terraform State with OIDC) terraform init \ -backend-config="use_oidc=true" Even your state storage is secretless Azure Setup for OIDC Create App Registration No client secret required Configure Federated Credential Example: Issuer: https://token.actions.githubusercontent.com Subject: repo:<org>/<repo>:ref:refs/heads/master You can restrict by: Branch Environment Repository Assign RBAC: Grant roles like: Contributor Or scoped resource-level access CI/CD Workflow Design Both SPN and OIDC pipelines follow a 2-stage pattern: Plan Stage terraform fmt terraform validate terraform plan Upload plan artifact Apply Stage Triggered only on main Downloads plan Runs apply -auto-approve Protected via environment approvals This ensures safe, auditable deployments OIDC vs SPN — Real Comparison Feature SPN OIDC Secrets Stored in GitHub None Token lifetime Long-lived Short-lived Rotation Manual Not required Security Medium High Setup Simple Slightly complex Recommended No Yes Common Pitfalls (Real-World Lessons) Missing id-token permission Without this, OIDC fails silently. Federated credential mismatch Wrong branch Incorrect repo name Case sensitivity issues Azure rejects the token completely. RBAC delay Role assignments can take time → causes confusing failures. Backend misconfiguration Forgetting use_oidc=true breaks Terraform state auth. Debugging Tips Enable debug logs in GitHub Actions Check Sign-in logs in Microsoft Entra ID Validate federated credential subject format Always isolate: Identity issue vs Permission issue Migration Strategy (SPN → OIDC) A safe transition looks like this: Keep SPN as fallback Add OIDC alongside Test in DEV environment Remove client secret Revoke old credentials No downtime, no risk. Where This Fits in Modern Azure Architecture This pattern integrates naturally with: Azure Container Apps AI/ML workloads (AI Foundry, Search) Multi-environment deployments Zero-trust enterprise architectures Authentication becomes identity-driven, not secret-driven When NOT to Use OIDC Legacy CI/CD systems without OIDC support Organisations with strict identity federation constraints Cross-tenant scenarios with limited trust setup Note: These cases are becoming increasingly rare in modern cloud setups. Security Perspective Threat SPN Risk OIDC Risk Secret leak High None Credential reuse High Low Token replay Possible Limited Repo compromise Full access Scoped Final Takeaway This repository demonstrates a key shift in modern DevOps: Secrets were a workaround for identity. OIDC replaces that workaround with trust. By combining: GitHub Actions OIDC federation Azure RBAC You get: Secure pipelines Scalable deployments Zero secret management In enterprise environments, moving to OIDC can eliminate secret rotation pipelines entirely, reducing operational overhead and significantly lowering breach risk. Reference Implementation GitHub Repository: WorkFlowBasedDeployment Closing Thought OIDC doesn’t just improve authentication, it fundamentally changes how trust is established in cloud systems. In a world moving toward zero-trust architectures, identity is the new perimeter and OIDC is how you enforce it.
Clean up idle and always-failing Azure Logic App Consumption
If you’ve inherited an Azure subscription that’s been collecting Logic Apps Consumption workflows for a couple of years, you already know the shape of the problem: dozens of TestLA, webhook-test-2, poc-for-jira-FINAL workflows in the portal, half of them still Enabled, half of them quietly failing every five minutes against a connection that was rotated last quarter. They’re cheap, but they’re not free — polling triggers keep firing, alert rules keep paging, abandoned Microsoft.Web/connections keep pinning permissions, and the portal’s workflow list keeps getting harder to read. Source + full docs: GitHub - dengyanbo/LA-CleanUp What it gives you Two color-coded tables — Idle (no runs in the last -IdleDays days; never-run workflows land here too) and AlwaysFailing (ran in the window, but not a single Succeeded ). An optional, timestamped CSV ( LogicAppCleanup-Candidates-<yyyyMMdd-HHmmss>.csv ) with a stable column set, easy to drop in a Teams channel or PR for owner review before you delete anything. A per-item y/N/q deletion loop — y deletes, N /Enter skips, q quits the loop without touching anything else. A final summary with scanned / idle / always-failing / deleted / skipped / failed counts. Server-side OData $filter on run history so the scan is fast even on a subscription with thousands of workflow runs in the window. Lazy State lookup (Enabled/Disabled) — only fetched for actual candidates, not for every healthy workflow. What it is not: it does not touch Logic Apps Standard ( Microsoft.Web/sites with kind=workflowapp ) — those store run history in storage tables and need a completely different tool (see LogicAppAdvancedTool). It also does not GC Microsoft.Web/connections , and it does not iterate subscriptions — one invocation, one subscription, deliberately. Quick start Prerequisites PowerShell 5.1+ (Windows PowerShell or PowerShell 7 — both fine). Azure CLI on PATH: https://aka.ms/azcli An interactive az login against the subscription that owns the Logic Apps. Logic App Contributor on the relevant RGs (or plain Contributor) is enough — you need list + delete on Microsoft.Logic/workflows , plus the ARM token your az login already grants. Get the script git clone https://github.com/dengyanbo/LA-CleanUp.git cd LA-CleanUp One-liner — defaults (90-day idle, 90-day failure window, current sub) .\Invoke-LogicAppCleanup.ps1 A typical run looks like this: [INFO] Active subscription: Contoso-Integration (1111-2222-...) [INFO] Signed in as : alice@contoso.com [INFO] Idle cutoff : runs older than 2026-02-20T03:08:00Z (>90 days) [INFO] Failure window : checking runs since 2026-02-20T03:08:00Z (last 90 days) [INFO] Listing Logic App (Consumption) workflows... [ OK ] Found 13 workflow(s). [ 1/13] order-processor (rg-integration) [ 2/13] webhook-test (MyTest) ... [ OK ] Scan complete. Idle: 9, AlwaysFailing: 1, Errors: 0 === Idle Logic Apps (no runs in last 90 days) === Name ResourceGroup Location State LastStatus LastRunTime ---- ------------- -------- ----- ---------- ----------- webhook-test MyTest australiaeast Enabled Never poc-for-jira rg-integration eastus Enabled Succeeded 2025-09-04T... ... === Always-Failing Logic Apps (no successful run in last 90 days) === Name ResourceGroup Location State LastStatus LastRunTime ---- ------------- -------- ----- ---------- ----------- nightly-export rg-integration eastus Enabled Failed 2026-05-20T... Export the 10 candidate(s) to CSV? (y/N): y [ OK ] CSV written: ...\LogicAppCleanup-Candidates-20260521-110800.csv Starting per-item deletion review. Answer y to delete, N (or Enter) to skip, q to quit. (1/10) Delete [Idle] webhook-test in MyTest ? (y/N/q): y [INFO] Deleting webhook-test ... [ OK ] Deleted: webhook-test (2/10) Delete [Idle] poc-for-jira in rg-integration ? (y/N/q): N Skipped. ... === Summary === Scanned : 13 Idle : 9 Always-failing : 1 Scan errors : 0 Deleted : 4 Skipped : 6 Delete failures : 0 That’s the whole workflow. The commands you’ll actually use 1. Scope to one resource group with a tighter idle threshold .\Invoke-LogicAppCleanup.ps1 -IdleDays 60 -ResourceGroup rg-integration 2. Only review always-failing apps (skip the idle pile) .\Invoke-LogicAppCleanup.ps1 -SkipIdle 3. Only review idle apps (skip always-failing) .\Invoke-LogicAppCleanup.ps1 -SkipAlwaysFailing 4. Incident-driven cleanup — tight window, focused RG .\Invoke-LogicAppCleanup.ps1 -IdleDays 30 -FailureWindowDays 7 ` -ResourceGroup rg-integration-prod This answers: “Within prod-integration, which workflows haven’t run in a month, and which have been failing all week?” 5. Dry-run (there is no -WhatIf ) The per-item y/N/q prompt is the safety model. To dry-run, just answer N to every prompt — or q at the first one. The CSV is still written before the deletion loop starts, so you walk away with the report and zero deletions. Parameters — cheat sheet Parameter Default Meaning -IdleDays 90 No runs in this many days ⇒ flagged Idle. Never-run workflows land here too. -FailureWindowDays 90 Ran in this window but no Succeeded ⇒ flagged AlwaysFailing. -ResourceGroup (none) Restrict the scan to a single RG. -SkipIdle switch Skip the Idle bucket entirely. -SkipAlwaysFailing switch Skip the AlwaysFailing bucket entirely. Why Invoke-RestMethod instead of az rest This is the gotcha I want every other Logic Apps scripter to know about, because it eats hours. The Logic Apps Management REST API is queried with OData — $top , $filter , the usual: GET /subscriptions/.../workflows/{wf}/runs ?api-version=2016-06-01 &$top=1 &$filter=startTime ge 2026-02-20T03:08:00Z and status eq 'Succeeded' On Windows PowerShell, az is a .cmd shim. The URL you pass to az rest --uri "..." is re-parsed by cmd.exe , and the & characters separating OData query parameters get interpreted as command separators. Symptoms range from '$filter' is not recognized as an internal or external command to silent wrong-page returns where the filter is just dropped and you get the most recent N runs instead. Quoting heroics — single quotes, double quotes, triple-escaped ^& — don’t fully solve it across PS 5.1 and PS 7. The fix is to skip az rest entirely. The script grabs an ARM token once with az account get-access-token , caches it on a script-scoped variable, refreshes it proactively at the 45-minute mark (ARM tokens last ~60), and calls Invoke-RestMethod directly: $tok = az account get-access-token --resource 'https://management.azure.com/' -o json | ConvertFrom-Json Invoke-RestMethod -Method Get -Uri $url ` -Headers @{ Authorization = "Bearer $($tok.accessToken)" } That bypasses cmd.exe entirely. Bonus: caching the token makes the script noticeably faster on subscriptions with many candidates, since we’re no longer shelling out to az for every REST call. Why $top=1 matters more than you’d think The script never pages run history. For each surviving workflow it asks two existence questions: ?api-version=2016-06-01&$top=1&$filter=startTime ge <cutoff> ?api-version=2016-06-01&$top=1&$filter=startTime ge <cutoff> and status eq 'Succeeded' If the first one returns zero rows ⇒ the workflow is Idle. Otherwise, if the second one returns zero rows ⇒ AlwaysFailing. Both queries are O(1) server-side because startTime is indexed and the response is capped at one row. Even on a chatty workflow with tens of thousands of runs in the window, the answer comes back in tens of milliseconds. This is also why the script can afford to be sequential per workflow — there’s no need for parallelism when each existence check is essentially free. Why “AlwaysFailing” is defined the way it is The bucket is “ran in the window, but not a single Succeeded run in the window” — not “all runs are Failed ”. That distinction matters: Workflows whose runs are Running , Waiting , or Cancelled but never Succeeded get classified as AlwaysFailing. That’s usually what you want — a workflow that has been “Waiting” for 30 days is just as broken as one that’s been failing for 30 days. Long-running workflows that legitimately haven’t completed yet look the same to the classifier. If you operate that kind of workflow, widen -FailureWindowDays so a slow but eventually-Succeeded run shows up in the window. The reported LastStatus column in the table is the status of the most recent run, so you can usually eyeball the difference between “failing” and “still running.” A field-tested rollout If you’re running this on a subscription you don’t fully own, this multi-pass rollout has worked well: Run with -SkipAlwaysFailing first. Idle workflows are the safe pile — if they haven’t done anything in 90+ days, deleting them rarely surprises anyone. Export the CSV. Don’t delete yet — answer q at the first delete prompt. Drop the CSV in a Teams channel or PR. Give owners a few days to object. Re-run and actually delete the ones nobody claimed. Then run with -SkipIdle for the AlwaysFailing bucket. These often have an owner who just hasn’t noticed the breakage — treat the first pass as a bug-bash list, not a delete list. Things to know before you run it Consumption only. Logic Apps Standard is out of scope — different model, different APIs, run history in storage tables. Use LogicAppAdvancedTool for those. No -Force , no -WhatIf . The per-item y/N/q prompt is the entire safety model. That’s deliberate — cleanup tools that take a -Force get used with -Force . One subscription per invocation. The script operates on whatever az account show returns. Use az account set --subscription <id> to switch deliberately. Microsoft.Web/connections are not deleted. API connections are typically shared; the script intentionally leaves them alone. GC them with a separate pass. Run history disappears with the workflow. Once you delete the Logic App, Azure removes its run history too. Export the CSV first if you want any record. Enabled vs. Disabled is reported, not enforced. A Disabled workflow can still be Idle. The script shows the state in the table so you can decide. Where to go next The GitHub repo has the full reference — parameter table, CSV schema, the “how it works” deep dive on lazy State fetch, bearer-token caching, server-side $filter , considerations and limitations, and the recommended rollout: 👉 https://github.com/dengyanbo/LA-CleanUp Issues and PRs welcome. A few directions on the roadmap: an optional disable-instead-of-delete mode for the first pass ( PATCH ...?api-version=2019-05-01 with properties.state = 'Disabled' ), a cross-subscription mode that iterates az account list with a confirmation per sub, and a companion API-connection GC script that uses Resource Graph to join connections against workflow definitions in one query.Run Javascript code on Agent Loop
We have recently introduced support for Code interpreters inside of Azure Logic Apps Agent Loop, extending the support we had for Python. When partnered with a LLM, this allow builders to express their goals or intents via natural language and obtain executable results. These capabilities become powerful in the areas of data analysis, visualizations, validations and transformations. Our first language supported for code interpreter is JavaScript, with other languages following later. Historically, customers have had concerns about an LLM performing data analysis, calculations and transformations due to context window exhaustion which can lead to hallucinations. Code interpreters help in this regard as they can perform this analysis without filling up context windows and providing more reliable results. You can see the code interpreter with JavaScript in action in this video from Kent Weare. After watching the video, you can deep dive in the details. How it works When Agent Loop evaluates code generated by an AI agent (for example, through a code interpreter), we run it inside a V8 isolate using the isolated‑vm library. V8 is the JavaScript engine that powers Node.js and Chrome—it’s what actually executes JavaScript code. An isolate is a lightweight, independent environment within V8, with its own memory and execution context. Running code inside an isolate gives us strong separation from the host runtime. Each execution has its own memory (“heap”) and cannot directly access the host’s memory, file system, or network. This helps ensure that agent-generated code stays contained and doesn’t interfere with the rest of the system. This approach is not intended to be a full security sandbox, and we don’t treat it as safe for fully untrusted code. However, it provides meaningful defense-in-depth: Memory usage is limited per isolate, preventing a single execution from consuming all available resources Execution can be bounded with timeouts, allowing us to terminate long-running or infinite loops Failures are isolated, so crashes in agent-generated code won’t bring down the runtime process In practice, this is about reducing blast radius. By isolating execution and enforcing limits, we make sure that code—regardless of whether it’s generated by a user or an AI agent—cannot disrupt the engine that runs it. Use case: Expense Validations To help illustrate, this capability, let’s take an accounts payable example built in Logic Apps Standard. Zava uses a 3 rd party expense application to capture employee expenses. The 3rd party expense application will export transactions in CSV format. Zava has some very specific business validations that need to execute before the expenses can be processed by the ERP. To solve this problem, we will build an agentic business process in Logic Apps that includes our new JavaScript code interpreter. Our code interpreter will be able to ingest and parse our CSV file and then apply our business validations for us. The outcome is a report that identifies both valid and invalid transactions. Prior to uploading to the ERP (Dataverse), we will route our request to a human in the loop process for their oversight. This allows for additional control as unwinding in an ERP is always a tedious task. Below, is a picture of our solution. Within it we can see both deterministic steps before and after our Agent action. Within our agent action, we have tools that will help our agent address our company objectives. These tools include calling a batch API to upload valid expense records to Dataverse. Another tool that will take care of uploading invalid records to a different table, our human in the loop action to seek approval from our human stakeholder and a tool that will help us obtain business knowledge from SharePoint. You might be asking, ok where does the code interpreter come in? Within our Agent action, we will discover a toggle that allows you to enable it. The code interpreter gets invoked based upon instruction in the model. Here is a subset of the prompt from this workflow that describes how to invoke the code interpreter. For example: ### Step 2 -- Parse and Validate The expense CSV data is available from the Get_file_content action. Use code interpreter to parse ALL rows from the CSV. For each row, normalize: Category: title case - Amount: decimal number - SubmittedDate: ISO 8601 format (e.g. "2026-01-05T00:00:00Z") - ReceiptAttached: convert "Yes"/"No" to true/false Then apply the business rules from Step 1 to classify every record as VALID or INVALID. You won’t see the code interpreter modelled as a tool within our agent action, but we see the execution outcome within our run history. In the following screenshot we can see this illustrated. Within our agent action, we can see that we are on our 4 th turn and we have executed the code interpreter action. In the code window, we can see the code that was generated for our us. This is the result of the LLM working together with the code interpreter to generate and execute this code. Note: In this scenario, we are dynamically generating this code at runtime. This allows for ultimate flexibility if we have different source inputs and we are relying upon the LLM and code interpreter to adapt to these fluid inputs. If we were interested in a more deterministic approach we can also pass pre-written code into this action where it can also execute. This will result in less flexibility, but more deterministic behavior. Running JavaScript code in Logic Apps Consumption Agent Loop Logic Apps Consumption has a slightly different architecture to Logic Apps Standard. In Logic Apps Standard, we offer dedicated compute and storage for customers which provides workload isolation across customers. When it comes to Logic Apps Consumption, we provide a multi-tenant offering allowing customers to take advantage of a lower price point due to shared resource utilization. In order to allow customer isolation, customers need to have an integration account attached to their consumption workflow. This will allow the code interpreter to run in isolated compute thus avoiding any potential disruptions to other customers. You can provision an Integration Account by searching for Integration Accounts at the top of the Azure portal. You can select any of the SKUs available, including the Free SKU for non-production/non-SLA scenarios. With an Integration Account created, we can associate this Integration Account with our consumption logic app by clicking on Settings – Integration Account.Bulk-configure diagnostic settings on Azure Logic Apps Consumptions
Bulk-configure diagnostic settings on Azure Logic Apps — without clicking through the Portal LA-BulkDiag is a small, single-file PowerShell script that does the whole job in one guided run. It enumerates every Consumption Logic App in a resource group, shows you which ones already have settings, lets you pick a scope (every bare LA / every LA / a hand-picked subset), and creates the diagnostic setting on each. It auto-renames on collision so re-running is safe, and it ships with 129 Pester tests covering helpers, parameter binding, and end-to-end flows with a mocked az . Source + full docs: GitHub - dengyanbo/LA-BulkDiag: Bulk diagnostics configuration for Azure Logic Apps What it gives you A numbered, color-coded table of every Consumption LA in the RG and its current diagnostic-setting state (bare / has N / list failed). A single scope prompt — bare / all / pick / cancel — so the common cases are one keystroke. Selection grammar for the picker / -Selection : 1,3-5,8 , bare , all , none . Auto-rename on name collision ( la-diag → la-diag-1 → …) so the upsert behavior of Azure’s API never silently replaces an existing setting. Preflight verification of the destination workspace / storage account via az resource show before touching any Logic App. -WhatIf for a dry-run preview. Non-zero exit code if any LA failed, so it composes cleanly in CI. What it is not: it does not target Standard Logic Apps ( Microsoft.Web/sites with kind=workflowapp ) — those use a different API. It also doesn’t target Event Hub destinations. For everything else, see the “Scope and what this is NOT” section in the GitHub README. Quick start Prerequisites PowerShell 5.1+ (Windows PowerShell or PowerShell 7 — both fine). Azure CLI on PATH: https://aka.ms/installazurecliwindows An interactive az login against the subscription that owns the Logic Apps. Built-in Monitoring Contributor on the RG is enough. Get the script git clone https://github.com/dengyanbo/LA-BulkDiag.git cd LA-BulkDiag One-liner — fully interactive You don’t need to know the destination IDs up front; the script will ask: .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -SettingName la-diag You’ll see something like: Sub: my-sub (00000000-...) User: alice@contoso.com Destination not provided on the command line. Configure interactively: (paste the full ARM resource ID; leave blank to skip a destination) Log Analytics workspace resource ID: /subscriptions/.../workspaces/my-ws Storage account resource ID: Inspecting 3 Logic App(s) ... Logic Apps in 'my-rg': [ 1] order-processor bare (no settings) [ 2] notification-sender has 1: corp-governance [ 3] data-loader bare (no settings) How do you want to apply 'la-diag'? 1) bare -- apply to every BARE LA (recommended) 2) all -- apply to EVERY LA (may fail Azure-side on non-bare ones) 3) pick -- go into the selective picker 0) cancel Choice [1]: 1 Applying to every BARE LA. ==> order-processor Creating ... OK (Created). ==> data-loader Creating ... OK (Created). ================ Summary ================ LogicApp FinalName Status -------- --------- ------ order-processor la-diag Created data-loader la-diag Created Selected: 2 Succeeded: 2 Renamed: 0 Failed: 0 Not selected: 1 That’s the whole workflow. The commands you’ll actually use Grab the destination IDs once: $wsId = az monitor log-analytics workspace show -g ws-rg -n my-ws --query id -o tsv $saId = az storage account show -g sa-rg -n mysa --query id -o tsv 1. Apply to every bare LA — fully automated .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -WorkspaceId $wsId -SettingName la-diag -Selection bare -Selection bare skips both the scope prompt and the y/N confirm — perfect for CI. 2. Send to both a workspace and a storage account .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -WorkspaceId $wsId -StorageAccountId $saId ` -SettingName la-diag -Selection all 3. Metrics only, storage-only .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -StorageAccountId $saId -SettingName la-metrics ` -Preset metrics-only -Selection all Available presets: all (default) / logs-only / metrics-only / workflowruntime . 4. Specific Logic Apps by index — non-interactive After running once and seeing the numbered table, you can target them directly: .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName la-diag -Selection '1,3-5,8' 5. Dry-run before committing .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName la-diag -Selection all -WhatIf 6. Just inspect — list LAs + existing settings, change nothing .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName whatever -Selection none 7. Run the tests .\unit_test\Run-Tests.ps1 Auto-installs Pester 5 to CurrentUser if missing. Expected: Passed=129 Failed=0 . Selection grammar — cheat sheet Input Meaning 1 , 3 , 7 single index (1-based, matches the table) 1,3,5 multiple indices 1-5 inclusive range 1,3-5,8 mixed bare all LAs with no existing settings (recommended) all every LA (may fail on already-configured ones) none (or empty / q / cancel ) exit without changes Why the auto-rename matters Azure’s diagnostic-settings API is PUT — calling create --name la-diag on a Logic App that already has a setting named la-diag silently replaces the existing one. That’s a footgun if a colleague already set something up by hand. LA-BulkDiag refuses to overwrite. Instead, when -SettingName is already in use on a given LA, it auto-appends -1 , -2 , … until it finds a free name, and reports the actual name in the summary’s FinalName column. If you genuinely want to replace an existing setting, delete it first: az monitor diagnostic-settings delete -n <existing-name> --resource <la-id> Where to go next The GitHub repo has the full reference — parameter table, exit codes, status-value glossary, troubleshooting matrix (RBAC, MFA, throttling, category/sink conflicts), known limitations, and the full test inventory: 👉 https://github.com/dengyanbo/LA-BulkDiagHow to Visualize Your Azure AI Workloads Usage for Observability
This article assumes you already have an Azure Foundry project and resource deployed in Microsoft Foundry. The options referenced here are documented in detail in the linked articles; this post serves as a consolidated step by step guide bringing them all together and explaining where each option is most useful. A Summary: Need Best Option Quick day-over-day visual, minimal setup Grafana Dashboard (Option 3) Custom growth % calculations App Insights + KQL in Log Analytics (Option 4) Shareable, interactive report Azure Workbooks (Option 5) Per-user/per-agent granularity APIM + App Insights (Option 6) Quick one-off chart, export to Excel Microsoft Foundry Monitor tab or App Insights Metrics Explorer (Option 1 and 2) Option 1. Within the Microsoft Foundry Portal (Quickest, No Setup) If you have models deployed in Microsoft Foundry and would like to monitor its usage, go to the New Foundry Portal → Build → Models → Monitor tab. View metrics such as: Estimated cost Total token usage Input vs. output tokens Number of requests This is the simplest way to monitor both model and agent usage. For PAYG plans: You can also view your total allocated quota (and figure out which Tier you are on) using the Quota Management Screen (New Foundry Portal → Operate → Quota tab). This screen shows how much your total allocated quota is, per model in a given subscription + region + Deployment Type (Global, Data Zones or Regional). For eg., in the image below, for gpt-4o, I am allocated 7M total TPM in my subscription. I am only using 150K TPM of the allocated 7M TPM amount. Which means, my requests will get throttled if I exceed the 150K TPM limit. To avoid throttling, I would need to increase my shared allocation limit. NOTE: you are charged for usage, so if you allow more capacity, you use more, so you pay more. Option 2: Azure Monitor Metrics Explorer This is already built into the Azure Portal and gives you time-series charts out of the box. Go to Azure Portal → your Azure OpenAI / Foundry resource → Monitoring → Metrics Select a metric like AzureOpenAIRequests or TokenTransaction Set Aggregation to Sum (total) or Max and Time granularity to 1 day Split by ModelDeploymentName to see per-model trends Adjust the time range (e.g., last 30 days) — you'll see day-over-day bars/lines Tip: You can pin these charts to an Azure Dashboard for a persistent view, or click Share → Download to Excel to get the raw data for your own analysis. Option 3: Azure Managed Grafana (Best Pre-Built Dashboard) This is the best option for a polished, real-time, day-over-day dashboard with no custom code. There's a pre-built AI Foundry dashboard ready to import. [grafana.com], [Create a M...ed Grafana] How to set it up: Create an Azure Managed Grafana workspace (if you don't have one) In Grafana, go to Dashboards → New → Import → enter dashboard ID 24039 (for Foundry) Select your Azure Monitor data source and point it to your Foundry resource Tip: You can also import this directly from the Azure Portal: Monitor → Dashboards with Grafana → AI Foundry. That's it — the dashboard gives you (per model deployment): Token trends over time (inference, prompt, completion — day over day) Request trends over time (AzureOpenAIRequests as a time series) Latency trends (bonus) NOTE: Default time range is 7 days — adjust to 30/60/90 days for growth trends Option 4: Application Insights + KQL Queries (Most Flexible, Custom Reports) If you want fully custom day-over-day growth calculations (e.g., % change day-to-day), this is the way. [azurefeeds.com] Setup: Ensure your Foundry project is connected to an Application Insights resource (Foundry → Settings → Connected Resources). Open up App Insights resource → Logs → New Query or choose a sample query. In the images below, we simply ran 'requests' and set the time range to 24 hours. There is also a Kusto Query Language (KQL) mode or Simple mode on the right-hand side: Simple mode will let you run out of the box samples. KQL mode will open up a query window for you to enter custom queries. Below are the results in grid view. Same view but showing a chart: Export options: Another way to get the above graphs are via Log Analytics. Simply enable Diagnostic Settings on your Azure OpenAI resource → send to a Log Analytics workspace. Open Log Analytics → Logs and try our your sample queries. Sample KQL for day-over-day token usage (adjust to your needs): AzureMetrics | where MetricName in ("TokenTransaction", "ProcessedPromptTokens", "GeneratedTokens") | where TimeGenerated > ago(30d) | summarize DailyTokens = sum(Total) by bin(TimeGenerated, 1d), MetricName | order by TimeGenerated asc | render timechart Result: Sample KQL for day-over-day growth % (adjust to your needs): AzureMetrics | where MetricName == "TokenTransaction" | where TimeGenerated > ago(30d) | summarize DailyTokens = sum(Total) by Day = bin(TimeGenerated, 1d) | sort by Day asc | extend PrevDay = prev(DailyTokens) | extend GrowthPct = round((DailyTokens - PrevDay) / PrevDay * 100, 2) | project Day, DailyTokens, GrowthPct Option 5: Azure Monitor Workbooks (Custom Dashboards, Shareable) Workbooks let you build interactive, parameterized dashboards that combine metrics and KQL logs. What's more, you can select resources from multiple subscriptions and visualize them all in one place using Workbooks! Go to Azure Portal → Monitor → Workbooks → New Add a Metrics query panel → select your Log Analytics or App Insights or Foundry resource -> Enter the same query you used in Option 4. Do a test run and view the graphs (this can be viewed as charts or a list (grid view)): 4. Save and share with your team. Option 6: APIM + Application Insights (Granular Per-Caller/Per-Agent Tracking) 1. If your app routes requests through Azure API Management, you can use the azure-openai-emit-token-metric policy to send per-request token metrics to Application Insights with custom dimensions (User ID, Subscription ID, Agent, etc.). [Azure API...osoft Docs] This is ideal for scenarios like: "Which agent consumed the most tokens last week?" "What's the token usage per API consumer/team?" NOTE: Microsoft Foundry resources do not track usage by users. So, fronting your Foundry resource with an APIM could be a way to track users provided you pass the username/id in the request context. How you implement this is upto your app design. Ref: AI-Gateway/labs/token-metrics-emitting/token-metrics-emitting.ipynb at main · Azure-Samples/AI-Gateway · GitHub Bonus: Check out all other APIM + AI related policies here: AI-Gateway/labs/semantic-caching at main · Azure-Samples/AI-Gateway AI-Gateway/labs/token-rate-limiting at main · Azure-Samples/AI-Gateway AI-Gateway/labs/token-metrics-emitting/token-metrics-emitting.ipynb at main · Azure-Samples/AI-Gateway · GitHubMicrosoft BizTalk Server Product Lifecycle Update
For more than 25 years, Microsoft BizTalk Server has supported mission-critical integration workloads for organizations around the world. From business process automation and B2B messaging to connectivity across industries such as financial services, healthcare, manufacturing, and government, BizTalk Server has played a foundational role in enterprise integration strategies. To help customers plan confidently for the future, Microsoft is sharing an update to the BizTalk Server product lifecycle and long-term support timelines. BizTalk Server 2020 will be the final version of BizTalk Server. Guidance to support long-term planning for mission-critical workloads This announcement does not change existing support commitments. Customers can continue to rely on BizTalk Server for many years ahead, with a clear and predictable runway to plan modernization at a pace that aligns with their business and regulatory needs. Lifecycle Phase End Date What’s Included Mainstream Support April 11, 2028 Security + non-security updates and Customer Service & Support (CSS) support Extended Support April 9, 2030 CSS support, Security updates, and paid support for fixes (*) End of Support April 10, 2030 No further updates or support (*) Paid Extended Support will be available for BizTalk Server 2020 between April 2028 and April 2030 for customers requiring hotfixes for non-security updates. CSS will continue providing their typical support. BizTalk Server 2016 is already out of mainstream support, and we recommend those customers evaluate a direct modernization path to Azure Logic Apps. Continued Commitment to Enterprise Integration Microsoft remains fully committed to supporting mission-critical integration, including hybrid connectivity, future-ready orchestration, and B2B/EDI modernization. Azure Logic Apps, part of Azure Integration Services — which includes API Management, Service Bus, and Event Grid — delivers the comprehensive integration platform for the next decade of enterprise connectivity. Host Integration Server: Continued Support for Mainframe Workloads Host Integration Server (HIS) has long provided essential connectivity for organizations with mainframe and midrange systems. To ensure continued support for those workloads, Host Integration Server 2028 will ship as a standalone product with its own lifecycle, decoupled from BizTalk Server. This provides customers with more flexibility and a longer planning horizon. Recognizing Mainframe modernization customers might be looking to integrate with their mainframes from Azure, Microsoft provides Logic Apps connectors for mainframe and midrange systems, and we are keen on adding more connectors in this space. Let us know about your HIS plans, and if you require specific features for Mainframe and midranges integration from Logic Apps at: https://aka.ms/lamainframe Azure Logic Apps: The Successor to BizTalk Server Azure Logic Apps, part of Azure Integration Services, is the modern integration platform that carries forward what customers value in BizTalk while unlocking new innovation, scale, and intelligence. With 1,400+ out-of-box connectors supporting enterprise, SaaS, legacy, and mainframe systems, organizations can reuse existing BizTalk maps, schemas, rules, and custom code to accelerate modernization while preserving prior investments including B2B/EDI and healthcare transactions. Logic Apps delivers elastic scalability, enterprise-grade security and compliance, and built-in cost efficiency without the overhead of managing infrastructure. Modern DevOps tooling, Visual Studio Code support, and infrastructure-as-code (ARM/Bicep) ensure consistent, governed deployments with end-to-end observability using Azure Monitor and OpenTelemetry. Modernizing Logic Apps also unlocks agentic business processes, enabling AI-driven routing, predictive insights, and context-aware automation without redesigning existing integrations. Logic Apps adapts to business and regulatory needs, running fully managed in Azure, hybrid via Arc-enabled Kubernetes, or evaluated for air-gapped environments. Throughout this lifecycle transition, customers can continue to rely on the BizTalk investments they have made while moving toward a platform ready for the next decade of integration and AI-driven business. Charting Your Modernization Path Microsoft remains fully committed to supporting customers through this transition. We recognize that BizTalk systems support highly customized and mission-critical business operations. Modernization requires time, planning, and precision. We hope to provide: Proven guidance and recommended design patterns A growing ecosystem of tooling supporting artifact reuse Unified Support engagements for deep migration assistance A strong partner ecosystem specializing in BizTalk modernization Potential incentive programs to help facilitate migration for eligible customers (details forthcoming) Customers can take a phased approach — starting with new workloads while incrementally modernizing existing BizTalk deployments. We’re Here to Help Migration resources are available today: Overview: https://aka.ms/btmig Best practices: https://aka.ms/BizTalkServerMigrationResources Video series: https://aka.ms/btmigvideo Feature request survey: https://aka.ms/logicappsneeds Reactor session: Modernizing BizTalk: Accelerate Migration with Logic Apps - YouTube Migration tool: Bringing all your Integration workloads to Logic Apps Standard | Microsoft Community Hub We encourage customers to engage their Microsoft accounts team early to assess readiness, identify modernization opportunities, and explore assistance programs. Your Modernization Journey Starts Now BizTalk Server has played a foundational role in enterprise integration success for more than two decades. As you plan ahead, Microsoft is here to partner with you every step of the way, ensuring operational continuity today while unlocking innovation tomorrow. To begin your transition, please contact your Microsoft account team or visit our migration hub. Thank you for your continued trust in Microsoft and BizTalk Server. We look forward to partnering closely with you as you plan the future of your integration platforms. Frequently Asked Questions Do I need to migrate now? No. BizTalk Server 2020 is fully supported through April 11, 2028, with paid Extended Support available through April 9, 2030, for non-security hotfixes. CSS will continue providing their typical support. You have a long and predictable runway to plan your transition. Will there be a new BizTalk Server version? No. BizTalk Server 2020 is the final version of the product. What happens after April 9, 2030? BizTalk Server will reach End of Support, and security updates or technical assistance will no longer be provided. Workloads will continue running but without Microsoft servicing. Is paid support available past 2028? Yes. Paid extended support will be available through April 2030 for BizTalk Server 2020 customers looking for non-security hotfixes. CSS will continue to provide the typical support. What about BizTalk Server 2016 or earlier versions? Those versions are already out of mainstream support. We strongly encourage moving directly to Logic Apps rather than upgrading to BizTalk Server 2020. Will Host Integration Server continue? Yes. Host Integration Server (HIS) 2028 will be released as a standalone product with its own lifecycle and support commitments. Can I reuse BizTalk Server artifacts in Logic Apps? Yes. Most of BizTalk maps, schemas, rules, assemblies, and custom code can be reused with minimal effort using Microsoft and partner migration tooling. We welcome feature requests here: https://aka.ms/logicappsneeds Does modernization require moving fully to the cloud? No. Logic Apps supports hybrid deployments for scenarios requiring local processing or regulatory compliance, and fully disconnected environments are under evaluation. More information of the Hybrid deployment model here: https://aka.ms/lahybrid. Does modernization unlock AI capabilities? Yes. Logic Apps enables AI-driven automations through Agent Loop, improving routing, decisioning, and operational intelligence. Where do I get planning support? Your Microsoft account team can assist with assessment and planning. Migration resources are also linked in this announcement to help you get started. Microsoft Corporation
Azure API Center portal is now generally available
What Is the API Center Portal? The API Center portal is a hosted, provisioned and managed by Azure, where developers across your organization can discover, explore, and consume APIs. The API Center portal provides a multi-gateway, organization-wide view of every API and AI asset (e.g. plugins, MCP servers, skills etc) Key Capabilities Search and filter your full API inventory. Developers can find APIs and AI assets by name or use AI-assisted semantic search (available on the Standard plan) to query by intent. Natural language queries like “Enable cloud migration” surfaces relevant Azure cloud migrate skill and associated MCP server even when exact words don’t appear in AI asset name and description Rich API details at a glance. Users can view endpoints, methods, parameters, and response formats; download API definitions; or open them directly in Visual Studio Code — all from within the portal. Discovering and testing MCP servers: The API Center portal supports discovery of MCP (Model Context Protocol) servers, making it a single destination for both traditional APIs and the AI-native integrations powering modern copilots and agents. Developers and other stakeholders can browse and filter MCP servers in the inventory, view details such as the URL endpoint and tool schemas, and install MCP servers directly into their Visual Studio Code environment — all from within the portal. A built-in test console lets users test MCP server tools and view responses without leaving the portal: simply navigate to the Documentation tab of an MCP server details page, select a tool, and click Run tool to get started. Discovering Skills and assessment results: The API Center portal also serves as a central hub for discovering skills registered in your organization's API inventory. Developers and stakeholders can browse and filter skills alongside APIs and MCP servers and view detailed information about each skill directly in the portal. Skill assessment results are surfaced on the skill details page, giving teams immediate visibility into the quality and readiness of each skill — no additional tooling required. Together with API and MCP server discovery, skills support in the API Center portal reinforces its role as a unified catalog for all the building blocks of modern AI-powered applications. Flexible access control. The portal integrates with Microsoft Entra ID for authenticated access, or you can enable anonymous access for broader internal discoverability. Role-based access control makes it straightforward to grant access to specific users and groups. Customizable visibility rules. Admins can filter which APIs surface in the portal — by asset type (REST, GraphQL, MCP, Agent, Skill etc.), lifecycle stage, specification format, or custom metadata — so the right APIs and AI assets reach the right audiences. Setting It Up Getting started takes just a few steps in the Azure portal: Navigate to your API center and select API Center portal > Settings. Configure access — either Microsoft Entra ID authentication (recommended) or anonymous access. Hit Save + publish, and your portal is live at https://<service-name>.portal.<location>.azure-apicenter.ms. For teams with deeper customization needs, the portal can also be self-hosted and integrates with the Visual Studio Code extension for API Center. Learn more The Azure API Center portal is available today. Visit the setup documentation to configure your portal, and check out the overview of Azure API Center to learn more about managing your organization’s full API and AI asset inventory. To learn more click here
