New blog articles in Microsoft Community Hub

🏆 Agents League: Celebrating the Builders Who Made Agents Battle for Glory

Lee_Stott — Thu, 23 Jul 2026 19:00:00 GMT

The arena has closed, the scores are in, and the champions are crowned. Agents League, the esports-inspired hackathon at the heart of AI Skills Fest 2026, brought together tens of thousands of developers to build, ship, and compete with agentic AI. This is the celebration post: a spotlight on the winners across every category, the numbers behind the movement, and the engineering lessons worth carrying into your next build.

If you competed, watched a Reactor battle, or completed a skilling playlist, this recap is for you. You didn't just attend an event. You helped set a record.

Before we get to the winners, there is a useful playbook hiding in their submissions. Later in this post, the section “What the Winners Teach Us: Patterns Worth Stealing” breaks down the build patterns future attendees should pay attention to: multi-agent orchestration, meeting users where they already work, testing discipline, and accessibility-first design. If you are planning to enter next time, read the winners not just as inspiration, but as a practical checklist for what great agent projects have in common.

🥇 Best Overall: $15,000 Grand Prize

Afterlogin: The Hunt — https://github.com/jlynch160/afterlogin-the-hunt (Creative Apps track)

The top weighted score of the entire field. Afterlogin: The Hunt is described by its builders as "one engine, two faces": a cinematic Security Operations Centre (SOC) night on one side, and a coached training game on the other. The same underlying engine powers both an atmospheric narrative experience and a hands-on learning simulation.

Why it won: it fused genuinely creative design with a real-world use case (security operations training) and executed both at a high polish level. Built with GitHub Copilot for AI-assisted development, it's a masterclass in using one well-architected engine to serve two very different user experiences.

🏅 Category Champions

Best Creative App: StudyMate, "Study with Matey" — https://github.com/adetorojeremiahfadesayo/StudyMate

Tech: GitHub Copilot

StudyMate turns a student's own notes into a gamified, story-driven revision session, complete with XP and progression. Instead of generic flashcards, it grounds the experience in the learner's real material and wraps it in a narrative loop that keeps motivation high. It is a great example of pairing personalisation with game mechanics to solve a persistent problem: staying engaged while revising.

Best Reasoning Agent: DELPHAI — https://github.com/jlynch160/delphai

Tech: Microsoft Foundry

DELPHAI is an 11-agent reasoning council that checks the maths, explains the risk, and refines its own answer before responding. Rather than a single model producing a one-shot response, DELPHAI orchestrates a panel of specialised agents that debate, verify, and converge, a pattern that directly addresses the reliability gap in high-stakes reasoning. It's a textbook demonstration of multi-agent orchestration on Microsoft Foundry.

Best Enterprise Agent: Archon — https://github.com/upgradedev/archon_azure

Tech: Microsoft 365 Copilot

Archon is a 7-agent financial-intelligence pipeline for small and medium businesses, delivered right inside Microsoft Teams. It meets users where they already work, chaining specialised agents to turn raw financial data into actionable intelligence. Archon shows how enterprise-ready agents built for Microsoft 365 Copilot can deliver serious business value without forcing users to leave their daily workflow.

🌟 Special Awards

Award	Winner	What made it stand out
Best Use of IQ Tools	CivicGrant IQ — https://github.com/JonEricEubanks/CivicGrant-IQ	Stood out for making the IQ layers genuinely useful: Foundry IQ, Fabric IQ and Work IQ were combined into a traceable grant-analysis workflow with grounded citations, specialist agents, GraphRAG-style evidence handling, guardrails and evaluation coverage.
Accessibility	CLARO — https://github.com/jagaor/claro SchemeSaathi — https://github.com/red-coder-27/SchemeSaathi Solace — https://github.com/MaksymY11/solace-reasoning	These teams treated accessibility as core product architecture, not a feature add-on: CLARO combined deterministic public-benefit rules with grounded bilingual reasoning; SchemeSaathi made health-scheme discovery usable across Indian languages; Solace delivered cited, plain-language immigration-rights support with safety escalation for sensitive situations.
Hack for Good	Tell My Day — https://github.com/stork066/TellMyDay BRIEF — AI Bias & Research Intelligence Evaluation Framework — https://github.com/shiwakshir/brief-agent ARGUS — Agentic Risk & Governance Unified Screening — https://github.com/iarjunganesh/argus	Each winner used agents for tangible social value: Tell My Day turns picture symbols into grounded stories for non-verbal users; BRIEF audits assumptions and bias before research begins; ARGUS turns manual KYC and governance screening into cited, auditable risk assessment.
Top Student	Athenaeum — https://github.com/theCodeForgerHQ/msf-reasoning-agent Narrative Alchemist — https://github.com/10ANT/narrative-alchemist CurriculumCraft AI — https://github.com/gideonagbavor8/curriculumcraft-ai	These student-led projects stood out for ambition and execution: Athenaeum showed exceptional engineering discipline with a deep safety and test harness; Narrative Alchemist demonstrated a complete four-agent creative production pipeline; CurriculumCraft AI translated AI into practical instructional design for Ghanaian JHS teachers.

Across 8 categories, 14 winners shared a $55,000 prize pool. Congratulations to every one of them, and to the thousands of builders who submitted.

🧠 What the Winners Teach Us: Patterns Worth Stealing

Look across the champions and clear engineering patterns emerge. These are the takeaways AI engineers and developers should carry into their own projects.

1. Multi-agent orchestration beats the monolithic prompt

The two reasoning-heavy winners, DELPHAI (11 agents) and Archon (7 agents), both won by decomposing a hard problem into specialised, cooperating agents. A "council" or "pipeline" of narrow agents that verify each other outperforms a single model asked to do everything at once.

Here's the shape of that pattern, illustrated conceptually with the Microsoft Agent Framework style used with Microsoft Foundry. (This is an illustrative pattern, not the winners' actual code.)

# Illustrative multi-agent "reasoning council" pattern # Conceptual sketch, not the winning team's source code. async def reasoning_council(question: str) -> str: # 1. Specialised agents each own one responsibility solver = create_agent( role="Propose an answer with its reasoning" ) math_check = create_agent( role="Verify every calculation, flag errors" ) risk_agent = create_agent( role="Explain the risks and assumptions" ) # 2. Draft, then critique draft = await solver.run(question) math = await math_check.run(draft) risk = await risk_agent.run(draft) # 3. Refine using the critiques before answering the user refined = await solver.run( f"Question: {question}\n" f"Draft: {draft}\n" f"Math review: {math}\n" f"Risk review: {risk}\n" "Produce a corrected, final answer." ) return refined

The lesson: reliability comes from structure. Give each agent one job, let them check each other, and refine before you respond. That is exactly how DELPHAI "checks the math, explains the risk, and refines its answer."

2. Meet users where they already are

Archon delivers financial intelligence inside Microsoft Teams. StudyMate builds on a student's own notes. Winning agents reduce friction by integrating into existing workflows rather than asking users to adopt a new destination. When you build enterprise agents, target the surface, such as Microsoft 365 Copilot, Teams, and Copilot Studio, where the work already happens.

3. Test rigouris a differentiator, not an afterthought

Athenaeum won Top Student with 611 tests behind its multi-agent learning system. In a field of prototypes, evidence of engineering discipline stood out to judges. Agentic systems are non-deterministic, so a strong evaluation and test harness is what turns a demo into something trustworthy.

4. Design for everyone from day one

CLARO (accessibility-first reasoning) and Tell My Day (assistive storytelling for non-verbal users) prove that responsible, inclusive AI isn't a constraint; it's a source of the most meaningful innovation. Accessibility completions were a top skilling path this year, and the winners reflected it.

🎮 The Three Tracks and Their Toolchains

Agents League ran three build tracks, each anchored to a Microsoft developer platform. The winners map directly onto them:

Creative Apps → GitHub Copilot. AI-assisted development from concept to code. Winners: Afterlogin: The Hunt, StudyMate. (35% of the field.)

Reasoning Agents → Microsoft Foundry. Multi-step reasoning and agent orchestration. Winner: DELPHAI. (46% of the field, the most popular track.)

Enterprise Agents → Microsoft 365 Copilot & Copilot Studio. Business-ready knowledge agents. Winner: Archon. (19% of the field.)

🔴 The Reactor Battles: Learning in Public

The live Microsoft Reactor build battles were where the thousands of developers learned together in real time. The community connected over four live broadcasts. Microsoft Reactor Agents League series

A standout moment: Kyle Daigle, CMO of Microsoft Developer and COO of GitHub, live-coded his own project on stream during the Creative Apps Reactor Battle, an authentic build-along that resonated with the developer audience. As one attendee put it: "These types of sessions are the best, where we can see code and flows. It's like we learn more by visualising."

📚 Skill Up Like a Champion: The Developer Playlists

Winners don't appear from nowhere; many skilled up first. Seven role-based developer paths on AI Skills Navigator drove thousands of completions, spanning GitHub Copilot, Microsoft Foundry, and Microsoft 365. The top five learning playlists:

Develop your first agent with Microsoft Foundry, completions (the runaway favourite)

Learn AI-assisted coding with GitHub Copilot

Accessibility in practice

Optimise agentic DevOps with Azure DevOps & GitHub Copilot

Build and orchestrate agents with Microsoft Foundry

Completion earned free GitHub & Microsoft certification vouchers and Credly badges. If you want to be on next year's winners list, this is where to start.

🔧 One Honest Lesson for Next Time

Transparency matters, so here's a builder-to-builder tip drawn from the judging data. Of the final submissions, the single biggest disqualifier was a missing demo video, followed by no listed repository. Brilliant projects were screened out on a technicality.

The takeaway for future hackathons: treat your demo video and public repository as first-class deliverables, not last-minute additions. A working agent nobody can see or reproduce can't win. Record the demo early, keep the repo public, and document how to run it.

✅ Key Takeaways

Multi-agent architectures dominated the podium: DELPHAI's 11-agent council and Archon's 7-agent pipeline show that decomposition and self-verification win.

Integration and inclusivity are differentiators: winners met users inside Teams, in their own notes, and designed for accessibility from day one.

Engineering rigour gets noticed: 611 tests helped Athenaeum win one of the Top Student awards.

Submission hygiene is non-negotiable: a demo video and public repo are the price of admission to judging.

🚀 Your Next Move

Whether you're a returning competitor or inspired to enter your first battle, here's how to keep building:

🎬 Rewatch the battles: Microsoft Reactor Agents League series
📘 Start skilling: AI Skills Navigator AISF 2026 developer playlists
🤖 Build reasoning agents: explore Microsoft Foundry
💡 Ship with AI assistance: GitHub Copilot
🏢 Build enterprise agents: Microsoft Copilot Studio

To every builder who entered the arena, streamed a battle, or completed a playlist: thank you. You didn't just compete; you showed the world what's possible when developers and agentic AI build together. The champions above earned their moment, but the real story is a global community of 31,000 developers levelling up at once.

The arena will open again. When it does, will your agent be on the podium? 🏆

Agents League was part of AI Skills Fest 2026 and was open to the public at no cost. Figures reflect the completed submission and judging period after excluding Microsoft-affiliated participants. Winner descriptions are drawn from the official Agents League Hackathon summary.

1 million documents to 300+agents: Building an enterprise-scale Microsoft 365 Copilot connector

supramo — Thu, 23 Jul 2026 18:57:12 GMT

1 million documents. 100,000+ monthly users. 300+ Copilot Studio agents. Here's what we learned building the Microsoft 365 Copilot connector behind them.

Most enterprise knowledge lives in portals and repositories that people trust but rarely visit in the flow of work. That's the gap this connector was built to close.

At Microsoft, we built an enterprise-scale Microsoft 365 Copilot connector to make internal documentation available as grounded context across supported Copilot experiences. The connector runs in production today, serving teams across engineering, support, and field roles.

Who this post is for: platform teams, developers, and connector owners who are past prototype and thinking about production. We cover the design choices, security and governance considerations, schema decisions, operational patterns, and retrieval-quality practices that helped us make enterprise knowledge easier to discover and reuse through Microsoft 365 Copilot.

Understand why a Microsoft 365 Copilot connector matters

New to Microsoft 365 Copilot connectors? Start with the Microsoft 365 Copilot connectors overview and the Copilot connectors API documentation.

The real power of a Microsoft 365 Copilot connector isn't the ingestion — it's what becomes possible once your content is in the platform.

The moment your connector is live and configured for supported Microsoft 365 Copilot experiences, your content can become available as grounded context in those experiences. That means:

Copilot Chat — users ask questions in natural language and get answers grounded in your content, alongside emails, files, and Teams messages. No portal visit required.
Copilot in Microsoft 365 apps — in Copilot for Word, PowerPoint, and Excel (where supported), your knowledge can appear as context when users draft, summarize, or build presentations.
Copilot Studio agents — users with appropriate permissions and licensing can build custom agents scoped to your connector's content. In our case, 300+ agents were created by teams within Microsoft — incident response assistants, onboarding copilots, domain-specific Q&A bots — all without additional work from us.
Copilot CLI and developer tools — Copilot CLI is the command-line experience for developers working in a terminal. Engineers get answers in their terminal or IDE, grounded in the same authoritative content.
The Copilot Retrieval API — teams with appropriate access can programmatically query the indexed knowledge to build custom experiences we never anticipated.

The key insight is that a connector is not just an ingestion pipeline. When you invest in clean schema, reliable ingestion, and the right access controls, supported Copilot experiences can reuse that content without requiring a separate integration for every surface.

A quick note on terminology. This post describes a Microsoft 365 Copilot sync connector (previously known as a Graph connector). Sync connectors ingest and index your content into the Microsoft 365 substrate, which is different from federated connectors that query content in place.

Plan for production gaps

The public documentation gets you from zero to a working connector. Getting from a working connector to a production one uncovered four gaps we hadn't planned for: tenant configuration, security and compliance readiness, discoverability, and shared throttling limits.

Validate tenant configuration early

The documented path starts with creating a connector in your tenant and ingesting data. In our environment, we had to validate architecture before full production, and hit a few things that weren't in the docs. Watch out for:

Cross-tenant data flow. There is no supported model for cross-tenant data flow between Entra ID tenants today. We resolved this by consolidating connector operations into a single tenant.
"Draft" state limbo. Connectors can get stuck in "Draft" state despite correct permissions. Escalating through the platform team was the fastest unblock.
Ownership gaps. Multiple platform teams have overlapping responsibilities and no single owner. Identify your escalation path before you need it.
Dev tenant lifecycles. Dev tenants may have undocumented auto-deletion policies. Don't rely on a dev tenant as a long-lived staging environment.

Start security and compliance early

Registering an app and configuring permissions is the easy part. For a cross-tenant connector at enterprise scale, we also needed:

A threat model.
A privacy review.
A Responsible AI review.
Design reviews from platform teams.
Security exception approvals.

No template existed. No checklist. No predefined path. This was a significant effort that started well before we wrote code.

Make connector content discoverable

Even with successful ingestion, Copilot may not prioritize your content. Emails and user files rank higher by default. Connector content ranking varies across clients. There's no visibility into why a result was or wasn't surfaced.UserPrincipal support — the ability to attach a user identity to an indexed item so it's ranked with the same signals as that user's emails and files — is an important platform improvement for us. We plan to adopt it in the near future, with the goal of making connector content show up more reliably alongside a user's other work in Copilot results.

Design for throttling and shared limits

At approximately 1 million documents, throttling became an important design consideration. We handled it with retry logic, exponential back-off, monitoring for 429 responses, and operational alerts so we could detect ingestion slowdowns quickly.

The Microsoft 365 Copilot connectors platform has a global rate limit shared across all connectors in a tenant. If another connector spikes ingestion, yours gets throttled — and the 429 doesn't tell you why or who's consuming the budget. Today, there's no visibility into the shared quota, no priority system, and no way to reserve capacity, so it's worth designing your pipeline to tolerate unexpected back-pressure.

Build the connector for scale

Our architecture focused on one principle: keep the source content separate from the ingestion compute. That choice made the pipeline easier to retry, easier to monitor, and easier to evolve as the documentation platform changed.

Separate data from compute

A core design principle was keeping the data layer completely separate from the ingestion compute. The documentation platform stores content in Azure Blob Storage — that's the source of truth. The ingestion pipeline never owns or duplicates that data. Instead, it reacts to changes and transforms on the fly.

Blob Change Feed — Azure Blob Storage's change feed emits events whenever documents are created, updated, or deleted. This is the trigger for all ingestion work — no polling, no scheduled full crawls.
Azure Function (event-driven) — an Azure Function listens to the change feed and processes each event. It reads the blob, transforms the content, enriches metadata, and pushes the item to the Microsoft Graph connectors API. The function is stateless — all state lives in the storage layer and the Microsoft Graph platform.
Storage as the boundary — the function has read access to blob storage but never writes back. Data flows one direction: storage → function → Graph API. This keeps the pipeline simple to reason about and safe to retry — reprocessing a blob event is always idempotent.
Graph API ingestion — items are pushed with retry logic, back-off on 429s, and observability via Application Insights.

This separation means:

The documentation platform can evolve its storage independently — new formats, new metadata, reorganizations — without touching the ingestion pipeline.
The pipeline scales horizontally via Azure Functions consumption plan — spikes in content updates don't require capacity planning.
Failures are isolated — a bad blob doesn't block other ingestion, and the change feed provides natural retry semantics.

Iterate on schema design

We treated schema design as the highest-leverage decision. Through four iterations, we significantly improved retrieval quality — entirely through schema and metadata refinement:

Mapped document types (TSGs, runbooks, architecture docs, onboarding guides) to distinct property sets.
Wrote detailed connection descriptions optimized for Copilot's ranking.
Added custom properties for freshness and ownership signals.
Tested with real user queries, not synthetic data.

Use secure authentication and deployment patterns

A few patterns kept the deployment story simple across environments:

Managed Identity for service-to-service communication in production.
Infrastructure-as-code for consistent deployment across commercial and sovereign clouds.
Environment-specific configuration abstracted from the start.

Measure retrieval quality

One benefit of onboarding to the Microsoft 365 Copilot platform was access to the Search Evaluation framework used by the Copilot team. This helped us measure retrieval quality, including precision and recall against real user queries, without building evaluation infrastructure from scratch. We used this framework to test pipeline changes and catch regressions before they reached users.

Monitor connector health

A healthy connector is a prerequisite for everything else, so we built:

Alerting on ingestion failures and throttling spikes.
Recovery automation for re-ingestion scenarios.

See the impact

Once the connector was live, three things stood out: the portal became a platform, an ecosystem of agents formed on top of it, and we kept the controls we needed while gaining new ways to measure quality.

From portal to platform

The documentation platform moved from being a destination people visited to a knowledge source that powers AI experiences across Microsoft. Users no longer need to navigate to the portal — knowledge surfaces directly in Copilot Chat, Copilot in Word, Copilot in VS Code, and Azure Copilot. Consumption is ambient and contextual, embedded in existing workflows.

An ecosystem of agents

The core value proposition of the Microsoft 365 Copilot platform is this: push your content once, and it's enabled across multiple AI surfaces. That's exactly what happened.

300+ Copilot Studio agents now build on the connector. Content surfaces in Copilot Chat, Copilot CLI, Work IQ (Microsoft's workplace intelligence experience), and other AI-powered developer tools — all from a single ingestion pipeline. Teams within Microsoft created:

Incident response assistants that help surface relevant troubleshooting guides.
Onboarding copilots that pull architecture docs contextually.
Domain-specific Q&A agents scoped to their team's content.
Support augmentation workflows with human oversight.

Because we invested in getting the connector right once — clean schema, proper access controls, reliable ingestion — supported Copilot experiences reuse that content automatically. None of the 300+ agents required additional integration work from our team.

Measurable quality and preserved governance

Alongside the new capabilities, the shift preserved what mattered most: existing controls and a way to measure what we were doing.

Programmatic access at scale. The Copilot Retrieval API lets teams with appropriate access query the indexed knowledge programmatically, without the documentation team's involvement. Single ingestion, multi-surface consumption.
Governance stayed centralized. Despite AI integration, the connector continues to rely on existing Microsoft 365 security and access controls. Governance policies and access restrictions remain centrally managed. This was critical for sovereign cloud deployment and regulated environments.
Quality became measurable. With evaluation frameworks in place, we can quantify answer quality and continuously improve — something that wasn't possible when the platform was purely a static portal.

Apply these recommendations when building connectors

If you are planning a Microsoft 365 Copilot connector, these are the practices we would prioritize before moving from prototype to production:

Start security and compliance conversations before writing code — budget significantly more time than you expect.
Treat schema design as your highest-leverage decision — test with real Copilot queries early and iterate aggressively.
Build evaluation from day one — you need to measure whether Copilot is actually using your content effectively.
Build health monitoring for the connector itself — not just the pipeline.
Design for the ecosystem — if you build it well, people will build on it in ways you didn't anticipate.

Make the investment worthwhile

The public docs for Microsoft 365 Copilot connectors cover the "what." This post covers the "how" — and more importantly, the "why it's worth it."

Security approvals took months. Schema iteration took four rounds. Operational readiness took ownership none of us had budgeted for. But the payoff is real: your organization's knowledge becomes accessible through AI, grounded in authoritative content and available across supported Microsoft 365 Copilot experiences.

The platform is powerful. Getting there takes work. In our first year of production, 300+ agents were built on the connector — none of which required additional integration work from our team.

Get started

Join the conversation

Have you built a Microsoft 365 Copilot connector at scale? We'd love to hear what you learned — share your experience in the comments below, and let us know which patterns worked (or didn't) in your environment.

Did you know? The Microsoft 365 Roadmap is where you can track upcoming updates across Microsoft 365 apps and services. Microsoft 365 Copilot release notes are where you can review generally available Copilot features by platform. Check both resources regularly for the latest status, and note that roadmap dates are tentative and subject to change.

Announcing public preview of Azure DDoS Protection custom policy

OfirSarfaty — Thu, 23 Jul 2026 17:16:28 GMT

We are excited to announce the public preview of Azure DDoS Protection custom policy, a new capability that gives customers more granular control over how Azure DDoS Protection detects and mitigates attacks against protected workloads.

Azure DDoS Protection has always focused on delivering automatic, adaptive protection at scale. With custom policy, customers can now fine-tune mitigation behaviour for supported resources and configure protocol-specific detection thresholds. This allows customers to better align protection settings with any planned or projected changes in their application traffic patterns upfront, while giving them additional control over supported protocol thresholds.

Azure DDoS Protection custom policy is currently in preview. See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet generally available.

Why customers asked for more control

Azure DDoS Protection automatically analyses traffic patterns and applies adaptive mitigation during attacks. While this approach works well for most workloads, some organizations require additional flexibility to support unique traffic characteristics, operational environments, or changes around big releases and events.

Customers running latency-sensitive applications, high-throughput services, gaming platforms, or workloads with predictable traffic spikes often want the ability to customize mitigation trigger behavior for specific protocols.

Example scenarios include:

Applications with known peak traffic periods

Workloads that experience sustained high packet-per-second rates

Services requiring protocol-specific tuning

Organizations that need separate mitigation policies across environments or applications

Custom policy allows organizations to align DDoS protection behaviour with their operational traffic baselines while still leveraging Azure’s global-scale mitigation infrastructure.

Key benefits:

Granular, protocol-level control: Configure custom detection thresholds for TCP, UDP, and TCP SYN traffic, so mitigation triggers reflect how your application behaves rather than generic baselines.
Predictable protection during planned events: Align mitigation behaviour with anticipated traffic changes product launches, seasonal peaks, gaming events, so legitimate traffic surges aren't mistaken for attacks.
Flexibility without sacrificing scale: Fine-tune triggers for specific workloads while still benefiting from Azure's global-scale mitigation infrastructure and adaptive protection everywhere else.
Per-resource policy management: Apply separate policies across environments or applications, giving teams the ability to tune protection independently for dev, test, and production workloads.
Full operational visibility: Existing Azure Monitor and DDoS Protection telemetry continue to work with custom policies, so you can validate threshold changes and monitor mitigation activity end to end.

Public preview walkthrough

Customers can deploy and manage DDoS custom policies directly from the Azure portal.

To create a new policy:

Open the Azure portal.
Search for DDoS custom policies.
Select Create.
Choose the subscription, resource group, and region.
Select a supported frontend IP configuration.
Configure protocol detection rules.
Review and deploy.

Once deployed, the custom policy can be associated with supported frontend IP resources to apply protocol-specific mitigation settings.

Current public preview scope

During public preview, Azure DDoS Protection custom policy supports:

Standard Load Balancer frontend IP configurations

TCP, UDP, and TCP SYN threshold customization

Azure portal management

ARM and REST API deployment

Current limitations include:

Support is currently limited to Standard Load Balancer frontend IPs and no Power Shell support

As with all preview features, functionality and supported scenarios may evolve before general availability.

Important considerations

When a customer configures a custom threshold for a protocol, Azure disables autotuning triggers for that protocol and uses the configured static value.

Customers should:

Use anticipated traffic baselines to guide threshold selection

Start with conservative tuning changes

Validate behaviour in lower environments before broad deployment

Monitor mitigation telemetry after configuration changes

Azure Monitor and existing Azure DDoS Protection telemetry continue to provide visibility into mitigation activity and operational behavior.

Looking ahead

Azure DDoS Protection continues to evolve to support modern application architectures, large-scale internet exposure, and advanced operational requirements.

Custom policy extends Azure DDoS Protection's automatic, adaptive baseline with optional per-resource control, without changing the turnkey default that protects every workload out of the box. Autotuning stays on everywhere a custom threshold is not explicitly configured.

We want customers to know that Azure DDoS continues to be a hands-off fully automated service, and that policy customization is not a new operational model, but rather an optional override-on-top automated/adaptive engine.

Get started

Customers can begin using Azure DDoS Protection custom policy today through the public preview experience.

To learn more:

Review the Azure REST API documentation for DDoS Custom Policies here

Deploy a test policy in a supported subscription

Explore the Azure portal experience for policy management

Evaluate protocol-specific threshold tuning for your applications

We look forward to hearing your feedback.

Coming soon: the Frontier Partner specialization

JS5 — Thu, 23 Jul 2026 17:54:06 GMT

One of two Frontier-focused offerings in the Microsoft AI Cloud Partner Program, the Frontier Partner specialization validates partners who can design, build, deploy, govern, and secure AI agents across the Microsoft tech stack, including Microsoft 365 Copilot, Azure AI Foundry, GitHub Copilot, Microsoft Defender, Entra, and Purview.

Partners who earn this specialization signal their deep expertise to customers—and get access to badging, priority search, and skill-aligned benefits such as:

Eligibility for Frontier-aligned co-sell opportunities
Microsoft Agent prepurchase plan credits and Microsoft 365 E7 licensing
Packaged go-to-market resources including marketing campaigns and case study opportunities
Microsoft AI Cloud Partner Program Concierge support through the qualification process

The specialization will be open for enrollment later in FY27, but you can start preparing now.

Requirements across three components must be met simultaneously under the same Partner Global Account:

Specializations: Partners must hold the following four prerequisite specializations: Microsoft 365 Copilot, AI Apps on Microsoft Azure OR AI Platform on Microsoft Azure, Data Security, and Identity and Access Management.
Skilling: Five individuals from your organization must complete the Frontier Transformation Engineer badge; three individuals must earn the Fabric Analytics Engineer Associate (DP-600) certification. The people who hold the badge and the certification can be the same or different.
Audit: You must get a third-party audit validating delivery capability across design, build, deploy, govern, secure, and operate. There is a two-year audit cadence.

Review the walking deck for more details on this exciting opportunity.

Partner Blog | Navigating the next era of hosting: Your playbook is here

JillArmourMicrosoft — Thu, 23 Jul 2026 17:00:00 GMT

Hosting and hybrid cloud partners are currently navigating significant infrastructure transitions. In a May blog, we explored why changes in virtualization licensing, rising infrastructure costs, and evolving customer expectations are creating both pressure and opportunity for hosting businesses.

Now the conversation shifts from understanding the opportunity to taking action. It is about evolution without disruption: preserving what works, modernizing where it matters, and growing into higher-value services with Microsoft Adaptive Cloud.

That is why we created the new e-book, Navigating the Next Era of Hosting. It is a practical guide for hosting partners looking to protect margins, retain customer trust, and define a clear modernization path across Azure, hybrid, and AI-ready scenarios.

From awareness to action

Hosting partners are already fielding more complex customer conversations. Customers want flexibility across on-premises, edge, partner datacenter, and public cloud environments. They want consistent management, built-in security, stronger governance, and clear modernization options without being forced into a single destination or timeline.

At the same time, many partners are reevaluating long-standing platform strategies. Licensing changes, evolving commercial models, and rising infrastructure costs are prompting new questions about margin predictability, platform control, and long-term differentiation.

This is where action matters. Partners that move early can shape the conversation with customers instead of reacting to it. You can explain what will stay consistent, where modernization can begin, and how customers can retain choice while preparing for what comes next.

Continue reading here

Designing Intune enrollment for frontline workers: Choosing the right path for real-world devices

Intune_Support_Team — Thu, 23 Jul 2026 16:59:40 GMT

By: Shawn Catlin – Senior Product Manager | Microsoft Intune and Sucheta Gawade, Microsoft MVP (Azure & Security / Intune)

Practitioner perspective from Sucheta Gawade, Microsoft MVP (Azure & Security / Intune), with deep experience in secure frontline mobility, including regulated healthcare environments.

Enrollment methodology is one of the most consequential design decisions teams make for frontline environments. It shapes how devices are used, how identity is handled, how failures are recovered from, and how much friction workers experience before they can do their jobs.

Frontline use cases aren’t limited to shared devices. They can span nearly every enrollment type available in Microsoft Intune, including user-assigned, shared, dedicated, kiosk, corporate-owned, BYOD, and zero-touch deployment models. The right choice is often influenced by business need, operational workflow, budget, support model, and security requirements. But it must also account for platform and operating system design. Android, iOS, and iPadOS may offer similar enrollment concepts, but they don’t always behave the same way or support the same management patterns.

That distinction matters. A kiosk or dedicated-device model, for example, is intentionally designed for a locked-down, task-focused experience. It manages the device around a specific function, not around a personalized user workspace. In that model, broad app availability, persistent personalization, and user-driven app installation are not the primary management paradigm. Similarly, a shared-device model should not be selected simply because an organization cannot provide a dedicated device to every worker. If identity, app access, compliance, or user context are required, those needs must be part of the enrollment decision from the beginning.

There is no copy-and-paste frontline enrollment strategy that works across every industry, business unit, or device scenario. Some frontline devices are shared across shifts and must remain reliable where connectivity, identity, and support are not guaranteed. Others are assigned to supervisors, clinicians, field workers, or shift leads who need persistent access to apps, settings, and data. When enrollment choices are made without accounting for these realities, especially platform differences and OS-level limitations, friction surfaces quickly during pilots and scales painfully during rollout.

This article explains how to approach Intune enrollment for frontline devices through a practical, reality-first lens: start with how the device is used, align the management model to the workflow, and then plan how the device will be enrolled, replaced, and reprovisioned at scale.

In a hospital environment, frontline does not mean one type of device or one type of worker. A shared clinical workstation, a nurse’s mobile device, a patient check-in kiosk, a barcode scanner, and a supervisor’s assigned device may all be considered frontline, but they each have very different identity, security, app, and recovery requirements. That is why enrollment decisions have to start with the workflow.

Sucheta Gawade
Practitioner

Enrollment Is a Design Decision, not a Checkbox

Enrollment does more than bring a device under management. It defines how the device is expected to work, where the security boundary sits, how identity is applied, and what recovery looks like when something fails in the field.

There is no single “best” enrollment model for frontline. There is only the model that best fits how the device is actually used. The right choice depends on whether the device follows a person, a shift, a task, or a business process. It also depends on how much identity matters to the experience, whether apps need to be personalized, whether Conditional Access or compliance is required, and how quickly the device must be replaced or recovered.

This is why many problems that look like policy, app, or configuration failures are actually enrollment design problems in disguise. A device can be successfully enrolled and still be poorly designed for the job it needs to do.

A device can be successfully enrolled and still fail the workflow. If a shift worker cannot access the right app quickly, if a shared device retains the wrong user context, or if a replacement device cannot be brought online during a shift, the issue may look like an app or support problem. In reality, it often traces back to an enrollment model that did not match the workflow.

Sucheta Gawade
Practitioner

Separate Two Decisions: Management Model and Provisioning Method

Frontline enrollment planning becomes easier when teams separate two related but different decisions.

The first decision is the management model. This is the architectural choice. It answers questions such as:

Does the device need to represent a specific person?
Is the device shared across multiple workers?
Is it dedicated to a narrow task or workflow?
Does the device require personal apps, persistent settings, or user-specific data?
Does the workflow require Conditional Access, compliance, auditability, or individual identity?

This decision determines whether the device should be user-associated, shared, dedicated, kiosk-style, personally owned, or corporate-owned with a work profile.

The second decision is the provisioning and reprovisioning method. This is the lifecycle choice. It answers questions such as:

How will the device get into management the first time?
Will it be staged by IT, a depot, a partner, or the site?
What happens after a wipe, repair, refresh, or reassignment?
Can the device recover without a specific user’s credentials?
Will Wi-Fi, certificates, tokens, apps, and policies be available at first boot?

Zero-touch, pre-staging, depot workflows, and reprovisioning plans support the selected management model. They should not replace the decision about which model is right for the scenario.

Start With How the Device Is Used

In the previous article, Migrating Frontline Mobile Devices: Understanding the Reality of Your Estate, we discussed why successful frontline migrations begin with understanding how devices are actually used in the field. That discovery work should now feed directly into enrollment design.

The most reliable starting point is not the department, license, or ownership model. It is the device’s behavior in the field.

Ask:

Does this device follow a person?
Does it follow a shift?
Does it follow a task?
Does it need to know who the user is?
Does it need persistent user context?
Does it need to be quickly replaced with minimal IT involvement?
Does the platform support the experience you expect?

The answers help map real-world requirements to the right Intune enrollment approach. Before selecting an enrollment model, organizations should also understand how identity is expected to function on the device. If you have not yet reviewed assigned versus shared identity patterns, see our previous article, Migrating frontline mobile devices: Identity considerations for assigned and shared devices, which explores how user identity, authentication, auditability, and device ownership assumptions can influence frontline management decisions.

Decision indicator	Usually points toward	Validate before choosing
One person regularly uses the device and needs persistent apps, settings, approvals, or data	User-driven or user-associated enrollment	Whether identity and personalization are truly required for the workflow
Multiple workers use the same device across shifts and need individual sign-in	Shared or device-first enrollment with identity support	How sign-in, sign-out, session cleanup, and auditability will work
The device performs a narrow, repeatable task	Dedicated or kiosk-style enrollment	Whether the workflow can operate with a locked-down app set and minimal user choice
The device needs corporate control but may allow limited personal use	Corporate-owned work profile where supported	Whether the OS supports the expected separation between work and personal data
The device is personally owned and only work data needs to be protected	BYOD / personally owned work profile / user enrollment	Whether the workflow can tolerate limited organizational control
The device must be replaced quickly with minimal IT involvement	Pre-staged, zero-touch, or easily reprovisioned device-first model	Reset behavior, network readiness, certificate delivery, and replacement speed
The environment has inconsistent connectivity or limited support	Simpler enrollment paths with fewer live dependencies	What the device needs at first boot, during sign-in, and after wipe or reset

Map Frontline Scenarios to Enrollment Models

A practical Intune strategy starts by accepting that frontline is not one scenario. It is a collection of scenarios. Standardization is important, but standardizing on one enrollment method for every frontline use case is rarely the right goal. Mature organizations standardize the decision framework, not necessarily the deployment model.

Device usage pattern	Typical characteristics	iOS/iPadOS enrollment	Android enrollment
User-assigned device	One person regularly uses the device and needs personalized apps, settings, and data	Automated Device Enrollment with user affinity	Android Enterprise Fully Managed or Corporate-Owned Work Profile if personal use is permitted
Shared device with individual sign-in	Multiple workers share the device and sign in with their own identities	Automated Device Enrollment with Microsoft Entra Shared Device Mode; Shared iPad when multi-user iPad support is required	Android Enterprise Dedicated Device with Microsoft Entra Shared Device Mode
Dedicated or task-based device	Device performs a specific function and does not require a personalized user experience	Automated Device Enrollment without user affinity, with supervised device and app restrictions	Android Enterprise Dedicated Device
Android device without Google Mobile Services	Corporate-owned specialty device, often shared or task-focused	Not applicable	Android AOSP userless or AOSP user-associated enrollment
Personally owned device	Employee-owned device used for work	BYOD User Enrollment	Android Enterprise Personally Owned Work Profile
Zero-touch or pre-staged deployment	Corporate-owned device that needs scalable provisioning or replacement	Automated Device Enrollment through Apple Business Manager or Apple School Manager	Android Zero-touch Enrollment, Samsung Knox Mobile Enrollment, or equivalent supported provisioning path

If the device follows a person, choose a model optimized for identity and personalized access. If the device follows a shift, workflow, or task, choose a model optimized for simplicity, consistency, and easy replacement.

If you’re looking for more platform-specific guidance please see frontline enrollment resources for both Android and iOS/iPadOS:

These resources provide detailed implementation guidance, recommended enrollment approaches, and platform-specific considerations for frontline deployments.

Platform and OS Differences Matter

Teams often assume that similar enrollment concepts behave the same way across platforms. They do not.

On Android, a shared frontline device that needs a locked-down experience and individual worker sign-in often maps to Android Enterprise Dedicated Device with Microsoft Entra Shared Device Mode. Android Enterprise Dedicated Device provides the task-focused management model. Entra Shared Device Mode adds the identity layer so workers can sign in as themselves. Intune Managed Home Screen then helps present a consistent launcher experience and enforce the sign-in flow between shifts.

On iPadOS, a shared device with individual sign-in may be designed using Shared iPad for Business or Automated Device Enrollment with Microsoft Entra Shared Device Mode. The distinction becomes important when security requirements are involved. Shared iPad can support multi-user scenarios, but organizations should review its limitations carefully, especially if Conditional Access or device compliance enforcement is required. Where Conditional Access, compliance, and security-driven access controls are mandatory, ADE with Entra Shared Device Mode may be the better fit, although it introduces additional configuration considerations and dependency on compatible apps. See Shared iOS and iPadOS devices for more information.

Platform differences also matter for corporate-owned devices that allow personal use. Android Corporate-Owned Work Profile provides a native work profile boundary between corporate and personal data. iOS and iPadOS do not provide that same OS-level separation for corporate-owned personally enabled devices, so organizations often rely more heavily on app-level controls and MAM policies.

The practical point is simple: choose the enrollment model that fits the workflow, but confirm that the platform supports the management pattern you expect.

One of the most common mistakes I have seen is designing for the cleanest administrative model instead of the messiest operational reality. In FLW cases, the real test is not whether the device enrolls successfully on day one. It is whether the device can keep supporting the workflow after shift changes, network changes, app issues, wipes, repairs, and urgent replacements.

Sucheta Gawade
Practitioner

When User-Driven Enrollment Makes Sense

User-driven enrollment still has a place in frontline, but the use cases are narrower than many teams expect. It makes sense when the device needs to reflect a specific person, not just a task.

This can work well for shift managers, supervisors, clinicians, field workers, or frontline leads who need persistent access to apps, approvals, notifications, data, and settings. In these cases, user-driven or user-associated enrollment can provide cleaner app targeting, stronger identity context, and a more familiar experience for the person carrying the device.

Common indicators include:

The worker keeps the device for most of its working life.
The user needs email, Teams, approvals, or real-time app badges.
The workflow depends on user-specific apps, settings, or data.
The device may support some personal enablement where the platform supports separation.
The worker is responsible for keeping the device available, charged, and ready for use.

But personalization comes with operational cost. User-driven enrollment increases dependency on credentials, adds friction when sign-in steps fail, and makes recovery more complex when a device must be replaced quickly. It is usually a poor fit for shared workflows, high-turnover roles, or task-based devices where speed and predictability matter more than personalization.

Designing for Shared and Shift-Based Devices

Shared and shift-based devices are passed from one worker to the next. They are expected to stay productive across handoffs and often operate in environments where there is little time for sign-in friction or troubleshooting.

For these scenarios, device-first enrollment usually aligns better with reality because the device is treated as a managed tool for a shared workflow, not as a personal endpoint tied to one individual. The goal is consistency: the next worker should be able to pick up the device, authenticate if required, and get to work without recovering from leftover state or complex setup steps.

If shared devices require individual sign-in, identity must be designed into the enrollment model. Microsoft Entra Shared Device Mode and QR code authentication can help preserve individual identity without forcing workers through a full username and password flow at every handoff. This is especially relevant in environments such as retail, healthcare, warehousing, and field operations where shared devices still need auditability, Conditional Access, app access, or user-specific sessions.

Shared-device success does not come from default settings alone. Teams should define:

How sign-in and sign-out should work.
What user context should persist.
What should be cleared between sessions.
Which apps need to support shared-device behavior.
How quickly a device can be swapped or reprovisioned.
Whether access depends on the user, the device, the app session, or a combination.

Especially in healthcare and clinical settings, shared devices have to be absolutely ready for the next worker, the next patient, and the next task. There is rarely time for complex recovery steps, unclear ownership, or leftover user state from the previous shift. A good shared-device design should support quick handoff, clean session behavior, and predictable recovery under pressure.

Sucheta Gawade
Practitioner

Dedicated and Kiosk Devices: Avoid Personalization Drift

Dedicated and kiosk-style enrollment is ideal when the device performs a narrow, repeatable function and individual identity is secondary or unnecessary. Examples include scanners, point-of-sale systems, check-in kiosks, digital signage, inventory devices, and task-specific handhelds.

The strength of kiosk-style design is that it limits choice. That is also the boundary teams must respect. A kiosk is not intended to behave like a general-purpose device where users browse a catalog of available apps, personalize settings, or install what their business unit needs on demand.

A common friction point occurs when organizations try to simplify IT support with one shared kiosk configuration for multiple businesses or personas, and then expect users to install the apps they need. That creates a mismatch. User-installed available apps are not the kiosk paradigm. If each business unit needs a different set of apps, the better design is usually to do the work upfront: segment the device scenarios, define the required app sets, and deploy the right configuration to the right devices.

This is also important for identity and certificates. User certificates, persistent user sessions, and shared secrets can conflict with the assumptions of a device-first or kiosk model. If the workflow requires user identity, auditability, or user-specific access, that requirement should be addressed through the right shared-device identity pattern, not bolted onto a kiosk design after the fact.

Enrollment at Scale: Plan for Provisioning and Replacement

Once the right management model is selected, teams should plan how devices will be enrolled and reprovisioned at scale.

At scale, enrollment becomes a lifecycle capability. The question is not only how a device gets into management the first time. Instead, it is how quickly that same device can be staged, replaced, wiped, repaired, reassigned, or reintroduced into service.

Some organizations ship devices directly to frontline locations and complete setup during out-of-box experience. Others rely on depot, partner, or white-glove processes to front-load setup before the device reaches the site. Neither model is automatically better. The right choice depends on network readiness, site support, variability at first boot, app dependencies, certificate delivery, and replacement expectations.

Replacement velocity is a real design constraint. In many frontline settings, a broken device cannot wait for a full troubleshooting cycle. A worker may need to drop one device at a charging bay and pick up another with minimal disruption. The more the enrollment and reprovisioning model supports a known-good state, the less productivity depends on one specific device surviving the shift.

Common Friction Points in Frontline Enrollment

Frontline enrollment problems are rarely caused by one dramatic failure. More often, they come from reasonable decisions made in the wrong order or optimized for the wrong thing.

Friction point	Why it happens	Better design approach
Treating frontline as only shared	The organization assumes all frontline workers use devices the same way	Segment by workflow: person, shift, task, or business process
Choosing shared because dedicated devices are too expensive	Budget drives the model before identity and workflow are understood	Validate identity, app, compliance, and recovery needs before choosing shared
Using kiosk for personalized workflows	Kiosk seems simple and locked down	Use kiosk only when the workflow is task-focused and does not require broad personalization
Wanting available apps on kiosk devices	One configuration is used for too many personas	Build scenario-specific app sets and configurations instead of relying on user installation
Using shared credentials	Enrollment was not designed for individual identity	Use Entra Shared Device Mode, QR code authentication, or another supported identity pattern
Requiring user certificates on device-first or kiosk scenarios	Security assumptions are copied from knowledge-worker designs	Validate whether access can be controlled through device, app, or session design
Over-securing setup at the expense of recovery	Controls are designed for ideal conditions, not shift pressure	Design security that holds up during replacement, poor connectivity, and limited support
Treating enrollment as a one-time event	Success is measured by initial provisioning only	Design for wipe, repair, reassignment, refresh, and reprovisioning

A deployment path that saves time on day one can create years of friction if it does not match how the device is used. In frontline scenarios, the best enrollment model is not always the fastest one to provision. It is the one that is easiest to sustain.

One of the most common mistakes I have seen is designing for the cleanest administrative model instead of the messiest operational reality. In FLW cases, the real test is not whether the device enrolls successfully on day one. It is whether the device can keep supporting the workflow after shift changes, network changes, app issues, wipes, repairs, and urgent replacements.

Sucheta Gawade
Practitioner

Closing

Successful frontline deployments are rarely defined by the sophistication of their policies alone. They are defined by how well design choices hold up under real-world pressure. Enrollment is one of the earliest and most visible signals to frontline teams about whether the technology is there to support their work or get in the way.

By treating enrollment as a deliberate design decision and grounding it in how devices are actually used, organizations can reduce friction, improve resilience, and create a foundation that scales as frontline operations evolve. Getting enrollment right does not guarantee success, but getting it wrong sets a ceiling that no amount of policy refinement can overcome.

For more frontline examples and implementation guidance, see related Microsoft frontline worker management resources, including the blog, From the frontlines: Frontline worker management with Microsoft Intune, and the earlier article, Migrating Frontline Mobile Devices: Understanding the Reality of Your Estate.

When enrollment, identity, security, and recovery are designed well, frontline teams can stay focused on the people they serve - customers, patients, guests, employees, students, and communities - instead of the device in their hands. That is the standard a frontline enrollment strategy should be measured against.

Sucheta Gawade
Practitioner

As always, we welcome your feedback and experience. If you’ve navigated identity decisions for shared or frontline devices, share your advice and lessons learned in the comments, or reach out to us on X @IntuneSuppTeam.

Introducing MAI-Image-2.5 Pro and MAI-Voice-2 Flash in Microsoft Foundry

Naomi Moneypenny — Thu, 23 Jul 2026 16:32:22 GMT

One of the core principles in Microsoft Foundry is giving customers flexibility to choose the right model for the right job. As we've continued to expand the Microsoft AI (MAI) model family, we've heard a consistent theme from developers and enterprises: they want more choice based on their specific workload requirements. Some need the highest possible quality, fidelity, and consistency for professional production workflows. Others prioritize responsiveness and cost-efficiency for frequent, real-time responses.

Today, we're introducing two new additions to the MAI portfolio:

MAI-Image-2.5 Pro, designed for customers who need maximum visual fidelity and creative control
MAI-Voice-2 Flash, built for low-latency voice applications where every millisecond matters.

Together, these models extend the MAI family with specialized options that help developers optimize for the jobs they need to do. Let’s dive in.

MAI-Image-2.5 Pro: Built for professional creative workflows

MAI-Image-2.5 Pro is our newest high-fidelity image generation model, designed for scenarios where visual accuracy, consistency, and creative control are critical. The model delivers stronger object consistency, improved alignment with creative intent, and enhanced visual reasoning and world knowledge, making it the ideal choice when quality and fidelity matter more than throughput.

As generative AI moves from experimentation to production, creative teams increasingly need models that can reliably generate assets that meet professional standards without extensive manual editing. MAI-Image-2.5 Pro was built to address those needs. Here are some of the scenarios it best fits:

Campaign Hero Assets & Multi-Frame Storytelling. Creative agencies and marketing teams can create polished campaign visuals while maintaining consistent products, characters, and brand elements across every asset. Whether producing launch campaigns, social media variants, retail signage, or digital advertising, Image-2.5 Pro helps ensure visual consistency throughout the customer journey.
Product Photography & E-Commerce Catalogs. Retailers and consumer brands can generate high-quality product imagery with accurate rendering of packaging, labels, materials, and reflections. The model's improved object consistency helps maintain identical product representation across multiple angles, color variations, and lifestyle settings.
Storyboarding & Pre-Visualization. Film studios, game developers, and creative production teams can rapidly develop visual concepts while maintaining consistency across characters, environments, props, and scenes. Enhanced visual reasoning enables more accurate interpretation of camera direction, lighting, and staging instructions.
Regulated Industry Content Creation. Organizations in healthcare, financial services, manufacturing, and other regulated industries can generate imagery that requires greater real-world accuracy and domain understanding, reducing the effort needed to correct inaccuracies before customer-facing use

When should customers use MAI-Image-2.5 Pro vs. MAI-Image-2.5?

Both models deliver high-quality image generation capabilities, but they are optimized for different priorities.

Choose MAI-Image-2.5 Pro when:

You need maximum image fidelity and creative quality.
Object consistency across multiple images is critical.
Your workflow depends on visual reasoning, world knowledge, and close adherence to creative direction.
You are producing professional marketing, advertising, product design, or enterprise creative assets.

MAI-Voice-2 Flash: Real-time voice experiences at scale

We're also introducing MAI-Voice-2 Flash, a new low-latency text-to-speech model that extends MAI-Voice-2 with faster response times and greater cost efficiency across more than 15 supported languages.

As voice becomes a critical interface for AI applications, responsiveness is increasingly important to the end-user experience. Whether a customer is speaking with an AI-powered support agent, interacting with a voice assistant, or navigating a self-service phone system, long pauses can make experiences feel slow and unnatural. MAI-Voice-2 Flash was built to address those scenarios. Here are some of the scenarios on when to choose MAI-Voice-2 Flash:

Call Center Agents: Customer support organizations can generate spoken responses in real time, minimizing delays between conversation turns and enabling more natural customer interactions. Low latency helps improve customer experiences while supporting AI-powered service, support, and sales workflows.
Conversational Voice Assistants: Developers can build voice-enabled copilots, assistants, and intelligent applications that respond nearly instantly. The result is a more fluid, natural conversation that feels interactive rather than turn-based.
Interactive Voice Response (IVR) Systems: Organizations can modernize traditional phone systems with dynamic AI-generated speech that responds contextually to customer requests while maintaining a responsive user experience.

When should customers use MAI-Voice-2 Flash vs. MAI-Voice-2?

The distinction between the two voice models comes down to whether customers are optimizing for voice identity or real-time responsiveness.

Choose MAI-Voice-2 Flash when:

Low latency is a primary requirement.
You are building conversational assistants, IVR systems, or call center experiences.
Users expect immediate spoken responses as part of a live interaction.
Cost efficiency and responsiveness are more important.

Get started today in Microsoft Foundry

MAI-Image-2.5 Pro is available through Microsoft Foundry, providing developers with access to Microsoft's latest advancements in image generation. Pricing starts at $5 per 1M tokens for text input, and $106 per 1M tokens for image output.

MAI-Voice-2 Flash is available through Azure Speech, allowing customers to leverage Azure Speech's enterprise-grade reliability, scalability, and ecosystem while benefiting from Microsoft's latest voice technology. Pricing starts at $15 per 1M characters.

Your startup doesn't have an SRE team. Now what?

rmmartins — Thu, 23 Jul 2026 15:47:17 GMT

Most startups I work with have between 3 and 15 engineers. None of them have a dedicated SRE. The infrastructure runs on Azure, the team ships fast, and reliability is everyone's job until something breaks at 2 AM and it becomes one person's problem.

This is not a criticism. It is the rational allocation of scarce engineering time. But it creates a gap: nobody is watching the slow drift toward misconfiguration, overspend, and compliance debt. By the time these surface, they surface as incidents.

I spent the last few months building something to close that gap, and I want to share both the tool and the thinking behind it.

The problem with reactive operations

When a 10-person startup hits its first real outage, the postmortem usually reveals the same pattern: a quota was at 94% and nobody checked, a Network Security Group rule was too broad and nobody audited, a storage account had public access enabled six months ago during a debugging session and nobody reverted it.

The fixes are trivial. The problem is that nobody had the bandwidth to look. Traditional monitoring covers the "is it up?" question well. It does not cover "are we accumulating risk?"

Azure SRE Agent was built to fill exactly this space. It runs proactive, scheduled checks against your infrastructure and surfaces findings before they become pages. The built-in skills cover common scenarios, but every environment has its own shape. A fintech startup cares about different things than a gaming company.

Custom skills: teaching the agent your priorities

SRE Agent supports custom skills, which are structured prompts that tell the agent what to check, how to check it, and how to present findings. Think of them as runbooks that execute themselves on a schedule.

I built a pack of 8 skills that cover the gaps I kept seeing across startup engagements:

A Well-Architected Framework review that scores all 5 pillars and flags the weakest one
A compliance audit covering RBAC drift, missing resource locks, inconsistent tagging
Capacity planning that checks quota utilization and projects when you will hit limits
FinOps analysis combining cost optimization with chargeback allocation
Blameless postmortem generation using the 5 Whys method
Defender for Cloud Secure Score monitoring with prioritized remediation
A governance maturity assessment designed specifically for Digital Native companies
An AI Foundry and Azure OpenAI posture check for teams running LLM workloads

Each skill runs read-only. No write operations, no deployments, no changes to your environment. The agent reads your infrastructure state and produces a scored report with specific remediation commands you can choose to run or ignore.

Design decisions that matter

A few choices shaped how these skills work, and I think they are worth explaining because they apply to anyone building custom skills.

Scoring over pass/fail

Every skill produces a numeric score. A binary "compliant / not compliant" result is less useful than knowing you are at 41/100 on governance maturity and your weakest area is identity management. Scores let you track improvement over time and prioritize effort.

Inline documentation links

Each finding includes a link to the relevant Microsoft Learn page. When the agent tells you that your Azure OpenAI deployment lacks a private endpoint, the remediation section includes the exact az CLI command and a link to the documentation explaining why it matters. The goal is that an engineer can go from finding to fix without opening a browser to search.

Tiered scheduling

Not all checks need the same frequency. The capacity planning skill should run daily because quotas can spike fast. The Well-Architected review is a weekly check because architectural drift happens slowly. I organized the 8 skills into three priority tiers so teams can configure schedules that match the volatility of each risk category.

No write operations, ever

This was a hard line from day one. These skills read infrastructure state through Azure Resource Graph, Azure CLI queries, and REST API calls. They never create, modify, or delete resources. The remediation commands appear in the output as suggestions for a human to review and execute. This constraint makes the skills safe to run on production subscriptions without additional approval workflows.

What the output looks like

Here is a real example from the Digital Native Governance skill running against a test subscription.

The agent checks 6 governance categories: Alerting, Subscription Topology, Cost Controls, Identity, Web Protection, and Operational Foundations. Each category gets a score against its maximum, and the total determines a maturity level (Foundation, Developing, Established, or Optimized).

In my test run, the subscription scored 41/100, placing it at "Developing" maturity. Web Protection scored 0/15 because there was no WAF, no custom domain, no DDoS protection. Alerting scored 3/20 because Service Health and Resource Health alerts were missing entirely. That is specific enough to act on immediately.

The FinOps skill found ~$43/month in recoverable waste on a subscription that costs about $177/month. Empty container registries, deallocated VMs still paying for disks and public IPs, overprovisioned Defender plans. Not a huge number, but for a pre-seed startup running lean, that is real money sitting idle.

And here is what the Well-Architected review looks like when it scores all five pillars:

Lessons from building this

Three things I did not expect when I started.

First, prompt structure matters more than prompt length. Early versions of these skills were verbose, with long explanations of each check. The agent performed better with terse, structured instructions that clearly separated what to check, how to check it, and how to format the result. Clarity beats volume.

Second, the LLM behind the agent occasionally rendered emoji shortcodes (:red_circle:) as literal text instead of Unicode characters. This sounds minor but it made the output hard to scan visually. The fix was a single line in the skill definition: "Use Unicode emoji characters directly, never use emoji shortcodes." Explicit formatting instructions prevent the model from making stylistic choices that degrade readability.

Third, scoring philosophy requires intentional calibration. If you weight security checks too heavily, every subscription looks terrible and the report loses signal. If you weight them too lightly, teams ignore real risk. I landed on roughly 35% security, 30% reliability, 25% cost, and 10% architecture for the AI workload skill after testing against several real environments and seeing which distributions produced actionable variance between "good" and "needs work" subscriptions.

How to use this

The skills are open-source at github.com/ricmmartins/azure-sre-agent-skills. Each skill is a single Markdown file you paste into the SRE Agent portal at sre.azure.com. Setup takes about five minutes per skill.

You do not need all eight. If your startup is pre-revenue and running a single subscription, start with Capacity Planning and FinOps. If you are preparing for an enterprise customer's security questionnaire, start with Compliance and Defender Secure Score. Pick the two or three that match your current pain.

The skills are MIT-licensed and designed to be forked. If your compliance requirements include specific tagging conventions or naming standards, edit the skill to check for those. The structure is documented so you can build your own from scratch if none of mine fit.

How this differs from Azure Advisor

The first question people ask: why not just use Azure Advisor?

Advisor gives you a flat list of recommendations per resource. It tells you "this VM could be smaller" or "enable HTTPS on this App Service." Useful, but limited in three ways.

First, Advisor has no concept of correlation. It does not know that your failing health probe, your missing Resource Health alert, and your absent backup vault are three symptoms of the same problem: nobody set up operational foundations for that workload. These skills connect findings across domains and produce a single maturity score that tells you where you actually stand.

Second, Advisor does not generate narrative reports. It exports a CSV of individual recommendations, but there is no scored document with correlated findings, maturity levels, and prioritized remediation commands that you can forward to a CTO or attach to a security questionnaire. These skills produce that artifact directly in the chat, ready to copy or download.

Third, Advisor is passive. You go to the portal and look at it. SRE Agent runs your skills on a schedule and surfaces problems before they surface themselves as incidents. The difference between "there is a recommendation waiting in the portal" and "the agent flagged a quota at 85% utilization this morning" is the difference between a suggestion and a safety net.

Think of Advisor as a linter. These skills are closer to a staff SRE who reads everything, correlates the findings, and writes you a report with priorities and az CLI commands ready to paste.

What this is not

This is not a replacement for proper observability, incident management, or SRE staffing. When your startup reaches the scale where you need a dedicated SRE function, you should build one.

What these skills give you is coverage during the phase when you do not have that function yet. They catch the slow-moving risks that slip through the cracks when everyone is heads-down shipping features. Think of them as a part-time auditor who checks in daily and tells you what drifted since yesterday.

For startups on Azure, that gap between "we should probably check our security posture" and "we have someone whose job it is to check our security posture" can last years. These skills are one way to fill it.

Understanding Microsoft 365 Copilot Risk Surface and Mitigations

AtilGurcan — Thu, 23 Jul 2026 15:37:20 GMT

It’s a shift that carries important security implications organizations should understand before scaling deployment. Customers with Microsoft 365 E5 licensing may already have access to many of the tools that can help identify and reduce Copilot-related risk, but licensing alone does not reduce exposure.

What’s often missing during early Copilot deployments is a clear understanding of the risk surface itself: what data is exposed, who can access it, and through which vectors.

Organizations beginning their Zero Trust journey can use the Zero Trust Workshop to assess their current posture, identify gaps, and better understand how existing permissions and governance impact Copilot readiness.

In this post, we take a broader look at the types of risks Copilot can amplify and how those risks align to key Zero Trust pillars.

Why Copilot changes the risk conversation

Before assessing specific risks, it's worth understanding why AI solutions like Copilot introduce a different risk conversation than traditional Microsoft 365 applications.

Most enterprise applications operate within a bounded context. A user opens a file, reads an email, or searches a SharePoint one item at a time. The time and effort required to manually locate, connect, and synthesize information across systems creates a natural friction layer.

While that friction was never designed as a formal security control, it did create a practical limit on how quickly users could surface and act on organizational data at scale.

Microsoft 365 Copilot removes much of that friction entirely. It operates at the speed of a prompt across the full scope of a user's access rights, synthesizing information from emails, files, meetings, chats, and other Microsoft 365 data sources into a single response.

The exposure is not the result of new permissions; it comes from how quickly and easily existing access can be discovered and aggregated. In short, Copilot makes data once hidden by volume discoverable by intent.

Use Zero Trust to assess Copilot risk

Zero Trust rests on three principles: verify explicitly, use least-privileged access, and assume breach. Rather than trusting users or devices by network location, it requires continuous validation of every user, endpoint, and request. This analysis focuses on the four pillars most directly involved in Copilot deployments.

Together, these pillars answer three questions: who can access Copilot; from which endpoints and applications; and what data Copilot can surface once access is granted.

The two-layer Copilot risk model

The foundation is simple: Copilot acts as a force multiplier for whatever access a user already has. If that access is governed well, Copilot improves productivity; if not, it amplifies exposure. Risk is therefore examined in two layers — access to the Copilot service itself, and access to the data Copilot can ground on and surface.

MICROSOFT 365 COPILOT · TWO-LAYER RISK MODEL

Layer-1 Access Risk
Identity	Device
Who can access copilot	From which devices
Under what conditions	Device compliance posture
Layer-2 Data & Governance Risk
Apps	Data
What copilot can access and surface	Sharing and permissions
Connected data sources	Labeling, classification, output context

Table-1: Two-layer model for Microsoft 365 Copilot risk

Risk Layer-1: Who can access Microsoft 365 Copilot?

The first layer of risk begins at the point of entry: the conditions that determine whether a user can access Copilot. Organizations don’t need to address every potential exposure point at once. Think of the following table as a map of where exposure can exist across identity and device controls. For details of how remediation works for this layer of risks; you may refer to the blog post: Mitigating Microsoft 365 Copilot access risk: Identity and device controls for Zero Trust.

The following risks are primarily governed by the Identity and Devices pillars of Zero Trust and define whether Copilot is being accessed by the right person, from a trusted device, under appropriate authentication and access conditions.

	Risk	Pillar	Description
R1	Unmanaged identity access	Identity	A compromised, shared, or former employee account can authenticate to Microsoft 365 and access Copilot. Because Copilot operates across the full scope of a user’s permissions, compromised accounts expose a much larger risk surface than before Copilot existed. Strong account hygiene and identity lifecycle management therefore directly reduce Copilot exposure.
R2	Weak or absent multi-factor authentication	Identity	If organizations do not enforce MFA, or if legacy authentication bypasses modern sign-in controls, users can start Copilot sessions using only a password. In environments with inconsistent MFA coverage, attackers may need only stolen credentials to gain access. Because Copilot synthesizes data across services, compromised accounts create significantly greater risk than access to a single application.
R3	Unmanaged or non-compliant devices	Devices	Users can access Copilot through browsers and native applications from any device where they can authenticate. Unmanaged devices without EDR coverage, disk encryption enforcement, or compliance posture evaluation can expose Copilot sessions and allow attackers or unauthorized users to store or exfiltrate outputs locally.
R4	License sprawl without role-based scoping	Identity & Apps	Enterprise Copilot pilots often start with broad license assignments across departments, floors, or business units instead of deliberate, security-reviewed pilot groups. When organizations assign licenses without reviewing each user’s access rights, permission posture, and role sensitivity, Copilot can amplify risk across both highly governed and minimally governed users. Broad pilot enrollment without access review is itself a risk factor.
R5	Missing real-time risk evaluation at sign-in	Identity & Devices	If Conditional Access does not evaluate sign-in and user risk signals—such as impossible travel, anomalous token activity, or identity protection alerts—high-risk sessions may still gain access to Copilot. Without real-time risk gating, controls respond only after access is granted, by which point Copilot may already have surfaced and synthesized sensitive content.
R6	App protection gap on mobile devices	Devices & Apps	Users can access Microsoft 365 Copilot mobile—and the broader Microsoft 365 mobile surface that exposes Copilot—from personal devices that are not enrolled in MDM or MAM. Without an application protection policy, organizations cannot prevent users from copying Copilot outputs into unmanaged apps, remotely wipe organizational data from lost devices, or restrict screenshots and screen recordings during Copilot sessions containing sensitive data.

Table - 2: Risks in Layer-1: Who can access Microsoft 365 Copilot

Key observations from Layer 1:

Identity appears most frequently across Layer 1 risks, reflecting how tightly Copilot access depends on authenticated user permissions and sign-in conditions. Device-related risks also play a major role because unmanaged or non-compliant endpoints can expose Copilot sessions and outputs beyond the organization’s trusted environment.

Together, these risks highlight a central theme: securing Copilot access is not just about controlling who can sign in, but also validating the devices, conditions, and access patterns associated with every session.

Risk layer 2: What data can Microsoft 365 Copilot reach?

The second layer of risk assumes that the user is already authenticated and actively using Copilot.

At this stage, the focus shifts from who can access Copilot to what data Copilot can surface on the user’s behalf.

These risks reflect the full scope of data exposure created by existing permissions, overshared content, connected systems, and governance gaps. Layer 2 risks are governed primarily by the Apps and Data pillar, with Identity playing a secondary role in defining the scope of data each user can access.

For mitigating risks in this layer, you may refer to the blog post: Limiting Microsoft 365 Copilot data exposure risk with Zero Trust apps and data controls.

	Risk	Pillar	Description
R7	Overshared SharePoint and OneDrive content	Apps & Identity	Content shared with "Everyone," "Everyone except external users," or broad groups becomes part of Copilot’s query able surface for any licensed user, even if that user would never have found those files manually. Years of SharePoint oversharing, combined with Copilot’s ability to traverse and synthesize content in a single prompt, can turn long-standing governance debt into immediate exposure. Copilot makes data once hidden by volume, discoverable by intent.
R8	Sensitivity label gaps	Apps & Data	Microsoft Purview sensitivity labels tell Copilot how to handle content, including whether it can summarize, cite, or include that content in responses. Leaving content unlabeled, mislabeling, or miss inheriting labels across containers such as SharePoint sites and Teams, Copilot treats the content as unclassified and may surface it freely. Many enterprise tenants still contain large volumes of unlabeled legacy content, and Copilot cannot infer classification on its own.
R9	Excessive user permissions	Identity & Apps	Like overshared content, Copilot follows each user’s existing Microsoft Graph permissions and does not surface content users cannot access. In many enterprise environments, however, users accumulate access far beyond their current role through leftover project permissions, broad temporary group memberships, and inherited rights from outdated organizational structures. Copilot does not create this overprovisioning, but it makes the full scope of that access immediately visible and usable.
R10	No DLP coverage on Copilot-generated outputs	Apps & Data	Copilot outputs—including summaries, drafts, and synthesized answers—are generated content, and traditional DLP policies do not always preserve links to original source data. Users may receive Copilot responses containing aggregated PII, financial data, or confidential project details and paste that information into emails, Teams messages, or external documents without triggering DLP policies designed to detect the original source files. As content shifts from source material to generated output, organizations often lose the underlying sensitivity context.
R11	Plugin and connector data surface expansion	Apps & Identity	Organizations can extend Microsoft 365 Copilot through plugins and Microsoft Graph connectors that pull external data from CRM systems, ITSM platforms, HR applications, and custom line-of-business tools. Each connector expands the data surface Copilot can query on a user’s behalf and often reaches into systems whose access control models do not align natively with Microsoft 365 permissions. As organizations add connectors, each connected source introduces governance and audit risk that expands alongside the broader Copilot data surface.
R12	Audit and visibility gap	Apps & Data	Organizations need visibility into what users asked Copilot, what data Copilot accessed, , and what responses it generated to maintain an effective security posture for both incident response and risk monitoring. Disabling Copilot interaction logging, retaining audit logs for too short a period, or failing to forward logs to a SIEM, obscures the organization’s visibility into how users interact with Copilot, whether Copilot surfaces unexpected content, and whether activity may indicate compromise. Without audit data, organizations cannot reliably detect misuse or investigate incidents.
R13	Privileged user data amplification	Identity, Apps & Data	Administrators, senior IT staff, and other privileged users often hold access that spans organizational boundaries, including mailboxes, site collections, security groups, and configuration data that most users never access. A compromised admin account with Copilot access gives adversaries an organization-wide view of data that far exceeds the exposure associated with a compromised end-user account. Organizations therefore need to apply the strictest Copilot access governance to privileged identities.

Table – 3: Layer-2 Risks: What data can Microsoft 365 Copilot reach?

Key observations from Layer 2:

Apps-related risks appear throughout Layer 2 because Microsoft 365 Copilot depends heavily on connected systems, accessible data sources, and governance over generated outputs. The Data pillar further emphasizes the need to protect not only sensitive source content but also AI-generated responses that aggregate and surface information across systems.

The table above maps each identified risk to its primary and secondary Zero Trust pillars. Primary pillars represent control areas that most directly govern a given risk, while secondary pillars represent contributing dimensions.

Conclusion & next steps

Copilot typically does not grant broader access than a user already has — it makes existing access easier to discover, connect, and use across Microsoft 365. Organizations that successfully scale Copilot are the ones that understand and govern that access first.

Reducing Copilot data exposure is not a one-time cleanup; it is a continuous governance posture. Oversharing accumulates, labels drift, permissions grow, and connectors are added. Together, the Layer 1 and Layer 2 controls in this guide create the feedback loops that keep the risk surface governed as the organization and its use of Copilot evolve — governing not only who can access the service, but what it can reach on their behalf.

WHERE TO GO NEXT

Assess your current posture: Zero Trust Workshop — http://zerotrust.microsoft.com
Understand the framework: Zero Trust Overview on Microsoft Learn (http://learn.microsoft.com/security/zero-trust)

New in Microsoft Marketplace: offers published June 23-24, 2026

Nikhil_Viswanathan — Thu, 23 Jul 2026 13:42:11 GMT

Learn about 221 new offers that went live in Microsoft Marketplace, a single destination to find, try, and buy cloud solutions, AI apps, and agents to meet your business needs.

Get it now in our marketplace
	Mashu Server: Mashu is a SaaS data catalog that automatically collects and integrates metadata from distributed systems like data lakes and warehouses. It centralizes metadata management, enabling quick data discovery and use; supports easy, low-risk implementation; offers pay-as-you-go pricing; and improves data access, collaboration, and governance for data-driven decisions.
	Ackomas Koa Cloud: Ackomas is a SaaS platform for medical device regulatory data governance, offering centralized data management, automated submissions, and global database connectivity. It supports multi-entity workflows, integrates with IT systems, enhances data reliability, and helps anticipate regulatory changes, enabling scalable, efficient access to international markets.
	Advanced Threat Hunting Agent by Inspira: This autonomous threat hunting agent for Microsoft Sentinel and Microsoft Defender XDR detects suspicious activity, correlates data, reconstructs attacks, adds threat intelligence, and provides actionable insights. Outputs include executive summary, findings, entity analysis, MITRE ATT&CK mapping, attack timeline, evidence, recommendations, and a final verdict.
	Aegis Capital Forecasting: Aegis Capital Forecasting is an earned value management extension for Microsoft Dynamics 365 Business Central, enabling real-time cost control, budget tracking, and automated forecasting for capital projects. It offers WBS hierarchy, AFE spending gates, and progress measurement and eliminates the need for spreadsheets and costly platform changes.
	AI Incident Investigation Agent by Inspira: Autonomous AI agent for Microsoft Sentinel and Microsoft Defender XDR conducts deep incident investigations, correlating alerts, entities, and threat intelligence. It reconstructs attack timelines, identifies root causes, maps MITRE ATT&CK techniques, and provides evidence-based reports with actionable recommendations, enhancing SOC analyst efficiency and accelerating incident response.
	Apache Superset on Azure Kubernetes Service: Apache Superset is an Apache 2.0 licensed data exploration and visualization platform deployed on Azure Kubernetes Service using the official ASF Helm chart. It features Celery async query execution, Valkey cache backend, PostgreSQL metadata database, and PVC storage.
	API Management Backup by UDX: API Management Backup by UDX offers automated backup, efficient restore, and disaster recovery for API instances. It ensures high availability, security, compliance, and scalability with an easy-to-use interface. This solution enhances resilience, operational efficiency, and cost-effectiveness, safeguarding API services against data loss and downtime for business continuity.
	Bizagi - NORAM: Bizagi is a low-code process automation platform offering rapid solution delivery, business agility, and governance. It integrates seamlessly with Microsoft Azure, supports AI-powered features like Ask Ada, and serves citizen to pro developers. Bizagi’s scalable, usage-based pricing and expert services drive enterprise-wide automation and efficiency.
	Bolt Intelligence: Bolt Intelligence is an AI-native consumer insight platform combining qualitative research, quantitative research, UX testing, and social listening. It delivers fast, decision-ready findings with expert oversight, saving time and reducing costs. Trusted by top global brands, it offers advanced tools like AI-moderated interviews, emotion analysis, and dynamic personas for enterprise teams.
	CellTrust SL2 for Verizon Carrier Capture: CellTrust’s Carrier Capture enables compliant text message archiving on corporate-owned devices without extra apps. It captures SMS/MMS directly via carriers, preserving native format and attachments. The self-service portal offers easy deployment, policy control, and monitoring, supporting COBO strategies for secure, business-only device use and seamless compliance.
	Climavision Horizon AI Point Weather Model: Horizon AI Point by Climavision offers precise, site-specific weather forecasts up to 15 days ahead using AI and proprietary radar data. It supports energy traders, utilities, renewable operators, and others by delivering localized, high-resolution forecasts to optimize operations, reduce risk, and improve weather-driven decision-making.
	CostGuard: CostGuard is a cost management tool for SaaS teams using Azure. It provides clear insights into cloud spending, tracks trends, identifies top cost drivers, offers optimization recommendations, and forecasts future costs. Designed for startups and DevOps, it enables proactive Azure cost control through a user-friendly, multi-tenant workspace.
	CS SSCC Management: CS SSCC Management adds GS1-compliant unique identification numbers to packages, enhancing traceability and efficiency in supply chains. It supports various package types, integrates with external devices via API, and complies with global standards. Compatible with Dynamics 365 Business Central, it streamlines logistics for retail and other industries worldwide.
	Cyber Quantified: Cyber Quantified is a cyber risk modeling tool that predicts financial impacts of cyber threats, helping organizations optimize risk management and insurance coverage. Designed for risk professionals, it enhances collaboration between security and risk teams, providing clarity, transparency, and improved resilience against evolving cyber risks.
	Document Intelligence – Automate Document Processing: Document Intelligence uses AI, OCR, NLP, and machine learning to automate document processing, extracting and validating data from emails, PDFs, invoices, and more. It integrates with ERP systems, speeds workflows from minutes to seconds, reduces manual entry errors, lowers costs, and enhances productivity, supporting digital transformation and efficient business operations.
	Ensure PosturePass Compliance Verification System: PosturePass extends Microsoft Entra Conditional Access to external devices without changing Microsoft Entra ID setup. It installs quickly, verifies device compliance, and integrates natively, securing unmanaged contractor devices. No VPN, MDM, or IT help is needed. The solution ensures privacy, fast deployment, and seamless control for Microsoft 365 environments with external users.
	Ensure PosturePass Proof of Concept for 25 Users: PosturePass extends Microsoft Entra Conditional Access to external devices without changing Microsoft Entra ID setup. It installs quickly, verifies device compliance, and integrates natively, securing unmanaged contractor devices. No VPN, MDM, or IT help is needed. The solution ensures privacy, supports Windows/macOS, and works seamlessly with Microsoft 365 environments.
	Everfox Data Guard Bundle: Everfox Data Guard is a defense-grade, high-assurance software solution for securely transferring and controlling data between physically separated networks. It ensures robust data protection without hardware, providing a reliable method to maintain data security across isolated systems.
	EverShield Insider Risk Case Manager: EverShield Insider Risk Case Manager is a secure, centralized platform for managing evidence and documentation. It features in-app messaging and workflows to enhance team collaboration, enabling faster case handling. The tool offers operational and strategic metrics to monitor caseloads, assess organizational risk, and address critical inquiries efficiently.
	EverShield User Activity Monitoring: Everfox EverShield User Activity Monitoring helps security analysts and investigators by gathering behavioral data from various endpoints, providing comprehensive context of user activities for enhanced monitoring and analysis.
	EverShield User Entity Behavioral Analytics: Everfox's Activity Insights dashboard enhances security teams' efficiency by integrating with EverShield User Activity Monitoring's Investigation Workbench. It streamlines workflows, helping prioritize and investigate risky user activities for improved security management.
	Gaia - Agentic AI Application Platform: Gaia is an enterprise platform for designing, operating, and governing AI agents and applications. It integrates agent design, runtime orchestration, risk controls, evaluation, and governance in one system. Gaia supports multicloud environments, ensures auditability, and helps organizations scale AI from pilots to governed, mission-critical deployments.
	Global Payroll and HR: Deel simplifies global hiring by managing payroll, compliance, benefits, and immigration in more than 150 countries without needing local entities. The solution offers a unified platform for onboarding, performance, and IT management to confidently scale remote teams worldwide.
	Gravity - The Autonomous Healthcare Platform: Gravity is an AI-powered healthcare platform that unifies data from multiple sources into a secure, cloud-agnostic system. It enables low-code AI application development, automates workflows, and offers healthcare-specific AI models. Gravity enhances collaboration, ensures compliance, and delivers rapid insights to improve patient outcomes and operational efficiency.
	Humanix: Humanix uses conversational AI to detect and respond to social engineering attacks targeting enterprise help desks and identity workflows. It analyzes voice, chat, and email interactions in real time, identifying manipulation, impersonation, and procedure violations. Humanix integrates with platforms like Microsoft 365 and ServiceNow for proactive security and compliance.
	Identity Threat Analyst Agent by Inspira: This autonomous agent for Microsoft Entra ID investigates identity threats by analyzing risk events, sign-in anomalies, privilege exposure, MFA/token abuse, and Microsoft Entra Conditional Access gaps. It provides evidence-based analysis with MITRE ATT&CK mapping, risk assessments, prioritized remediation guidance, and a comprehensive final verdict for enhanced security management.
	Incident Intelligence Reporting Agent: This autonomous agent for Microsoft Sentinel and Microsoft Defender XDR incidents automates deep investigations, retrieving metadata, alerts, threat intelligence, and attack timelines. It generates detailed reports with MITRE ATT&CK mapping, root cause analysis, risk scoring, and remediation guidance, providing downloadable HTML, PDF, and Microsoft Word outputs for SOC teams and management.
	LEX Risk Management Coach: Lockbase Exposure Agent (LEX) identifies and prioritizes pre-breach risks across Microsoft Entra ID, Active Directory, and Azure. It analyzes telemetry and configuration data to reveal exploitable escalation paths, vulnerabilities, and exposure, providing CISOs with actionable, prioritized risk findings to reduce attack surfaces before exploitation occurs.
	NeuralData Synthesis Hub: NeuralData Synthesis Hub is an advanced AI-driven platform that integrates and analyzes data using neural networks. It enhances data processing and provides real-time insights, making it ideal for businesses needing intelligent data synthesis and improved decision-making capabilities.
	NeuralNet Integrator: NeuralNet Integrator is an advanced AI platform for seamless integration and deployment of neural network models. It offers robust tools for developing, training, and managing networks, ensuring optimal performance and scalability across various applications.
	Panzura Nexus: Panzura Nexus is an enterprise AI platform that securely integrates unstructured file data with Microsoft 365 Copilot. It enables real-time, permission-aware access to file content without data migration, enhancing productivity and insights for industries like AEC and manufacturing. The extensible platform supports future AI integrations while preserving security and governance.
	Polarion X Italy: Polarion is a browser-based application lifecycle management tool for teams of any size. It enables unified definition, building, testing, and management of software with end-to-end traceability, agile support, secure collaboration, granular permissions, and workflow automation, enhancing productivity and compliance across distributed teams.
	QuantumPulse Analyzer: This solution uses AutoML to analyze real-time data streams, helping businesses gain timely insights and make informed decisions. The service offers efficient, automated data handling and analysis, enhancing operational agility and supporting data-driven strategies.
	Quest Data Modeler: Quest Data Modeler is a cloud-native SaaS platform enabling AI-assisted, collaborative data modeling with enterprise governance. It ensures consistent data definitions across teams and tools, supports full-stack modeling, integrates with major cloud platforms, and bridges legacy and modern workflows—accelerating delivery, enhancing trust, and aligning business meaning with technical data.
	Reality Capture: Reality Capture embeds 360-degree panoramas into Microsoft Power BI, offering a street-view interface for site monitoring and spatial data tracking. It includes tools for project progress comparison.
	RESET – Microsoft 365 Digital Skills and Enablement Platform: RESET is a self-service digital learning platform offering more than 5,000 task-based videos on Microsoft 365, AI, and Microsoft 365 Copilot. It supports role-based, multilingual, and self-paced learning with tracking, gamification, and SSO integration, helping individuals and organizations improve digital skills, productivity, and technology adoption efficiently.
	Risk Intelligence Executive Narrator by Inspira: This autonomous risk intelligence agent for Microsoft Sentinel and Microsoft Defender XDR incidents converts technical data into clear business narratives, risk summaries, impact assessments, and stakeholder communications. It supports executive leadership, SOC, IT, and compliance teams by generating tailored email drafts based on incident IDs, enhancing security response efficiency.
	Risk IQ Suite: Risk IQ enhances transparency, efficiency, and resilience by offering advanced risk modeling across the spectrum. It enables clients to independently measure and model risk outcomes or collaborate with experts. This modern, connected platform optimizes total risk and insurance programs, moving beyond spreadsheets for smarter risk management.
	Schedule Pro: Schedule Pro integrates with Power BI to visualize Primavera P6 and Microsoft Project schedules. It offers interactive Gantt charts, S-Curves, EVM dashboards, risk analysis, and baseline comparisons. Features include customizable themes, multi-project support, and privacy-focused local processing.
	SDM Gradient Heatmap: SDM Gradient Heatmap creates smooth, continuous color surfaces from sparse XY points using interpolation algorithms. Features include customizable color presets, isolines, sample markers, category labels, axes, legends, cross-filtering, and rich tooltips. The solution is ideal for spatial analysis, scientific visualization, and enterprise dashboards requiring continuous data surfaces.
	Swiss fastOnboarding API: Swiss fastOnboarding API offers fast, accurate Swiss company and address data validation with daily updates from the Swiss Commercial Register. It reduces manual entry, prevents errors, and enhances onboarding for banking, CRM, ERP, and more. Usage-based billing enables cost-effective integration into digital applications and business processes.
	TextMine: TextMine is a context layer for enterprise agents that enhances data analysis by providing advanced contextual insights. It integrates seamlessly with existing systems, helping businesses improve decision-making and operational efficiency. Ideal for handling complex datasets, TextMine enables precise, actionable results, boosting competitiveness in data-driven environments.
	Upstage Studio: Upstage Studio is a no-code platform for building document agents that manage complex workflows using multiple AI models. It supports various document formats; ensures repeatability, verifiability, and human oversight; and allows integration of your language models for precise data extraction and classification without technical expertise.
	VERSO KitBridge – Lab Kit Orchestration Platform: VERSO KitBridge bridges the gap between LIMS and logistics for healthcare testing programs. It standardizes kit assembly and offers real-time tracking, AI-driven analytics, blockchain compliance, and multi-site coordination. Designed for CROs, specialty labs, and home testing, it boosts efficiency, reduces errors, and ensures scalable, compliant operations.
Easily deploy virtual machine images
	Apache Accumulo on Ubuntu 26.04 LTS Apache Arrow on Ubuntu 26.04 LTS Apache Avro on Ubuntu 26.04 LTS Apache Beam on Ubuntu 26.04 LTS DuckDB v1.5.4 on Debian 13 FusionPBX v5.5 on Debian 13 HAProxy on Debian 13 HAProxy v3.4.0 on Ubuntu 26.04 LTS Mosquitto MQTT v2.1.2 on Ubuntu 26.04 LTS PyArrow on Ubuntu 26.04 LTS Quay Container Registry on Ubuntu 26.04 LTS WireGuard v1.0.2 on Debian 13
	Database for PostgreSQL 16 on Enterprise Linux 10 Database for PostgreSQL 16 on Linux Stream 9 Database for PostgreSQL 17 on Enterprise Linux 10 Database for PostgreSQL 17 on Linux Stream 9 Database for PostgreSQL 18 Based on Red Hat Enterprise Linux 9 Database for PostgreSQL 18 on Linux Stream 10 Database for PostgreSQL 18 on Linux Stream 9 Linux Stream 9 VM for PyTorch Workloads with NVIDIA CUDA GPU Support
	Airflow Bob Coaster CMS CouchDB Elgg Evolution CMS Laravel NocoDB Prestashop Prometheus-Grafana Red5 Redmine SQLite Wagtail
	AnythingLLM on Ubuntu 24.04 LTS Bun on Ubuntu 24.04 LTS Concrete CMS on Ubuntu 24.04 LTS CrowdSec on Ubuntu 24.04 LTS FerretDB on Ubuntu 24.04 LTS KrakenD API Gateway on Ubuntu 24.04 LocalAI on Ubuntu 24.04 LTS Reposilite on Ubuntu 24.04 LTS Traefik Proxy on Ubuntu 24.04 LTS Trivy on Ubuntu 24.04 LTS Umami on Ubuntu 24.04 LTS Verdaccio on Ubuntu 24.04 LTS Vikunja on Ubuntu 24.04 LTS
	Alvanit Keycloak - Magic Link and SCIM
	Amnezia VPN Supported and Secured by the Hossted Platform
	Ajenti BigTree CMS Dolibarr Gibbon LMS Go (Golang) InstantCMS oAuthlib OXID eShop Piwigo WonderCMS Zenario
	Grafana + Prometheus - Hardened Observability Stack
	Red Hat Enterprise Linux 9.2
	Billing Lago Cilium Proxy FlatPress Parse Server PyTorch Rust Stitching Tools
	VM for Windows Server
	VM with Ubuntu 26.04 LTS Minimal Wiki Engine (Wiki.js-based) on Ubuntu 26.04 LTS
	Calls VoIP Server on Debian 12 LTS Linux Stream 9 VM with VPN Server (WireGuard Protocol) SoftEther VPN for Windows Server 2022 Datacenter
Go further with workshops, proofs of concept, and implementations
	Agent Factory - Explore, Build, Govern, Secure, and Scale Agents: Vivicta's Agent Factory helps organizations implement Microsoft Copilot Agents through three models: kickstart for pilot projects, advisory for building internal skills, and delivery for full lifecycle management. It accelerates value, ensures governance, and offers flexible, expert-led services tailored to organizational maturity and needs.
	AI Customer Service Agent - Retail Accelerator: Nexer’s AI Customer Service Agent enhances customer service by integrating with existing platforms like Dynamics 365. It provides real-time guidance, suggested responses, and customer data to improve case handling, reduce errors, and boost agent confidence. Quick to deploy, it delivers measurable benefits from day one, helping teams during peak times and onboarding.
	AI Store Assistant: Nexer’s AI Store Assistant integrates with existing platforms to enhance Dynamics 365 Sales usage. It provides store teams instant access to product details, stock, and customer context, enabling faster service, cross-selling, upselling, and efficient handling of sales and returns to boost sales and improve customer experience.
	Assessment and Upgrade to Dynamics 365 Business Central: LITS Services offers a comprehensive offering to assess and upgrade your ERP system to Dynamics 365 Business Central. It evaluates compatibility, customization, and data migration needs, ensuring a smooth transition. This upgrade enhances operational efficiency and leverages new features, minimizing business disruption during modernization.
	Azure Cloud Migration and Managed Services: Manao Software specializes in Azure services, offering cloud migration, architecture, cost optimization, and managed operations. Certified experts ensure secure, compliant, and efficient solutions tailored for businesses using Microsoft technologies. Founded in 2007, they serve Nordic and Thai enterprises, providing practical, results-focused cloud modernization and support.
	Azure Migration and Modernization: Logic V offers a comprehensive Azure Migration and Modernization service, transitioning organizations from legacy systems to scalable, secure Azure environments. They assess infrastructure, plan and execute migrations, and optimize performance, cost, and governance. This engagement is ideal for modernizing applications, consolidating datacenters, and enabling cloud-native growth and innovation.
	Azure Storage and Secure Data Management Implementation: Logic V's Azure Storage service includes designing and deploying secure, scalable solutions using Azure Blob Storage, Azure Data Lake Storage, and others. They ensure controlled access, data protection, lifecycle management, and cost optimization, integrating with Azure services for backup, disaster recovery, and automation.
	Business Continuity and Disaster Recovery on Azure: Diyar United's Azure-based Business Continuity and Disaster Recovery service includes risk assessment, design, implementation, testing, and documentation. Using Azure Site Recovery and Azure Backup, this service protects critical workloads across environments, ensuring fast recovery, monitoring, and operational readiness.
	Capgemini Sovereign: Data Protection and Cyber Defense: Capgemini will deploy Microsoft Sovereign Key Management and Data Protection to secure sensitive data across Microsoft 365, Azure, SaaS, and hybrid environments. It offers data discovery, classification, encryption, key management, and monitoring, reducing risks like data loss and ransomware. Ideal for regulated enterprises, it ensures compliance, control, and audit readiness with scalable, integrated Microsoft security solutions.
	Capgemini Sovereign: Microsoft Sovereign Resilience: Sovereign Resilience by Capgemini ensures critical workloads remain operational, compliant, and controlled amid regulatory or geopolitical constraints. It offers tailored strategies, multicloud architecture, identity continuity, and tested playbooks for lawful business continuity, making it ideal for regulated enterprises needing secure, resilient AI, data, and SaaS operations under evolving sovereignty conditions.
	CPS AgentOps Agent Factory: CPS AgentOps is a managed service that helps organizations govern, scale, and optimize Microsoft AI agents like Microsoft 365 Copilot. It provides governance, lifecycle management, support, and continuous improvement to accelerate AI adoption, reduce risks, and maximize business value across industries, enabling scalable, secure, and measurable AI deployments.
	CPS HR Agent – AI-Powered HR Support for Microsoft 365: The CPS HR Agent automates HR queries within Microsoft 365, providing instant, policy-compliant answers. It reduces HR workload, improves employee experience, ensures compliance, and offers analytics for better HR processes. Customizable and secure, it streamlines HR service delivery and supports strategic workforce initiatives.
	CPS Recruitment CV Sifting Agent: The Recruitment CV Sifting Agent by CPS automates high-volume CV screening using Microsoft Copilot Studio, reducing screening time from days to minutes. It delivers unbiased, data-driven candidate rankings, saves money, improves recruiter focus, and enhances hiring efficiency.
	Data Protection Envisioning Workshop: Telekom Deutschland's Data Protection Envisioning Workshop analyzes security and compliance risks in Microsoft 365, identifies sensitive data and insider threats, assesses the environment, develops measures with Microsoft Purview, and demonstrates solutions in a practical way. The target group is IT and security managers who want to improve governance, compliance, and AI security.
	Dynamics 365 Business Central Spain Localization: Awara IT's service configures Dynamics 365 Business Central for Spain, enabling local VAT reporting, electronic invoicing (FacturaE), and compliance with Spanish tax laws. It offers setup, training, and support for faster rollout, reducing manual finance tasks and ensuring smooth operations aligned with local requirements.
	ERP JumpStart Guided Service: ERP JumpStart Guided Service by Naviona offers small businesses a faster, lower-risk Dynamics 365 Business Central setup with expert support. It includes workshops, hands-on sessions, and 12 expert reviews, enabling quick go-live, reduced manual work with Microsoft Copilot, and scalable ERP tailored for growth.
	ERP JumpStart Self-Service: ERP JumpStart Self-Service by Naviona offers small businesses a fast, ready-to-run Dynamics 365 Business Central ERP solution. It features guided self-setup with expert support, built-in training, and Microsoft Copilot integration. Designed for quick implementation, it replaces complex projects with a scalable, best-practice system to streamline operations and growth.
	Dynamics 365 Finance Implementation: Folio3 implements Microsoft Dynamics 365 Finance for fast, AI-driven financial close. It supports multi-entity, multi-currency consolidation, budgeting, and audit-ready reporting with Microsoft Copilot and AI agents. Integrated with Azure and Power BI, it ensures real-time analytics, lower costs, and global compliance from day one.
	Get Agent Ready with Microsoft Agent 365: Increment's Get Agent Ready with Microsoft Agent 365 helps organizations adopt AI agents securely and effectively. It addresses challenges like lack of AI strategy, governance gaps, undefined operating models, data security risks, licensing complexities, and agent sprawl, ensuring a scalable, compliant, and cost-efficient AI deployment.
	Integration Operations Hub: Centralized Monitoring and Recovery for Azure Integrations: Accigo's Integration Operations Hub centralizes Azure integration monitoring and recovery, reducing mean time to recovery and operational effort. It offers unified dashboards, automated telemetry ingestion, dead-letter queue management, and proactive alerts. Secure and scalable, it empowers support teams to resolve incidents without deep Azure expertise, improving reliability and SLA performance.
	Intelligent Contact Center Platform: IBM's Intelligent Contact Center Platform uses AI to enhance customer service by supporting live agents, automating tasks, and providing real-time guidance. Built on Azure, it improves efficiency, reduces handle time, and integrates with existing systems, enabling scalable, consistent, and high-quality support for modern contact centers.
	Inventory and Demand Intelligence Agent: Nexer’s Inventory and Demand Intelligence Agent integrates demand signals and supply data with Dynamics 365, enabling proactive identification of demand shifts, replenishment risks, and sales opportunities. It helps retail teams make data-driven decisions, improving responsiveness across stores, e-commerce, and suppliers while optimizing inventory and sourcing strategies.
	Jasco Copilot Advantage: Microsoft 365 Copilot Adoption Program: The Jasco Copilot Advantage ensures secure, effective Microsoft 365 Copilot adoption. It offers role-based training, change management, and continuous consulting to embed Copilot into workflows, delivering measurable productivity gains, strong AI governance, and a scalable adoption model for Australian organizations.
	LTM Data and AI DeepCure: LTIMindtree's DeepCure AI, built on Azure, accelerates drug discovery by automating literature review, molecular screening, and analysis using AI agents and domain-specific data. It reduces research time, improves candidate selection, lowers manual effort, and integrates decision intelligence for faster, data-driven biomedical research workflows.
	Manufacturing for Dynamics 365: Folio3 enhances Dynamics 365 for manufacturers by unifying production, inventory, and finance in one system. Their solution offers real-time data, integrates via Burq iPaaS, and supports discrete and process manufacturing. Benefits include faster delivery, lower integration risk, scalable cloud deployment, and audit-ready financials.
	Microsoft 365 Copilot Deployment: Cloud Direct's service ensures secure, governed deployment of Microsoft 365 Copilot aligned with business priorities. It includes readiness assessment, phased rollout, compliance controls, and detailed documentation, enabling controlled AI adoption, improved productivity, reduced risk, and scalable implementation for responsible, efficient use of Microsoft 365 Copilot.
	Microsoft 365 Copilot Starter Workshop: Aveniq offers a workshop on Microsoft 365 Copilot, providing an overview, practical industry-specific use cases, and strategic rollout planning. Participants gain a clear understanding of the capabilities and limitations of Microsoft 365 Copilot. The workshop concludes with documented results, delivering a structured decision-making guide for successful implementation.
	Microsoft Copilot Studio - Agent Builder: Aveniq offers tailored Microsoft Copilot Studio agent development, starting with process evaluation and security assessment for safe AI use. It includes detailed design, integration, and documentation, followed by deployment as a proof of concept or full solution. Ongoing support ensures stable operation, monitoring, and continuous optimization for business needs.
	Microsoft Entra - Global Secure Access Engagement: Signal Alliance Consulting enhances Microsoft 365 security with zero trust network access via Global Secure Access. They offer risk assessments, vulnerability audits, optimized traffic routing, and seamless VPN-less access. Their expert team provides tailored deployment, pilot testing, and training to secure remote workforces and protect cloud assets effectively.
	Nebulan Commercial Proposal Agent: Nebulan's service automates the creation of business proposals using AI integrated into Microsoft 365 Copilot to reduce errors and improve the quality and consistency of documents. It supports multiple languages; integrates with CRM systems; and optimizes B2B sales teams, consultancies and agencies with templates and custom configurations.
	SCC Cloud Security Pathfinder: SCC’s Cloud Security Pathfinder engagement will assess and enhance your Azure security posture. Leveraging Microsoft Defender tools, it identifies risks, misconfigurations, and vulnerabilities across hybrid and multi-cloud environments, providing tailored recommendations and a clear roadmap to strengthen cloud security and compliance effectively.
	Secure Microsoft 365 Copilot Engagements: Increment's Secure Microsoft 365 Copilot Engagements help organizations safely adopt Microsoft 365 Copilot and AI by addressing data security, governance, and sensitive information risks. They offer two paths: a five-week Readiness Assessment for strategic planning and a six-week Accelerated Controls service for rapid implementation of security measures and AI usage controls.
	Threat Protection Envisioning Workshop: Telekom Deutschland's Threat Protection Envisioning Workshop helps organizations detect, prioritize, and remediate threats across Microsoft cloud and on-premises environments. With Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Entra ID Protection, it provides visibility, actionable insights, prioritized recommendations, and a roadmap for modern security architectures.
	Transforma 365 - Strategic Adoption of Microsoft 365 and Copilot: Transforma 365 is an end-to-end service that drives strategic adoption of Microsoft 365 and Microsoft Copilot, improving productivity, collaboration, and automation. It offers continuous diagnostics, strategy, implementation, training, and measurement, helping organizations maximize technological value and move toward a work culture based on data and artificial intelligence.
	TTEC Digital CortentaCX: CortentaCX by TTEC Digital is an AI-powered Open CX platform that enhances customer experience by integrating with existing systems. Built on Azure, it offers unified intelligence, omnichannel support, and data privacy. It reduces costs, technical debt, and vendor dependency while providing scalable, customizable customer service solutions.
	Vibe Coding, Delivered Securely - From Idea to Azure in an Afternoon: Accigo’s Internal Developer Platform integrates GitHub Enterprise and Azure, enabling AI-assisted app development with automated security, testing, and deployment. It offers preconfigured templates, built-in authentication, secrets management, and full observability. This platform accelerates secure, production-ready app delivery, reduces operational costs, and ensures consistent quality and governance.

Contact our partners

AL Processing Charge

App Store for Microsoft Intune

Aryson OLM to CSV Migrator

Aryson Zoho to Office 365 Migration Tool

aSa Studio 26

Auto Add Item Lines

AXIO Intercompany Transactions Agent

Azure Migration Readiness Assessment

BanIA - From Chatbot to Intelligent Companion

BI Modernization on Microsoft Fabric: 1-Hour Readiness Assessment

BitRecover EML Attachment Extractor Tool

BitRecover IncrediMail to Outlook PST Converter Tool

BitRecover IncrediMail to PDF Converter Tool

BlueVoyant Anthropic Claude Compliance

BMD Interface

CapuWare Event Manager

Cigati GoDaddy to Gmail Migration Tool

Cigati GoDaddy to Zoho Mail Migration

Cigati HostGator to Office 365 Migration Tool

Cigati IMAP to Google Workspace Migration Tool

Compliance Sentinel

Continia Document Capture - French e-Invoicing

Continia Document Output - French e-Invoicing

Customer Aging Dashboard

DataNova Managed Services

DRS Softech OST to IMAP Migration Tool

DRS Softech OST to Thunderbird Converter

Eleiris

Fanarex - ERP for GCC Cleaning Companies

Finifi AI for Order-to-Cash

FPE Index

Fusion5 Business Hub

Fusion5 Business Hub for Australia/New Zealand

GCC High Licensing: 1-Day Enablement

GCDocs to SharePoint Online Migration Assessment and Roadmap

Insource Services - Azure Managed Services

Intility Landing Zone

Intranet Modernization with Microsoft 365: 1-Hour Briefing

License Manager

LITS Equipment Rental System

LOOKie Close as Invoice

MacSonik Apple Mail Converter Tool

MacSonik Gmail to Google Workspace Migration for Mac

Key Vault Link

NITRO Help Desk for IT

Nordcloud's Managed Service for Azure Local

Nordcloud's Managed Service for Microsoft Entra ID

Onplana Migration Tool for Microsoft Project

Powerblox Advanced Project Administration

RecoveryTools for Zimbra to PST Converter Tool

RecoveryTools for Zimbra to Zoho Mail Converter Tool

Regulate365: Casework

Regulate365: Inspections

Regulate365: Payments

Regulate365: Registrations

RidgeEstates 365 Property Lease Management

Risk, Compliance & Data Security Assessment

rocket365 ALSO Marketplace

tialto

VOSS Automation and Analytics for Microsoft Teams Rooms

Vulnerability Assessment & Penetration Test

Wiboo CPQ for Microsoft Dynamics 365

XINU Press

XPR365 Rest API Client

ZeroFox Threat Intelligence Connector

ZeroHack TRACE Sensor

This content was generated by Microsoft Azure OpenAI, then revised by human editors.

Should You Use the New Microsoft Entra Tenant Governance or Azure Lighthouse? (part 3 of 3)

Preston_Romney — Thu, 23 Jul 2026 12:00:00 GMT

In Part 1 we built Azure Lighthouse the technical way. In Part 2, "Bring Your Partner In, Without Letting Their Identities In," we made the security case for it: let a service provider operate a customer's Azure resources without creating any identity in the customer's tenant.

This third part introduces another, newly available delegation model Microsoft Entra Tenant Governance and helps you to answer the question: which one do I use, and when?. If you already know Lighthouse, you have everything you need to follow along - If not, catch up on the previous two articles. While most of the focus will be on Microsoft Entra Tenant Governance, we will compare and contrast it with Azure Lighthouse.

There's one idea that makes the whole comparison click: the two models project access in opposite directions.

1. Azure Lighthouse, and its boundary

As a brief refresher, Azure Lighthouse lets a service provider manage a customer's Azure resources (subscriptions and resource groups) from the provider's own tenant. The provider's users never get an account in the customer's directory and never become guests there; instead, the customer's subscriptions and resource groups are delegated to the provider through Azure Resource Manager, and the provider operates them with their home credentials (Azure Lighthouse architecture). No identity sprawl, no extra license, no charge (Azure Lighthouse overview).

Lighthouse is scoped to the Azure Resource Manager control plane. It delegates resources from subscriptions or resource groups such as virtual machines, storage, networking, policy, and Sentinel workspaces. It does not grant Microsoft Entra directory roles, it does not reach resource data planes such as Storage blob data or Key Vault secrets, and it doesn't reach Microsoft 365 (cross-tenant management experience).

But it leaves a real question open. What happens when the partner (or an enterprise with multiple tenants) legitimately needs access to the directory, to read identity configuration, run security operations, administer users, or govern identities, and not just the resource estate? Lighthouse, by design, can't take you there. That's the gap the second model fills.

2. Two directions of projection

The easiest way to keep the two models straight is to consider the following:

Fig 1 - Access delegation direction of trust

Azure Lighthouse projects the customer's resources up into the provider's tenant. The provider manages those resources from its own context. The customer's subscription is, in effect, presented inside the provider's Azure portal.
Microsoft Entra Tenant Governance projects the provider's identity down into the customer's tenant. A principal from the provider tenant becomes usable inside the customer, and a provider user or service principal uses it there to do the work.

Each delegate cross-tenant access without local accounts, but the thing that moves is opposite. And who moves strongly shapes whose rules apply. When the customer's resources come up to the provider, the work happens in the provider's context. When the provider's identity goes down to the customer, the work happens in the customer's context.

Think of the word "projection" as a way to reason about trust direction, not a literal claim that objects are copied between tenants. Lighthouse is delegated management from the provider's context; Tenant Governance creates a governed principal in the customer's context that can hold directory roles and Azure RBAC.

3. What is Microsoft Entra Tenant Governance?

Microsoft Entra Tenant Governance is the capability that lets one tenant securely administer another. The connection between a specific pair of tenants is called a governance relationship: a directional link in which one tenant, the governing tenant (the provider), administers another, the governed tenant (the customer) (set up a governance relationship).

Throughout, this article is written from the provider's vantage point: when it says you, it means the provider (governing) side, and the other tenant is always referred to explicitly as the customer. The topics discussed here apply equally to Enterprises needing to manage many of their own tenants as well as Service Providers who manage many customer tenants.

You set it up in two steps:

A policy template in the provider tenant that declares which principal will be projected and which Entra roles it should receive. Note that RBAC assignments are not part of the governance relationship and must be completed by the customer in their tenant.
A handshake between the two tenants that establishes the trust boundary and provisions the access.

Now let’s dive into the details: what gets projected, and how it gets its powers.

4. What actually gets projected: one proxy principal

In the provider tenant you start with something completely ordinary, a security group (say, your "Cloud Operators" group), or a custom multitenant application. When you form the governance relationship, a proxy of that principal is created in the customer tenant:

A security group is projected in as a remote tenant group.
An application (a custom multitenant app) is projected in as a service principal, when the relationship is established, Tenant Governance automatically creates a service principal with the same permissions in the customer tenant (no manual step on the customer's side): "Tenant Governance creates a service principal with the same permissions in the governed tenant" (governance policy templates).

Using a multitenant app registration with Tenant Governance requires an Entra ID Governance license.

Fig 2 - Provider principal is projected into the customer tenant

It’s important to keep two things straight, neither is a local account or a guest:

The proxy, the remote tenant group (or, for an app, the service principal), is a new principal created in the customer tenant by the relationship. It is not a copy of the provider's group, not a local group created in the customer, and not a guest. It exists only because the relationship projects it, and it is what the provider grants roles to.
The people and apps that use it, the provider's users and service principals, stay in the provider tenant. They never receive a member account or a guest invitation in the customer; they reach the customer through the proxy.

Here is what that provider user or service principal is and isn't, from the customer's point of view:

The provider user or service principal is NOT…	…it IS…
A local member account created in the customer's directory	An identity that stays in the provider tenant and authenticates with provider credentials
A B2B guest invited into the customer	Reachable only through the projected proxy, a signed-in user shows in the customer's logs as the provider tenant's name + Technician (e.g. Contoso Technician)
A standing, permanent object listed among the customer's users	Present only as a governed session or principal, scoped by the relationship and revocable by the customer

To work in the customer tenant, a provider user opens a supported admin portal (Entra or Azure) and appends the customer's tenant ID, for example https://entra.microsoft.com/{customer-tenant-id}, then signs in with their provider-tenant credentials. The customer's logs then show them a directory display name of user_{object-id} (the provider object ID without dashes), and, in sign-in and audit logs, the provider tenant's name followed by Technician, so for a provider tenant named Contoso the entry reads Contoso Technician (use cross-tenant delegated administration). No local account, no guest object, the resource-plane property Lighthouse provides, now on the directory plane (cross-tenant delegated administration).

A note on the two projection mechanics, because they differ in a way worth understanding. A group projects as a remote tenant group, a cross-tenant reference back to the provider's group, with no new local membership stored in the customer. An application projects as a real service principal that is actually created in the customer with the consented permissions. Same idea, a governed proxy of a provider principal, but a group is a reference, while an app is an instantiated object.

5. How the proxy gets its powers: roles attach to the one principal

The proxy is one principal. You don't create separate identities for "directory access" and "resource access." Instead, you grant roles to that single proxy, and the roles can come from two different planes:

Directory roles govern the customer's Microsoft Entra directory. Think of well-known ones such as Global Reader (read-only across the directory), Global Administrator, or User Administrator, selected as built-in roles in the policy template (governance policy templates).
Azure RBAC roles govern the customer's Azure resources. Think of the familiar Reader, Contributor, or a service-specific roles like Virtual Machine Contributor, assigned to the remote tenant group at a subscription or resource-group scope. This is not done as part of the governance relationship as the Entra directory role is. This must be assigned after the relationship is established likely by a privileged customer admin.

The bridge from directory to resources is the remote tenant group itself: because the projected group can be referenced by Azure RBAC, the same proxy that holds Global Reader in the directory can also hold Reader or Contributor on a resource group. Critically, these are not separate identities, they are both roles held by the one remote tenant group, as the diagram above shows. And the directory role grants no Azure access on its own; the resource rights come entirely from the explicit RBAC assignment you choose.

That single design choice, roles branch off one proxy, is what lets one projected principal span both planes: the same remote tenant group can hold a directory role and a separate, explicit Azure RBAC grant, without ever issuing a local account.

What do these identities actually look like in the customer tenant? The only place you will see the security group is in the governance relationship. You will not find it among your other Entra groups.

Fig 3 - Governance relationship shows the projected principal in the customer tenant

Fig 4 - The projected principal does not appear in the customer tenant security groups

For RBAC purposes, you can find the proxy security group under resource Access Control (IAM) as a foreign group.

Fig 5 - The projected principal is available for RBAC assignments as a foreign group

6. The building blocks, and how they depend on each other

Now that the concept is in place, here's the assembly order. Each block depends on the one before it.

Fig 6 - Sequence of creating a governance relationship

A role-assignable security group in the provider tenant, the principal you intend to project.
A policy template that selects which directory roles that group should receive when projected (governance policy templates).
A governance relationship, established by a handshake. In the standard three-step flow the customer invites, the provider requests (carrying the template), and the customer accepts; a streamlined two-step flow (request → accept) applies when the two tenants already share a qualifying signal, such as a billing relationship or an existing governance relationship. At acceptance, the role assignments are provisioned in the customer (set up a governance relationship). The template's role set is projected onto the relationship, so later template edits require a fresh request and re-approval, the customer always gets to review what changes.
The projected proxy plus its role assignments in the customer, the remote tenant group (or service principal), now holding the directory and/or Azure RBAC roles you granted.

Under the hood: this cross-tenant delegation is powered by granular delegated admin privileges (GDAP), the same delegation technology behind Partner Center (cross-tenant delegated administration). You don't configure it directly; the relationship and the template do it for you. That's all you need to know about the plumbing.

The whole flow is also scriptable through the Microsoft Graph Tenant Governance APIs (API overview), and a default template can bring new add-on tenants under governance automatically at creation (deployment guide).

7. Key Features

Because the proxy can hold both directory roles and Azure RBAC, Tenant Governance unlocks delegated administration across the entire surface a partner might legitimately need:

Directory administration, read or manage the customer's Microsoft Entra directory with least-privileged built-in roles, using home credentials, no local accounts.
Identity governance, run access reviews, entitlement management, and lifecycle workflows across many customer tenants from one place.
Security operations, operate security and compliance tooling centrally. Microsoft Defender XDR and Microsoft Sentinel multitenant management for MSSPs is one prominent example built on this model (governance relationships for unified SecOps).
Azure resource management, the remote tenant group can carry Azure RBAC for any Azure service, exactly the way a local group would. That covers the management (control) plane only; neither model delegates the resource data plane (for example, blob data or Key Vault secrets), so those operations still require an identity native to the customer tenant.
Application management, project a custom multitenant app as a service principal with consistent, least-privileged permissions across tenants (governance policy templates).

The provider's users and service principals use their provider-tenant identities, and no local or B2B account is ever planted in the customer. The one object the customer does gain is in the application case, a governed service principal of the projected app, created and maintained through the relationship rather than as a standing local login.

8. Comparing Tenant Governance with Azure Lighthouse

Now that both models are understood, the comparison is straightforward. They operate on different planes and point in different directions.

Dimension	Azure Lighthouse	Microsoft Entra Tenant Governance
Direction of projection	Customer resources → provider	Provider identity → customer
Where the provider identity operates	From the provider tenant (customer resources projected up; no customer sign-in)	In the customer tenant, authenticated by the provider home tenant — as {Provider} Technician
Planes reached	Azure resource (ARM) plane only	*Directory plane and* Azure resource plane**
Data-plane access (e.g., blob data, Key Vault secrets)	Not supported (control/ARM plane only)	Not supported (the proxy can hold a DataActions role, but cannot obtain a data-plane token)
Identity footprint in customer	None	A projected proxy principal, no local or guest object
Conditional Access	Only the provider's policies apply (security practices)	The customer's policies apply, the customer is the resource tenant for the technician's sign-in (lab-verified; see below)
Where the privileged assignment lives	Provider tenant (JIT approvers in the provider) (eligible authorizations)	Customer tenant (the role assignment is owned customer-side)
Audit of provider actions	Customer Activity Log (view activity)	Customer audit log records the provider user’s actions; the authentication sign-in is recorded provider-side, it appears in the customer's sign-in log only when the customer's CA fires
Role types	Azure built-in roles only, no custom roles; Owner and roles with DataActions excluded, and Microsoft.Authorization/* writes excluded except User Access Administrator for managed-identity assignments (role rules)	Directory roles and Azure RBAC (including custom RBAC) on the proxy
Setup	ARM template / Marketplace offer (onboard)	Relationship handshake (invitation → request → acceptance)
Revocation	Remove the delegation, either party (remove)	Terminate the relationship, either party
Operational view	Single pane of glass, every delegated customer's resources surface in the provider's own portal	Per-customer, the admin signs in to each customer tenant individually
Best for	Scaled Azure resource operations	Directory / identity / security delegation plus resources

The sign-in, Conditional Access, footprint, and audit rows describe the human delegated-administration path (a projected group). In the application case the customer instead gets a governed service principal, so those rows read differently.

Direction of projection, the root cause. Everything else in the table is a consequence of this one row. Lighthouse brings the customer's resources up to the provider; Tenant Governance places a governed proxy of the provider's identity down in the customer. Decide which direction your scenario actually needs, and the rest mostly answers itself.
Conditional Access, the cleanest inverse. With Lighthouse, provider users authenticate in their own tenant, so the customer's Conditional Access never reaches them, "Only policies set on the managing tenant apply"(recommended security practices). With Tenant Governance the provider actually signs in to the customer tenant (use cross-tenant delegated administration), which makes the customer the resource tenant that evaluates Conditional Access, so the customer's policies govern the inbound provider login, not the provider's policies.

Two nuances to keep in mind: When the provider logs into the customer tenant, the authentication still happens with the provider’s tenant, but the conditional access policy applied to the login is in the customer tenant.

Where privileged access lives. Lighthouse offers just-in-time elevation through eligible authorizations, and the approvers sit in the provider (managing) tenant, "up to 10 users or user groups in the managing tenant who can approve"(create eligible authorizations). Tenant Governance inverts the ownership: the proxy's role assignment lives in the customer tenant, so privileged-access governance over that assignment is anchored customer-side. The useful contrast is simply where the assignment lives and who governs it, provider-side for Lighthouse, customer-side for Tenant Governance.
Audit and identity footprint. With Lighthouse, provider actions land in the customer's Azure Activity Log under a named user, with no customer sign-in and no directory object (view provider activity). Tenant Governance is more subtle. The provider user's authentication is handled and logged in the provider (home) tenant, so the bare sign-in appears there, not in the customer tenant. What does get logged in the customer directory is the provider user’s actions, in its audit log, where the actor shows as the <provider tenant's name + Technician> (e.g. Contoso Technician) (use cross-tenant delegated administration). A sign-in entry from the provider user only appears in the customer's logs when the customer's Conditional Access evaluates the session, for example, an MFA challenge. Without such a policy, that sign-in is only logged on the provider side. Either way, the customer keeps a full audit of what the technician does and gains no standing local or guest object (cross-tenant delegated administration).

Fig 7 - The providers activities on resources are logged in the customer's subscription activity log as "<provider name> Technician"

Fig 8 - When the provider logs into the customer tenant, their authentication is logged against the provider tenant while Conditional Access is logged against the customer tenant

One console vs. many: Operational reach. Because Lighthouse projects the customer's resources up, the provider works from a single pane of glass, every delegated customer's subscriptions appear in the provider's own Azure portal, and cross-tenant tooling, Azure Resource Graph, Microsoft Sentinel, Azure Policy, Azure Monitor, can span all of them at once. Tenant Governance points the other way: the provider's identity projects down into each customer, so day-to-day administration is per-customer, the admin signs in to each customer tenant in turn. (Service consoles such as Microsoft Defender XDR add their own aggregated multitenant views on top, but the underlying delegated-admin model is per-tenant.) When operating many customers' Azure estates from one console is the priority, that single-pane reach is a distinct Lighthouse strength.

9. Where the two models overlap

As is the case with other delegated access models, there is clear overlap between Azure Lighthouse and Tenant Governance:

Both eliminate local and B2B accounts in the customer. The partner's people stay in the provider tenant either way (Lighthouse architecture, cross-tenant delegated administration).
Both can ultimately place Azure RBAC on customer resources, Lighthouse directly through the delegation, Tenant Governance via the remote tenant group.
Both are limited to the control (management) plane, neither delegates resource data-plane access (for example, blob data or Key Vault secrets); that still requires an identity native to the customer tenant.
Both keep the customer in control of the audit record, provider actions are written to the customer's logs.
Both are revocable by either party, remove the delegation, or terminate the relationship.

10. What is complimentary with the two models?

Because they sit on different planes and point in opposite directions, you can use one or both.

Fig 9 - Azure Lighthouse and Entra Tenant Governance compared

Deciding between the two delegated access models:

Need only to operate the customer's Azure resources, especially across many customers? Choose Azure Lighthouse, no extra license or charge, a broad set of Azure built-in roles (Owner and custom roles excluded), just-in-time elevation with provider-side approval, zero directory footprint, and a single pane of glass: because customer resources project up into the provider's tenant, the provider manages every customer's estate from their own portal, with cross-tenant tooling spanning all of them at once.
Need directory, identity, or security reach, not just resources? Choose Microsoft Entra Tenant Governance, directory roles and Azure RBAC on one projected principal, with the customer's own sign-in controls in the loop. Because the provider's identity projects down into each customer, administration is per-customer: the admin signs in to each customer tenant in turn rather than from one aggregated console.
Need both on the same tenant? Use both. They coexist because they operate on different planes, Lighthouse for the resource estate, Tenant Governance for directory and security.

11. Key points to remember about Entra Tenant Governance

Least privilege. A directory role grants no Azure access, and an Azure RBAC role grants no directory access. Each plane is an explicit grant to the proxy, start with read-only (e.g., Global Reader in the directory, Reader on resources) and add only what's needed.
Directory ≠ resource. The two planes are independent. If the partner needs to operate Azure resources, that comes from an explicit RBAC assignment on the remote tenant group, not from any directory role. That RBAC is control-plane only; neither Tenant Governance nor Lighthouse delegates the resource data plane (for example, blob data or Key Vault secrets), which still requires an identity native to the customer tenant.
Tenant discovery is irreversible. Enabling related-tenant discovery is permanent (deployment guide). For a controlled pilot, run the handshake by tenant ID and skip discovery. Azure Lighthouse, by contrast, coexists with a governance relationship on the same customer, different mechanism, different plane.
Conditional Access is the customer's to enforce. Because the provider signs in to the customer tenant, the customer's Conditional Access governs that access.

12. Summary

Azure Lighthouse and Microsoft Entra Tenant Governance are two delegation models pointing in opposite directions. Lighthouse brings the customer's resources up to the provider and keeps the provider's Azure access clean and identity-free. Tenant Governance places a governed proxy of the provider down in the customer, extending the very philosophy from Parts 1–2, govern the relationship, not the people, from the resource plane all the way into the directory.

Choose by the direction the trust needs to flow: bring the resources to you (Azure Lighthouse), or place a governed proxy of yourself in the customer (Microsoft Entra Tenant Governance). When you need both, use both.

Lessons Learned #547:Some SQL DB Statistics Remain Outdated While Others Are Automatically Updated

Jose_Manuel_Jurado — Thu, 23 Jul 2026 09:47:54 GMT

During the analysis of a SQL Server performance case, we observed an interesting statistics update pattern on a large table.

Several statistics had recently been updated at different times, while a group of automatically created _WA_Sys_ statistics still showed:

An older last_updated date.
A high modification_counter.
A row count significantly lower than the current number of rows in the table.

At first glance, this could suggest that AUTO_UPDATE_STATISTICS was not working correctly. However, a closer review showed that this pattern can be completely consistent with the expected behavior of SQL Server.

1. Types of statistics in SQL Server

SQL Server can maintain several types of statistics.

Automatically created column statistics

When AUTO_CREATE_STATISTICS is enabled, SQL Server can automatically create a single-column statistic when the Query Optimizer needs cardinality information for a column used in a query predicate. These statistics normally use names such as: _WA_Sys_00000002_47A6D5E5

The name can be interpreted as: _WA_Sys_<column_id in hexadecimal>_<object_id in hexadecimal>

For example: 00000002 hexadecimal = column_id 2 47A6D5E5 hexadecimal = table object_id

The most reliable way to identify the associated column is not to decode the name manually, but to query the SQL Server catalog views:

DECLARE @TableName sysname = N'dbo.CustomerTransactions'; SELECT s.stats_id, s.name AS statistics_name, sc.stats_column_id, c.column_id, c.name AS column_name, s.auto_created, s.user_created, s.no_recompute FROM sys.stats AS s INNER JOIN sys.stats_columns AS sc ON sc.object_id = s.object_id AND sc.stats_id = s.stats_id INNER JOIN sys.columns AS c ON c.object_id = sc.object_id AND c.column_id = sc.column_id WHERE s.object_id = OBJECT_ID(@TableName) AND s.name = N'_WA_Sys_00000002_47A6D5E5' ORDER BY sc.stats_column_id;

Statistics associated with indexes

When SQL Server creates an index, it also creates a statistics object associated with the index. For example: CREATE INDEX IX_CustomerTransactions_ClientId ON dbo.CustomerTransactions(ClientId) this creates an index statistics object normally named: IX_CustomerTransactions_ClientId when a statistics object corresponds to an index, its stats_id matches the index's index_id.

User-created statistics

Statistics can also be created explicitly: CREATE STATISTICS ST_CustomerTransactions_ClientId_Status ON dbo.CustomerTransactions ( ClientId, StatusId ); This object is identified in sys.stats with: user_created = 1 auto_created = 0 and AUTO_UPDATE_STATISTICS applies to index statistics, automatically created single-column statistics, manually created statistics and filtered statistics.

2. Statistics are not updated together

Assume that a table has these statistics:

_WA_Sys_00000002_xxxxxxxx for ClientId
_WA_Sys_00000003_xxxxxxxx for StatusId
IX_CustomerTransactions_CreatedDate for CreatedDate PK_CustomerTransactions and TransactionId

After a large data load, several or all of them could become eligible for an automatic update. However, SQL Server does not immediately update all eligible statistics. Before compiling a query, the Query Optimizer identifies the statistics that could be relevant to the query predicates and checks whether those statistics are outdated.

Consider this query:

SELECT TransactionId, ClientId, Amount FROM dbo.CustomerTransactions WHERE ClientId = 100;

The optimizer might need a histogram on ClientId. If the corresponding statistics object is outdated and has crossed its update threshold, SQL Server may update that specific statistics object.

It does not need to update unrelated statistics on:

StatusId
CreatedDate

As a result, statistics on the same table can legitimately have different update times:

PK_CustomerTransactions 2026-07-22 10:53
IX_CustomerTransactions_ClientId 2026-07-22 10:50
IX_CustomerTransactions_CreatedDate 2026-07-22 10:13
_WA_Sys_00000003_47A6D5E5 2026-07-19 10:00

This pattern can be evidence of demand-driven automatic updates rather than evidence of a malfunction.

3. What does modification_counter represent?

The modification_counter returned by sys.dm_db_stats_properties represents the number of modifications made to the leading statistics column since that statistics object was last updated. This definition is especially important for multicolumn statistics.

For example: CREATE INDEX IX_CustomerTransactions_ClientId_Status ON dbo.CustomerTransactions ( ClientId, StatusId );

The associated statistics object contains:

Histogram: ClientId
Density information: ClientId ClientId, StatusId

The histogram and modification_counter are based on the leading column, ClientId.

If only StatusId is modified: UPDATE dbo.CustomerTransactions SET StatusId = 2 WHERE TransactionId = 100; this does not have the same statistics impact as changing ClientId, because ClientId is the leading histogram column.

SQL Server statistics contain only one histogram, built on the first key column. Multicolumn statistics additionally contain density information for column prefixes.

4. Why do multiple statistics sometimes have similar modification counters?

This commonly happens after an insert operation.

For example:

INSERT INTO dbo.CustomerTransactions ( TransactionId, ClientId, StatusId, Amount, CreatedDate ) SELECT TransactionId, ClientId, StatusId, Amount, CreatedDate FROM dbo.StagingCustomerTransactions;

Each inserted row introduces a value for every populated column. Consequently, multiple single-column statistics may show similar increases in their modification counters. This is particularly visible after a large ETL operation: Table rows before the load: 487,673 Rows inserted by the ETL: 515,244 Current approximate row count: 1,002,917

Several statistics could then show modification counters close to the number of inserted rows. That does not mean SQL Server must update all those statistics immediately. They become candidates for updating, but an update is normally triggered when query optimization requires them.

5. Does automatic updating apply only to _WA_Sys_ statistics?

AUTO_UPDATE_STATISTICS applies to:

Automatically created _WA_Sys statistics
Index statistics Primary-key index statistics
User-created statistics

Each statistics object is evaluated independently. Therefore, SQL Server might update: PK_CustomerTransactions while leaving this object unchanged: _WA_Sys_00000003_47A6D5E5

The reverse is also possible. The behavior depends on which statistics are considered relevant during compilation or cached-plan validation.

6. What happens when a _WA_Sys_ statistic and an index statistic cover the same column?

This is one of the most interesting scenarios. Assume SQL Server originally created: _WA_Sys_00000002_xxxxxxxx for ClientId.

Later, someone creates this index: CREATE INDEX IX_CustomerTransactions_ClientId ON dbo.CustomerTransactions(ClientId);

The table now has two statistics objects with histograms on ClientId: _WA_Sys_00000002_xxxxxxxx and IX_CustomerTransactions_ClientId

Conceptually: _WA_Sys statistic Histogram on ClientId Index statistic Histogram on ClientId

For a query such as: SELECT * FROM dbo.CustomerTransactions WHERE ClientId = @ClientId; the optimizer can have more than one potentially relevant statistics object. It may rely on the index statistics object rather than the older _WA_Sys_ object.

In that case:

IX_CustomerTransactions_ClientId Updated recently
_WA_Sys_00000002_xxxxxxxx
- Old last_updated value
- High modification_counter

This does not necessarily mean that automatic statistics updating has failed. It can mean that the _WA_Sys_ statistic has become redundant and has not been required by recent compilations.

However, this should be presented carefully: The Query Optimizer is not publicly documented as always preferring an index statistic over an equivalent _WA_Sys_ statistic.

The statistics selected can depend on:

Query.
Predicates.
Available indexes.
Filtered versus unfiltered statistics.
Statistics freshness.
Sampling quality.
Multicolumn density information.
Cardinality Estimator behavior.
Existing cached plans.

The correct conclusion is that the scenario is possible and plausible, but the execution plan should be inspected before claiming that a specific statistics object was used.

As we wrote down in multiple articles in our blog (below), identify redudant statistics is part of DBA work to avoid this situation, also, in other situations, I saw that the maintenance plan is taking too much time because we are updating statistics that we are not using or migth be duplicated. The following script identifies statistics whose leading columns overlap:

DECLARE @TableName sysname = N'dbo.CustomerTransactions'; ;WITH LeadingStatisticsColumns AS ( SELECT s.object_id, s.stats_id, s.name AS statistics_name, s.auto_created, s.user_created, s.no_recompute, s.has_filter, s.filter_definition, sc.column_id, c.name AS leading_column, i.index_id, i.name AS index_name FROM sys.stats AS s INNER JOIN sys.stats_columns AS sc ON sc.object_id = s.object_id AND sc.stats_id = s.stats_id AND sc.stats_column_id = 1 INNER JOIN sys.columns AS c ON c.object_id = sc.object_id AND c.column_id = sc.column_id LEFT JOIN sys.indexes AS i ON i.object_id = s.object_id AND i.index_id = s.stats_id WHERE s.object_id = OBJECT_ID(@TableName) ) SELECT leading_column, statistics_name, CASE WHEN index_id IS NOT NULL THEN N'INDEX STATISTICS' WHEN auto_created = 1 THEN N'AUTO-CREATED _WA_SYS' WHEN user_created = 1 THEN N'USER-CREATED STATISTICS' ELSE N'OTHER' END AS statistics_type, index_name, has_filter, filter_definition, no_recompute, COUNT(*) OVER ( PARTITION BY column_id ) AS statistics_on_same_leading_column FROM LeadingStatisticsColumns ORDER BY leading_column, statistics_type, statistics_name;

This does not automatically mean that one object should be deleted. It only identifies an overlap.

7. Script

The following example demonstrates how an automatically created statistic can coexist with a later index statistic.

DROP TABLE IF EXISTS dbo.CustomerTransactions; GO CREATE TABLE dbo.CustomerTransactions ( TransactionId int NOT NULL, ClientId int NOT NULL, StatusId tinyint NOT NULL, Amount decimal(12,2) NOT NULL, CreatedDate datetime2(0) NOT NULL, CONSTRAINT PK_CustomerTransactions PRIMARY KEY CLUSTERED (TransactionId) ); GO

Insert sample data

;WITH Numbers AS ( SELECT TOP (200000) ROW_NUMBER() OVER ( ORDER BY (SELECT NULL) ) AS n FROM sys.all_objects AS a CROSS JOIN sys.all_objects AS b ) INSERT INTO dbo.CustomerTransactions ( TransactionId, ClientId, StatusId, Amount, CreatedDate ) SELECT n, n % 5000, n % 5, CONVERT(decimal(12,2), n % 10000), DATEADD ( minute, -(n % 100000), SYSUTCDATETIME() ) FROM Numbers; GO

Ensure that automatic statistics creation and updating are enable

ALTER DATABASE CURRENT SET AUTO_CREATE_STATISTICS ON; GO ALTER DATABASE CURRENT SET AUTO_UPDATE_STATISTICS ON; GO

Trigger automatic statistics creation on ClientId

SELECT COUNT_BIG(*) FROM dbo.CustomerTransactions WHERE ClientId = 100 OPTION (RECOMPILE); GO

Check the statistics created for ClientId

SELECT s.stats_id, s.name AS statistics_name, s.auto_created, s.user_created, c.name AS column_name FROM sys.stats AS s INNER JOIN sys.stats_columns AS sc ON sc.object_id = s.object_id AND sc.stats_id = s.stats_id INNER JOIN sys.columns AS c ON c.object_id = sc.object_id AND c.column_id = sc.column_id WHERE s.object_id = OBJECT_ID(N'dbo.CustomerTransactions') AND c.name = N'ClientId' ORDER BY s.stats_id;

Create an index on the same column

CREATE INDEX IX_CustomerTransactions_ClientId ON dbo.CustomerTransactions(ClientId);

The table can now have:

Modify the data significantly

UPDATE dbo.CustomerTransactions SET ClientId = ClientId + 10000 WHERE TransactionId <= 100000;

Review the counters again

SELECT s.name AS statistics_name, sp.last_updated, sp.rows, sp.rows_sampled, sp.modification_counter FROM sys.stats AS s OUTER APPLY sys.dm_db_stats_properties ( s.object_id, s.stats_id ) AS sp WHERE s.object_id = OBJECT_ID(N'dbo.CustomerTransactions') ORDER BY s.stats_id

Force a new compilation using ClientId

SET STATISTICS XML ON; GO SELECT COUNT_BIG(*) FROM dbo.CustomerTransactions WHERE ClientId = 10100 OPTION (RECOMPILE); GO SET STATISTICS XML OFF; GO

After the query, review:

The actual execution plan XML.
The StatisticsInfo elements.
last_updated.
modification_counter.

The exact object updated is an optimizer decision and can vary by SQL Server version, build, compatibility level and query shape. The test should therefore be used to observe the behavior rather than to assume a fixed preference.

Finally, as you could see SQL Server choose _WA_Sys_00000002_151102AD instead of IX_CustomerTransactions_ClientId to update. In some situations, depending on execution plan, SQL Server might choose IX_CustomerTransactions_ClientId to update instead of _WA_Sys_00000002_151102AD and for this reason, doesn't mean that SQL Server is not updating the statistics it is depending that it is choosing one of them that the column is involved.

My lessons learned, a statistic can be outdated without being relevant, and it can be relevant without being the only available source of cardinality information. Before interpreting an old last_updated value as an automatic statistics failure, identify the leading column, look for overlapping statistics, inspect the execution plan and determine whether there is a real estimation or performance problem.

Articles:

Lesson Learned #482: Identifying Potential Duplicate Statistics | Microsoft Community Hub

Lesson Learned #324: Query Recompilation in Azure SQL | Microsoft Community Hub

Lessons Learned #537: Copilot Prompts for Troubleshooting on Azure SQL Database | Microsoft Community Hub

Lesson Learned #498:Understanding the Role of STATMAN in SQL Server and Its Resource Consumption | Microsoft Community Hub

Disclaimer:

The scripts included in this article are provided for demonstration and educational purposes only. They create a sample table, insert a significant number of rows, create indexes and statistics, modify data, and change automatic statistics settings in the current database.

Run the complete demonstration only in a test or non-production environment. Review and adapt the database name, object names, row volume, and statements before execution.

The results may vary depending on the SQL Server version, database compatibility level, existing configuration, data distribution, and workload. Always test the scripts in a representative environment before applying any conclusion or change to a production system.

Design, test, and ship Foundry hosted agents from a canvas in GitHub Copilot App

junjieli — Thu, 23 Jul 2026 07:50:18 GMT

Building a Microsoft Foundry hosted agent has historically meant juggling multiple surfaces — looking up a model deployment in the Foundry portal, wiring toolboxes and skills by hand, copying an endpoint into your editor, then dropping to the CLI to test and deploy. That context-switching adds friction at exactly the moment you want to be experimenting.

Today we're changing that. The Foundry Agent Canvas is now in public preview. With this release, the full hosted-agent workflow — discover, scaffold, configure, test, deploy — lives right beside the Copilot chat that's already writing your code.

The Foundry Agent Canvas is a GitHub Copilot App extension that opens a visual canvas in the side panel. You make choices in the canvas, and it hands each step to Copilot with your Foundry project context already attached. Copilot writes the code and runs the commands; the canvas keeps the visual state and your workspace in sync. Here are a few things this unlocks for developers.

🧭 A project-aware canvas, one prompt away

Ask Copilot to create a Foundry hosted agent and the canvas opens automatically, connected to your project. It surfaces what's actually deployed — models, Foundry Toolboxes and their tools, project skills, and account guardrails — so you're choosing from real resources, not a static list.

To get started:

In the GitHub Copilot App, ask Copilot: Create a Foundry hosted agent using the Foundry Agent Canvas.
Open the canvas project menu, sign in to Azure if you're prompted, and pick a subscription.
Select a Foundry project. The canvas remembers your choice across reopens.

✨ Scaffold and configure without leaving the panel

Start from a generated idea with Inspire me, or begin from a Hello world sample. From there, wire the agent to a deployed model and connect any toolboxes, skills, and guardrails. Every selection becomes a project-aware prompt to Copilot, which updates the agent code for you.

To build your agent:

Choose Inspire me for a generated starting point, or the Hello world sample prompt.
Select a deployed model, then connect toolboxes, skills, and guardrails from your project.
Let Copilot apply each change in your workspace as you go.

🔍 Test locally with the embedded Agent Inspector

When you're ready to try it, Inspect Locally runs the agent and embeds the Agent Inspector right in the canvas — no separate REST client, no extra tooling. Chat with the agent, and if something breaks, send the error straight back to Copilot as a fix request.

To test and deploy:

Click Inspect Locally — the canvas runs the agent and opens the Agent Inspector on port 8088.
Send a prompt such as Write a haiku about deploying cloud applications. and iterate.
Click Deploy to Foundry to publish the agent to Foundry Agent Service.

Because Inspect Locally and Deploy to Foundry run the underlying Azure Developer CLI (azd) commands, you're never boxed in — drop back to the terminal whenever you want.

Hosted agents are one of the fastest-growing ways developers build on Microsoft Foundry — from internal copilots to task automation to customer-facing assistants. This release gives you a first-class, visual path to design and ship them faster, without giving up the code-first workflow you already know.

🚀 Get Started Today

Ready to build your first agent from the canvas? Here's how to jump in:

In the GitHub Copilot App, open Settings > Plugins, search for foundry-agent-canvas, and select Install. You can also install it from the awesome-copilot listing or ask Copilot to install it into user scope.
Ask Copilot to create a Foundry hosted agent, then follow the canvas from project pick to deploy.
Walk through it end to end with the Deploy your first hosted agent quickstart, and read the Foundry Agent Canvas overview for the full picture.

We'd love to hear from you! Whether it's a feature request, a bug report, or feedback on your experience, join the conversation and contribute directly on our GitHub repository.

Happy Coding!

Azure Files, Reimagined: Top-Level Shares with Per-Share Networking, Billing, and Scale

Pierre_Roman — Thu, 23 Jul 2026 07:00:00 GMT

Hello Folks!

If you have ever wrestled with Azure Files inside a storage account, juggling shared RBAC, shared networking, and shared IOPS across a pile of shares that really should not live together, this session is going to address all that. During Microsoft Azure Infra Summit 2026, Vincent Du and Will Gries (both Product Managers on the Azure Files team) walked us through the new Microsoft.FileShares resource provider, a management model that promotes the file share itself to a top-level Azure resource.

📺 Watch the session:

Why IT Pros Should Care

For years, file shares lived inside a storage account, and that storage account dictated a lot of decisions for you. If one team needed a private endpoint and another needed a service endpoint, you either compromised or you created another storage account. If one share got hot and consumed all the IOPS, the other shares felt it too. Vincent and Will are on the team that built the new model to remove that compromise.

Here is what changes for you as an IT pro:

Each file share is its own Azure resource with its own RBAC, networking, billing, IOPS, and throughput.
Per-share cost shows up directly in Azure Cost Management’s per-resource view, no more Excel guesswork.
Encryption in transit is on by default for NFS shares, at no extra cost.
Provisioning is dramatically faster. In their head-to-head demo, 200 shares finished in about 50 seconds on the new model versus about 720 seconds with the classic flow.
A new MCP server lets you create and manage shares from GitHub Copilot in VS Code with natural language.

In short, the new model trades the storage-account-as-gatekeeper pattern for something that feels a lot more like the rest of Azure (think VMs and disks, where the resource you care about is the resource you actually manage).

What Microsoft.FileShares Does, a Technical Overview

The new Microsoft.FileShares resource provider lets you deploy a file share without first standing up a storage account. When you go into the Azure portal, search for “File share,” and click create, you fill out a single create blade with the things that actually matter for that share: name, region, redundancy (LRS or ZRS), provisioned capacity, IOPS and throughput, networking, and tags. Microsoft Learn confirms the provisioned capacity range is 32 GiB to 262,144 GiB, and only LRS and ZRS redundancy are available at launch (see the Create a file share doc linked below).

At GA, the new experience supports NFS 4.1 on the SSD media tier. SMB support, HDD support, customer-managed key encryption at rest, soft delete, and the AKS CSI driver integration are all on the roadmap and called out as the most-requested follow-ups. If you need those features today, the classic file share inside a storage account is still there for you.

In the portal, Vincent showed off a small but meaningful detail: the icon color changed from blue (classic) to purple (new). It is a small thing, but when you are scanning a resource group, that visual cue saves you a click.

How It Works Under the Hood

The new model is built on the provisioned v2 billing structure. Microsoft Learn describes provisioned v2 as a billing model where you independently provision storage, IOPS, and throughput, and you pay for what you provision regardless of how much you actually use. This is a real shift from the older provisioned v1 model, where IOPS and throughput were a function of how much storage you provisioned.

Will walked through the math. In his example, provisioning 14 TiB of storage on v1 gave 17,000 IOPS, about 1.5 GB/s throughput, and a bill of roughly $2,297. Moving to v2 with the exact same numbers was already noticeably cheaper. Then, because v2 lets you tune storage, IOPS, and throughput separately, he provisioned the exact storage he needed with slightly less IOPS and throughput, dropping the bill to roughly a third. For database-hot workloads you can dial IOPS up; for hot archive scenarios you can dial them down to the minimum. That kind of flexibility is genuinely useful.

Encryption in transit deserves its own callout. The new shares default to encrypted NFS mounts using the AZNFS mount helper. Microsoft Learn explains that AZNFS wraps the NFS connection in a Stunnel-based TLS tunnel using AES-GCM, so you get TLS protection without needing Kerberos or external authentication. The helper installs cleanly on Ubuntu, RHEL, SUSE, Rocky, Oracle Linux, Alma Linux, and Azure Linux. If a workload genuinely cannot use the encrypted mount, you can uncheck the box and fall back to a traditional NFS mount.

Networking is per share. You can attach a service endpoint or a private endpoint to each individual share, which means you can put a strict private-endpoint-only share next to a service-endpoint share for dev/test, all in the same resource group, without compromise.

On the request side, classic shares throttle with a fixed window (you can burst, then you are locked out for the rest of the window). The new model uses a token-bucket algorithm (the same one Azure Resource Manager itself uses), which means you get a sustained refill rate. The team also gave you a separate delete bucket, so a big cleanup operation does not starve writes. That detail matters more than it sounds: batch cleanups against the classic model regularly crowd out new share creation.

Real-World Value

Where does this actually pay off? A few honest scenarios:

Mission-critical and regulated workloads. A healthcare org with workloads at different sensitivity levels can put strict private-endpoint-only shares next to less sensitive service-endpoint shares without the storage-account ceiling.
Chargeback and showback. With per-share resources, finance can pull a cost report that lines up to the team or project that owns each share. No more saying “we cannot itemize, the storage account is shared.”
High-density tenants. The classic model effectively caps you at 34 file shares on an SSD provisioned v2 storage account (because of IOPS minimums) and 50 absolute. The new model goes up to 10,000 shares per subscription per region. That is a different game.
Tuned database and analytics shares. Provisioned v2 lets you right-size IOPS to the workload. As Will showed, that can drop the bill to roughly a third for the right shape of workload.
Faster deployment automation. A 14x improvement on a 200-share deployment is not a micro-optimization. If you spin up environments for CI, training, or per-customer tenants, that adds up quickly.

The honest tradeoff: today, the new model is NFS-only on SSD. If you need SMB, HDD, customer-managed keys for NFS, or AKS CSI driver support, stay on the classic model for now. The team was upfront about that, and the GA-and-then-iterate roadmap is clear.

Getting Started

Here is the concrete path:

Register the Microsoft.FileShares and Microsoft.Storage resource providers on your subscription (Subscriptions, Resource providers, Register).
From the Azure portal, search for “File share” in the marketplace and click Create. Pick LRS or ZRS, set the capacity between 32 GiB and 262 TiB, and either accept the recommended IOPS/throughput or set them manually.
On the Advanced tab, leave “Require encryption in transit” enabled (it is on by default) and pick a custom mount name if you want one distinct from the resource name.
On the Networking tab, attach a service endpoint or a private endpoint, per share.
Mount it on your Linux VM with the AZNFS mount helper. The portal generates the exact command for your distribution.
If you live in IaC land, the Microsoft.FileShares ARM and Bicep types are available, and Terraform support is coming.
If you live in AI-assisted dev land, install the Azure MCP server and ask Copilot in VS Code to create a share for you, pointing at an existing VNet.

Resources

Keep Learning at the Summit

Catch the full Microsoft Azure Infra Summit 2026 session playlist here.

Cheers!

Pierre Roman

Regex-based dynamic data masking in Azure SQL Database (preview)

MadhumitaTripathyMSFT — Thu, 23 Jul 2026 06:48:35 GMT

Azure SQL Database introduces Regex-based dynamic data masking, a new capability that enables flexible, pattern-driven masking for string-based columns using regular expressions through the T‑SQL REGEXP_REPLACE() function. This feature extends Dynamic Data Masking beyond built-in masking functions, giving you precise control over which portions of sensitive data are masked and which remain visible, helping preserve data utility while meeting business and compliance requirements.

This capability is especially useful when working with structured data patterns—such as emails, phone numbers, or identifiers—where teams need to preserve specific visible segments while masking sensitive parts, and where built-in masks may be rigid for some business workflows.

Why this matters

Dynamic Data Masking helps reduce accidental exposure of sensitive data by obfuscating values in query results for nonprivileged users, while keeping the original data intact in the database. However, existing built-in masking functions—such as default(), email(), random(), partial(), and datetime()—apply fixed patterns. These patterns cannot be customized, and may not be suitable for some of the real-world scenarios.

For example, the built-in email() mask always transforms an address like alice.johnson@example.com into aXXX@XXXX.com, fully obscuring the domain name. In many operational scenarios, retaining the domain name is important for troubleshooting, routing, or business logic.

Regex-based dynamic data masking addresses this gap by enabling precision masking without sacrificing usability.

What’s new with regex-based masking

Regex-based DDM allows you to define custom, pattern-driven masking rules using regular expressions. By leveraging the native REGEXP_REPLACE function in Azure SQL Database, you can precisely specify which parts of a string to mask and which to preserve—centrally enforced in the database layer.

This approach supports variable-length and structured string data, enabling more precise and flexible data masking rules.

Practical scenarios

Regex-based masking enables common customer scenarios that are difficult to address with fixed masks:

Mask email usernames while preserving domains
alice.johnson@example.com → ****@example.com
Preserve country codes in phone numbers
+1-4155552671 → +1-XXXXXXXXXX
+44-7911123456 → +44-XXXXXXXXXX
Mask structured identifiers consistently
Hide sensitive portions of national IDs or custom identifiers while keeping recognizable structure for support and auditing workflows. For example: AB-1234-5678 → AB-****-5678

Example

The following example creates a table CustomerDetails with regex-based masking applied on Phone_Number and Email columns. The phone number mask preserves the country code and replaces the remaining digits with xxxx, and the email mask conceals the username while retaining the domain name.

-- Drop the CustomerDetails table if it exists

DROP TABLE IF EXISTS Data.CustomerDetails;

-- Create a CustomerDetails table under a schema

CREATE TABLE Data.CustomerDetails (

ID INT IDENTITY(1,1) PRIMARY KEY,

Name varchar(30),

Phone_Number varchar(30) MASKED WITH (FUNCTION = 'REGEXP_REPLACE("(\+\d{1,3})(?:[ -.]?\d){7,14}","(\1)-xxxx")'),

Email varchar(255) MASKED WITH (FUNCTION = 'REGEXP_REPLACE("([a-zA-Z0-9._%+-]+)(@+)([a-zA-Z0-9.-]+)(\.)(\w)","*****\2\3\4\5")')

);

-- Insert some dummy records to CustomerDetails table

INSERT INTO Data.CustomerDetails (Name, Phone_Number, Email) VALUES

('Alice Johnson', '+1 202-555-0123', 'alice.johnson@example.com'),

('Bob Smith', '+1 415-555-0198', 'bob.smith@contoso.com');

-- Create a test user

CREATE USER SupportEngineer WITHOUT LOGIN;

-- Grant read permission on CustomerDetails to SupportEngineer

GRANT SELECT ON Data.CustomerDetails TO SupportEngineer;

-- Query CustomerDetails table as SupportEngineer

EXECUTE AS USER = 'SupportEngineer';

SELECT * FROM Data.CustomerDetails;

REVERT;

Public Preview notice

Important
Regex-based dynamic data masking is currently in Preview for Azure SQL Database. Preview features are provided for evaluation purposes and are subject to the Preview Terms Of Use | Microsoft Azure.

Azure SQL Database is the first SQL offering to receive this feature, with additional SQL platforms planned in the future.

How to get started

To learn more and access sample scripts, refer to the official documentation Regex-based dynamic data masking (preview) - Azure SQL Database | Microsoft Learn

Try Regex-based dynamic data masking in your dev or test environment and tell us what works—and what doesn’t!

Tell us what you need next in Data Masking

Share your ideas through Azure SQL feedback forum.

Disclaimer: The examples in this article use fictional customer records created solely for demonstration and testing purposes. No real customer data is included.

Hybrid Logic Apps on RKE2: a self-managed cluster with MetalLB

anandgmenon — Thu, 23 Jul 2026 05:53:29 GMT

Azure Logic Apps Hybrid lets you run the Logic Apps runtime on your own Kubernetes cluster and still author, deploy, and monitor from Azure. The previous post walked through Red Hat OpenShift. This one is RKE2. We spun up a single-node RKE2 cluster, gave the ingress an IP with MetalLB, connected it to Arc, and shipped a Hybrid Logic App end-to-end. A handful of things needed care along the way, and those are what this post is really about.

If you've done Hybrid on AKS or K3s, the shape will look familiar. The official requirements doc covers the general flow. RKE2 is close enough to vanilla Kubernetes that most of it just works out of the box. Four things don't. Three of them are DNS. They're called out at the step they matter.

What makes RKE2 different?

Area	What we found
Ingress IP	RKE2 has an embedded cloud-controller-manager for node lifecycle, but no service load balancer. `type: LoadBalancer` sits at `<pending>` until you bring one. We used MetalLB (Step 2).
Pod security	No SCC dance like OpenShift; the extension pods schedule as-is. What we did hit was the node's `inotify` limit. Enough runtime pods use it that the default runs out and about half the deployment crash-loops (Step 4).
CoreDNS	RKE2 names its DNS objects `rke2-coredns-rke2-coredns`, not `coredns`/`kube-dns`. `az containerapp arc setup-core-dns` doesn't have an RKE2 distro flag yet, so DNS is manual (Step 7).
Distribution flag	RKE2 is upstream Kubernetes. Don't copy the OpenShift install command; the `Azure.Cluster.Distribution=openshift` and `coreDNSVersion` overrides don't apply here and will bite you (Step 4).

Prerequisites

A Linux host	Anywhere RKE2 runs: bare metal, a VM, an edge appliance. We used a single Ubuntu 22.04 Azure VM (`Standard_D8as_v5`) so everything was easy to nuke afterwards. 4 vCPU / 16 GB is the practical floor.
Azure subscription	Rights to create Arc resources, custom locations, and connected environments.
Azure CLI	Latest, with the `connectedk8s`, `k8s-extension`, `customlocation`, and `containerapp` extensions.
An SMB file share	Reachable from the cluster, for workflow artifacts.
A spare IP range	A small unused range on your node's L2 network for MetalLB to hand out (Step 2).

az extension add --name connectedk8s
az extension add --name k8s-extension
az extension add --name customlocation
az extension add --name containerapp

Step 1: Stand up RKE2

One line and a couple of minutes:

curl -sfL https://get.rke2.io | sudo sh -
sudo systemctl enable --now rke2-server.service

# kubectl + kubeconfig are dropped in place
export PATH=$PATH:/var/lib/rancher/rke2/bin
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
kubectl get nodes          # Ready in ~2-5 min after the first image pull

RKE2 servers are schedulable by default, so this single node is your entire cluster. No taint to remove. If you want to run kubectl from your laptop, add the node's public IP or hostname to tls-san in /etc/rancher/rke2/config.yaml before the first start, then copy rke2.yaml out and swap 127.0.0.1 for that address.

Quick sanity check. Expose a throwaway nginx as LoadBalancer: kubectl create deploy nginx --image=nginx && kubectl expose deploy nginx --port=80 --type=LoadBalancer. The EXTERNAL-IP will sit at <pending> forever. That's the gap MetalLB fills in the next step. Clean up the deployment and service when you're done looking.

Step 2: Give the ingress an IP with MetalLB

All the Logic Apps in this environment share a single Envoy ingress, and something has to give that service an IP. A cloud does it for you; on-prem, you pick one of two options:

In-cluster load balancer. MetalLB (or Cilium, kube-vip, OpenELB) assigns an IP from a pool on your node network. Leave envoy.serviceType=LoadBalancer in Step 4. This is what we did.
External L4 load balancer in front of NodePort. If you already run an F5, HAProxy, NetScaler, or an Azure Standard Load Balancer, keep using it. Set envoy.serviceType=NodePort (plus envoy.nodeHttpsPort / envoy.nodeHttpPort) and point your LB at those NodePorts. Then pass the LB's VIP as --static-ip in Step 6.

We went with MetalLB in L2 mode:

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.9/config/manifests/metallb-native.yaml
kubectl wait --for=condition=Ready pods --all -n metallb-system --timeout=180s

Then give it a pool from your node subnet and advertise it over L2:

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: hybrid-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.240-192.168.1.250   # a spare range on your node network
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: hybrid-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - hybrid-pool

Two things to watch. The range should be free on your node subnet, and it must not collide with RKE2's cluster (10.42.0.0/16) or service (10.43.0.0/16) CIDRs. Re-run the throwaway LoadBalancer test from Step 1; the EXTERNAL-IP should now be one of your pool addresses.

Running MetalLB on one cloud VM? L2 mode ARPs the pool IPs on the node's network, but a cloud SDN won't route an unassigned IP to your NIC from the outside. It works fine for anything inside the cluster (kube-proxy programs the IP locally), but to hit envoy from outside the VM you'll need to socat-forward the VM's public IP to the LB IP, or add the pool IP as a secondary ipconfig on the NIC. On real on-prem L2 you don't have to think about any of this.

Step 3: Connect the cluster to Azure Arc

az connectedk8s connect --name <cluster> --resource-group <rg> --location <region>
kubectl get pods -n azure-arc      # all agents Running in a couple of minutes

If your host is behind a strict egress policy, or in our case an internal MS VM with an inbound-deny NRMS policy, remember that Arc onboarding only needs outbound connectivity and a local kubeconfig. We ran the connect command on the VM itself using a system-assigned managed identity (az login --identity). No inbound port, no browser device-code prompt.

Step 4: Install the Container Apps extension

This is the extension that turns the cluster into a Logic Apps host. On RKE2 it's the plain command, with no Azure.Cluster.Distribution or coreDNSVersion overrides. If you copy those from an OpenShift guide, the install will still succeed and then behave in mildly confusing ways.

az k8s-extension create \
  --resource-group <rg> --cluster-name <cluster> \
  --cluster-type connectedClusters --name logicapps-aca-extension \
  --extension-type Microsoft.App.Environment \
  --release-train stable --auto-upgrade-minor-version true --scope cluster \
  --release-namespace logicapps-aca-ns \
  --configuration-settings "Microsoft.CustomLocation.ServiceAccount=default" \
  --configuration-settings "appsNamespace=logicapps-aca-ns" \
  --configuration-settings "clusterName=<env-name>" \
  --configuration-settings "keda.enabled=true" \
  --configuration-settings "keda.logicAppsScaler.enabled=true" \
  --configuration-settings "keda.logicAppsScaler.replicaCount=1" \
  --configuration-settings "containerAppController.api.functionsServerEnabled=true" \
  --configuration-settings "functionsProxyApiConfig.enabled=true" \
  --configuration-settings "envoy.serviceType=LoadBalancer"

Our first install came back "Succeeded", but half the pods were in CrashLoopBackOff. billing, containerapp-controller, keda-logicapps-scaler, mdm, and log-processor all had the same line in their logs:

The configured user limit (128) on the number of inotify instances has been reached

These are .NET services with FileSystemWatcher under the hood. The default fs.inotify.max_user_instances=128 on stock Ubuntu is comfortably below what the extension needs. Raise it on the node, delete the pods, done:

sudo sysctl -w fs.inotify.max_user_instances=8192
sudo sysctl -w fs.inotify.max_user_watches=1048576
echo -e "fs.inotify.max_user_instances=8192\nfs.inotify.max_user_watches=1048576" | sudo tee /etc/sysctl.d/99-inotify.conf
kubectl delete pods --all -n logicapps-aca-ns

After that everything came up green, and envoy grabbed a MetalLB address on its own. Confirm:

az k8s-extension show -g <rg> --cluster-name <cluster> \
  --cluster-type connectedClusters --name logicapps-aca-extension \
  --query provisioningState -o tsv          # -> Succeeded
kubectl get svc microsoft-app-environment-k8se-envoy -n logicapps-aca-ns   # EXTERNAL-IP from your pool

Step 5: Create a custom location

Turn on the custom-locations feature, then create the location that ties the cluster, extension, and namespace together:

az connectedk8s enable-features -n <cluster> -g <rg> \
  --features cluster-connect custom-locations \
  --custom-locations-oid $(az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query id -o tsv)

EXT_ID=$(az k8s-extension show -g <rg> --cluster-name <cluster> \
  --cluster-type connectedClusters --name logicapps-aca-extension --query id -o tsv)
CC_ID=$(az connectedk8s show -g <rg> -n <cluster> --query id -o tsv)

az customlocation create \
  --resource-group <rg> --name <custom-location> \
  --location <region> --host-resource-id $CC_ID \
  --namespace logicapps-aca-ns --cluster-extension-ids $EXT_ID

One thing we tripped on: the extension type isn't offered in every Azure region. It's registered in eastus, westus, westeurope, and a handful of others, but not eastus2 at the time of writing. The connectedCluster resource's region is independent of where the node actually runs, so pick a supported one here.

Step 6: Create the connected environment

CL_ID=$(az customlocation show -g <rg> -n <custom-location> --query id -o tsv)

az containerapp connected-env create \
  --resource-group <rg> --name <env-name> \
  --location <region> --custom-location $CL_ID

Because MetalLB already put an EXTERNAL-IP on the envoy LoadBalancer service, the platform picks it up automatically. --static-ip is only needed if you went the NodePort + external LB route in Step 2, in which case you pass your LB's VIP here.

Step 7: Configure cluster DNS

App hostnames like *.<env>.<region>.k4apps.io need to resolve to the Envoy ingress from inside the cluster. On AKS or OpenShift, az containerapp arc setup-core-dns handles this. RKE2 isn't a supported distro on that command yet, so it's manual, but it's a small manual.

The extension already writes the correct rewrite and forward rules into a coredns-custom ConfigMap. What's missing is CoreDNS mounting that ConfigMap and importing it from the Corefile.

We tried the direct route first: patch the Corefile ConfigMap, edit the Deployment to add the volume, restart. It works, right up until the next rke2-server restart. RKE2's helm controller re-renders both objects from the chart and wipes your changes. The right way is a HelmChartConfig. The rke2-coredns chart exposes extraConfig (config outside the default zone block) and extraVolumes/extraVolumeMounts, which is exactly what we need:

# /var/lib/rancher/rke2/server/manifests/rke2-coredns-config.yaml
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: rke2-coredns
  namespace: kube-system
spec:
  valuesContent: |-
    extraConfig:
      import:
        parameters: /etc/coredns/custom/*.server
    extraVolumes:
      - name: custom-config-volume
        configMap:
          name: coredns-custom
          optional: true
    extraVolumeMounts:
      - name: custom-config-volume
        mountPath: /etc/coredns/custom

Drop the file in /var/lib/rancher/rke2/server/manifests/, or kubectl apply -f it (the helm controller watches both). Within a minute CoreDNS redeploys with the mount and the top-level import. This time it survives restarts and RKE2 upgrades because the chart is now the source of truth.

To verify, run nslookup test.<env-domain> from a throwaway pod. You should get back the microsoft-app-environment-k8se-envoy-internal ClusterIP.

One last DNS thing: a kube-dns alias. The Logic Apps platform locates cluster DNS by looking for a Service named kube-dns in kube-system. That's the convention on AKS, K3s, kubeadm, and most other distros. RKE2 uses rke2-coredns-rke2-coredns and doesn't ship the alias, so the platform can't find DNS. Symptom: revision calls come back as 502s. Fix: create the alias.
apiVersion: v1
kind: Service
metadata: { name: kube-dns, namespace: kube-system, labels: { k8s-app: kube-dns } }
spec:
  selector: { k8s-app: kube-dns }
  ports:
    - { name: dns, port: 53, protocol: UDP, targetPort: 53 }
    - { name: dns-tcp, port: 53, protocol: TCP, targetPort: 53 }
It's a plain Service. Nothing about it gets templated or overwritten, so it just stays put across reconciles and upgrades.

Step 8: Create and deploy a Logic App

Plumbing's out of the way. In the portal, create a new Logic App (Standard) with the Hybrid hosting option, point it at your connected environment, wire storage up to your SMB share, and create. Author the workflow the way you always would. The runs will execute on your RKE2 cluster instead of in Azure.

Troubleshooting: the RKE2 things we hit

Symptom	Cause & fix
Test `LoadBalancer` / envoy stays `<pending>`	No LB provider on the cluster. Install MetalLB (Step 2). RKE2 ships no ServiceLB.
Runtime pods `CrashLoopBackOff` with `inotify instances ... reached`	Node `fs.inotify.max_user_instances` too low. Raise it to 8192 and restart the pods (Step 4).
Revision invoke returns 502	Platform can't find a `kube-dns` Service; RKE2's CoreDNS is under a different name. Add the alias (Step 7).
App hostnames don't resolve inside the cluster	CoreDNS isn't loading `coredns-custom`. Apply the `HelmChartConfig` (Step 7).
Extension type "not registered in region"	The Arc cluster is in an unsupported region. Reconnect it in a supported one; it's independent of where the node runs (Step 5).
Cluster shows Arc Offline after a reboot; `azure-arc` pods `Unknown`	Stale pods from an ungraceful stop. `kubectl delete pods --all -n azure-arc --force` and they'll recreate and reconnect.

References

Governance Is the New Bottleneck: What Agent 365 Means for Admins ?

Surya_Narayana — Thu, 23 Jul 2026 01:48:45 GMT

Hi all , following up on my last post about token limits, I wanted to write about something that's been on my mind a lot lately: the sheer number of agents quietly showing up across our tenant. Not just the ones we built deliberately in Copilot Studio, but ones people spun up in Power Platform, ones connected through Teams, and a few I genuinely couldn't trace back to an owner when I went looking. That's the moment this topic stopped being theoretical for me.

For the last couple of years, the Microsoft AI conversation was mostly about capability -what can Copilot do, which model is better, how do I write a good prompt. That conversation hasn't gone away, but a second one has caught up to it fast: who's actually watching all of this. Microsoft's own 2026 Work Trend Index makes the shift explicit this isn't about saving a few minutes in Outlook anymore, it's about organizations redesigning how work gets divided between people and agents. And the moment agents start acting semi-independently across your tenant, "how many do we have, and what are they allowed to touch" becomes a real operational question, not a hypothetical one.

That's exactly the gap Microsoft Agent 365 is built to close. It went generally available on May 1, 2026, alongside Microsoft 365 E7, and I think it's worth understanding properly especially if you're the one who ends up fielding the "wait, there's an agent doing what?" conversation.

What Agent 365 Actually Is (and Isn't)

The first thing worth clearing up: Agent 365 doesn't build agents. That's still Copilot Studio's job, or Foundry, or whatever platform your team is using. Agent 365 is the layer that sits on top of all of that it's a control plane, not a construction tool. Think of it less like "another AI product" and more like the admin and security backbone that was honestly missing from the picture until now.

Microsoft frames it around three pillars: observe, govern, and secure. In practice, that means every agent in your tenant whether it was built in Copilot Studio, imported from AWS or Google Cloud, or even running locally on someone's Windows machine gets registered, gets its own identity through Microsoft Entra, and becomes something you can actually see and act on instead of just hoping it's behaving.

That identity piece is the part I think gets underrated. Each agent gets its own Entra Agent ID, the same way a human user would. That's a meaningful shift it means conditional access policies, auditing, and compliance tooling that already exist for people can now extend to agents instead of treating them as some invisible background process.

Why This Matters Right Now

Here's the honest version of what's been happening across a lot of organizations, including bits of what I've seen firsthand: agent creation has gotten easy. Almost too easy. Between Copilot Studio, Power Platform, and now agentic mode built directly into Word, Excel, and PowerPoint, it doesn't take much for someone in a business unit to spin up something that's technically an AI agent with access to real data without IT or security ever being looped in.

Microsoft has been fairly direct about this risk themselves, which I appreciated seeing in writing rather than just implied: the speed of agent development shows real value, but without guardrails, that pace turns into blind spots, lower ROI, and genuine security exposure. That's not vendor fear-mongering, that's just what happens when adoption outpaces oversight in any technology, and agents are no exception.

What makes this particular moment different from past "shadow IT" waves is that agents don't just store or move data they can act on it. An agent with the wrong scope isn't just a compliance footnote, it's something that could send an email, modify a file, or trigger a workflow on its own. That's a different risk category than an unsanctioned spreadsheet sitting in someone's OneDrive.

What You Actually Get With Agent 365

A few capabilities stood out to me as genuinely useful rather than just checkbox governance:

The overview dashboard gives you a real-time view of your entire agent fleet total registered agents, active users, connected platforms, runtime hours, and risk signals, all in one place. Before this, getting even a rough headcount of "how many agents exist in our tenant" was a manual, frustrating exercise.

Registry sync extends that visibility beyond Microsoft's own tools. It can pull in agents built on AWS Bedrock and Google Cloud, so you're not stuck with three different governance stories depending on where an agent happens to live. For organizations that are realistically never going to be 100% single-vendor, that matters.

Lifecycle actions install, publish, block, unblock, delete, reassign ownership are now available directly from the registry. That's a big deal operationally. Before, tracking down who owned a rogue or abandoned agent could turn into an actual investigation. Now it's a few clicks.

Local agent controls through Defender and Intune are rolling in too, extending management down to agents running on individual Windows endpoints, not just cloud-hosted ones. Given how much agent activity is starting to happen at the device level, this closes a gap that would've otherwise been a blind spot.

Conditional access for agents, through Entra, means you can apply the same kind of dynamic, granular access policies to agents that you'd apply to a human user which is really the whole philosophical shift Agent 365 represents: agents aren't a separate, ungoverned category anymore, they're first-class identities in your tenant.

What This Means for Admins, Practically

If you're managing a tenant with any real Copilot or agent activity, here's where I'd actually start:

Don't wait for "full autonomy" to engage. It's tempting to think governance can wait until agents are doing something more dramatic than they are today. Microsoft's own guidance pushes against that the advice is to establish visibility and guardrails early, while adoption is still accelerating, not after.

Get a real inventory first. Before writing new policies, it's worth just knowing what already exists. I'd genuinely bet most tenants have more agents running than the admin team could name off the top of their head. The overview dashboard is the fastest way to close that gap.

Loop in more than just IT. Agent 365 licensing and controls touch the M365 admin center, Entra, Defender, Purview, and Intune which means this isn't a single-team rollout. Security, compliance, and helpdesk all need to understand what's changing, especially the distinction between Frontier (preview, no production SLA) and GA (production-ready, supported).

Understand the licensing model before you scope a rollout. Agent 365 is licensed per human user — the person who manages, sponsors, or is served by an agent rather than per agent. It's available standalone at $15 per user per month, or bundled into Microsoft 365 E7. Worth mapping that against your actual agent-using population rather than assuming it's a flat cost per bot.

Treat this as incremental, not a one-time setup. Microsoft has said plainly that Agent 365's capabilities will keep evolving as adoption patterns and governance models mature. This isn't a project you finish and close out it's closer to how you'd think about identity and access management generally: ongoing, not a one-time rollout.

The Bigger Shift Underneath All This

What I find genuinely interesting about Agent 365 is what it signals about where Microsoft thinks this is all heading. They're not just selling a better Copilot anymore they're positioning Microsoft 365 as the place where AI-driven work gets governed, regardless of which vendor's model or platform an agent actually runs on. Whether that's the right long-term answer for every organization is a fair thing to debate. But the underlying problem it's solving that agents were multiplying faster than anyone's ability to see or control them is real, and I don't think it's specific to Microsoft shops.

If your organization is building agents in Copilot Studio, experimenting with Foundry, or even just watching Copilot's agentic mode quietly take on more autonomous work in Word and Excel, this is worth getting ahead of. The teams that treat agent governance as a foundational layer now are going to have a much easier time scaling adoption later than the ones who bolt it on after something goes wrong.

Curious whether others are already rolling out Agent 365, or still in the "let's figure out how many agents we actually have" phase I suspect a lot of us are somewhere in between. Would love to hear how your organization is approaching this.

Cheers, and happy reading.

Surya Vennapusa-MCT

Reminder: Path to Production for Agents Webinar Series Starts Next Week

brauerblogs — Thu, 23 Jul 2026 00:15:07 GMT

Next week, join Microsoft for the Path to Production for Agents webinar series—a free, six-session technical training designed to help organizations move from AI experimentation to secure, scalable, production-ready agent solutions. The series takes place July 27–28 and is aimed at architects, technical leaders, engineers, and AI practitioners looking to operationalize AI at enterprise scale.

Across six expert-led sessions, you'll learn how to:

Establish governance foundations for AI at scale
Design production-ready AI platforms and landing zones
Build reliable multi-agent architectures
Implement AgentOps practices for deployment and observability
Secure and govern AI systems
Optimize performance, cost, and scalability

Each session includes proven Microsoft architecture patterns, real-world engineering guidance, and practical techniques you can apply immediately to accelerate your path from prototype to production.

Register today: Path to Production for Agents Registration

Don't miss this opportunity to gain the knowledge and frameworks needed to confidently deploy production-grade AI agents at scale. We look forward to seeing you next week!

Upcoming July 2026 Microsoft 365 Champion community call

JessieHwang — Wed, 22 Jul 2026 22:43:57 GMT

Join our monthly calls to learn more about driving user enablement of Microsoft 365 services, including Microsoft 365 Copilot. All are welcome. Our next call is July 28, 2026, where we'll dive into Teams Meeting controls.

Please note that our community calls are in the Teams webinar format, so you must register to receive the link to join. The join link will be sent to you in email with your webinar registration confirmation. The calls start at 5 minutes past the hour for both sessions (at 8:05 AM and 5:05 PM PT) and end at the top of the hour (9:00 AM and 6:00 PM PT, respectively).

The on-demand recording will be available on our Driving Adoption > Events pages, as well as on our Microsoft Community Learning YouTube channel. While our calls are open to everyone, you must be a member of the Microsoft 365 Champion Program in order to access the presentation materials - the access link is in the initial welcome email and the monthly newsletter emails sent the week before the community calls.

If you have not yet joined our Champion community, sign up here to get access to the monthly newsletters, calendar invites, and program assets (e.g., the presentations).

Is there a topic you want us to bring? Share your feedback here: https://aka.ms/Microsoft365ChampionCallFeedback.

REMINDER: Our community calls take a break in August and resume in September.

Azure Local expands SAN capabilities with iSCSI support

saniya0307 — Wed, 22 Jul 2026 22:15:00 GMT

As organizations modernize datacenters and accelerate migration from legacy virtualization platforms, flexibility in storage architecture has become a key requirement. Customers increasingly want to reuse existing storage investments, scale infrastructure independently, and choose the connectivity model that best fits their environment.

Building on the general availability of Fibre Channel (FC) SAN support, Azure Local now introduces iSCSI SAN integration, extending disaggregated architecture support to IP-based storage networks. With support for both Fibre Channel and iSCSI, Azure Local provides customers greater flexibility in how they modernize and scale their infrastructure while maintaining an Azure-consistent management experience.

Expanding disaggregated infrastructure

iSCSI support enables organizations to:

Leverage existing IP-based storage networks
Deploy cost-efficient disaggregated architectures without FC dependency
Scale compute and storage independently
Maintain an Azure-consistent management experience

Architecture and deployment

Azure Local supports 6-adapter configurations to balance cost, performance, and resiliency:

6 adapters: enhanced performance and redundancy with dedicated iSCSI paths.

Today, iSCSI follows a manual configuration flow during deployment.

Azure Local Deployment

Azure Local supports two SAN deployment approaches:

Hybrid deployments (S2D + SAN)

Customers can attach external SAN storage to existing Azure Local deployments while continuing to use Storage Spaces Direct (S2D) for platform storage. This approach enables organizations to incrementally adopt SAN while reusing existing storage investments.

Disaggregated deployments (SAN-only)

Customers can also deploy Azure Local using external SAN storage as the primary storage platform for both infrastructure and workloads. This enables:

Independent scaling of compute and storage
Fibre Channel or iSCSI connectivity
Larger-scale infrastructure deployments
Connected and disconnected deployment models
Manage rising disk costs associated with hyperconverged architectures

Additionally, customers can create local availability zones to align VM placement with physical infrastructure boundaries and support more granular workload placement. The deployment also validates connected SAN arrays against the supported vendor ecosystem, helping ensure a streamlined and fully supported experience.

Accelerating infrastructure modernization

Azure Migrate now supports migration to Azure Local deployments that use external SAN storage, including NTFS-based volumes. This allows organizations to modernize compute infrastructure while preserving existing storage investments.

Customers can:

Reuse existing SAN arrays and operational processes
Minimize disruption during modernization projects
Retain familiar storage architectures while adopting Azure Local
Simplify migration from existing virtualization environments

What's next

iSCSI support represents another step in our broader vision for external storage on Azure Local. Our goal is to provide a comprehensive storage platform that spans deployment, operations, protection, and recovery.

Looking ahead, we are investing in:

Integration of iSCSI node configuration into cluster deployment to simplify the initial setup.
Business Continuity and Disaster Recovery (BCDR) for SAN-backed workloads, including replication, failover, and failback capabilities between two external SAN attached or disaggregated Azure local clusters.
Day-N storage management experiences that simplify monitoring, troubleshooting, and operational workflows.
Replication management capabilities that provide visibility into recovery readiness, replication health, and workload mobility across environments.
Expanding enterprise storage vendors ecosystem for Azure Local, helping customers adopt Azure Local while preserving their existing storage investments.

Together, these investments will extend Azure Local beyond SAN connectivity and deployment to deliver a unified storage management experience across a broad ecosystem of enterprise storage solutions.

Summary

With iSCSI support, Azure Local now delivers a more complete SAN strategy—giving customers the flexibility to choose Fibre Channel or iSCSI, deploy hybrid or fully disaggregated architectures, and modernize infrastructure without abandoning existing storage investments.

As we continue to invest in SAN management, replication, and disaster recovery, Azure Local is evolving into a comprehensive platform for enterprise storage and infrastructure modernization—from edge deployments to sovereign-scale datacenters.