New blog articles in Microsoft Community Hub

mssql-python 1.5: Apache Arrow, sql_variant, and Native UUIDs

DavidLevy — Fri, 10 Apr 2026 19:00:00 GMT

We're excited to announce the release of mssql-python 1.5.0, the latest version of Microsoft's official Python driver for SQL Server, Azure SQL Database, and SQL databases in Fabric. This release delivers Apache Arrow fetch support for high-performance data workflows, first-class sql_variant and native UUID support, and a collection of important bug fixes.

pip install --upgrade mssql-python

Apache Arrow fetch support

If you're working with pandas, Polars, DuckDB, or any Arrow-native data framework, this release changes how you get data out of SQL Server. The new Arrow fetch API returns query results as native Apache Arrow structures, using the Arrow C Data Interface for zero-copy handoff directly from the C++ layer to Python.

This is a significant performance improvement over the traditional fetchall() path, which converts every value through Python objects. With Arrow, columnar data stays in columnar format end-to-end, and your data framework can consume it without any intermediate copies.

Three methods for different workflows

cursor.arrow() fetches the entire result set as a PyArrow Table:

import mssql_python conn = mssql_python.connect( "SERVER=myserver.database.windows.net;" "DATABASE=AdventureWorks;" "UID=myuser;PWD=mypassword;" "Encrypt=yes;" ) cursor = conn.cursor() cursor.execute("SELECT * FROM Sales.SalesOrderDetail") # Get the full result as a PyArrow Table table = cursor.arrow() # Convert directly to pandas - zero-copy where possible df = table.to_pandas() # Or to Polars - also zero-copy import polars as pl df = pl.from_arrow(table)

cursor.arrow_batch() fetches a single RecordBatch of a specified size, useful when you want fine-grained control over memory:

cursor.execute("SELECT * FROM Production.TransactionHistory") # Process in controlled chunks while True: batch = cursor.arrow_batch(batch_size=10000) if batch.num_rows == 0: break # Process each batch individually process(batch.to_pandas())

cursor.arrow_reader() returns a streaming RecordBatchReader, which integrates directly with frameworks that accept readers:

cursor.execute("SELECT * FROM Production.TransactionHistory") reader = cursor.arrow_reader(batch_size=8192) # Write directly to Parquet with streaming - no need to load everything into memory import pyarrow.parquet as pq pq.write_table(reader.read_all(), "output.parquet") # Or iterate batches manually for batch in reader: process(batch)

How it works under the hood

The Arrow integration is built directly into the C++ pybind11 layer. When you call any Arrow fetch method, the driver:

Allocates columnar Arrow buffers based on the result set schema
Fetches rows from SQL Server in batches using bound column buffers
Converts and packs values directly into the Arrow columnar format
Exports the result via the Arrow C Data Interface as PyCapsule objects
PyArrow imports the capsules with zero copy

Every SQL Server type maps to the appropriate Arrow type: INT to int32, BIGINT to int64, DECIMAL(p,s) to decimal128(p,s), DATE to date32, TIME to time64[ns], DATETIME2 to timestamp[us], UNIQUEIDENTIFIER to large_string, VARBINARY to large_binary, and so on.

LOB columns (large VARCHAR(MAX), NVARCHAR(MAX), VARBINARY(MAX), XML, UDTs) are handled transparently by falling back to row-by-row GetData fetching while still assembling the result into Arrow format.

Community contribution

The Arrow fetch support was contributed by @ffelixg. This is a substantial contribution spanning the C++ pybind layer, the Python cursor API, and comprehensive tests. Thank you, Felix Graßl, for an outstanding contribution that brings high-performance data workflows to mssql-python.

sql_variant type support

SQL Server's sql_variant type stores values of various data types in a single column. It's commonly used in metadata tables, configuration stores, and EAV (Entity-Attribute-Value) patterns. Version 1.5 adds full support for reading sql_variant values with automatic type resolution.

The driver reads the inner type tag from the sql_variant wire format and returns the appropriate Python type:

cursor.execute(""" CREATE TABLE #config ( key NVARCHAR(50) PRIMARY KEY, value SQL_VARIANT ) """) cursor.execute("INSERT INTO #config VALUES ('max_retries', CAST(5 AS INT))") cursor.execute("INSERT INTO #config VALUES ('timeout', CAST(30.5 AS FLOAT))") cursor.execute("INSERT INTO #config VALUES ('app_name', CAST('MyApp' AS NVARCHAR(50)))") cursor.execute("INSERT INTO #config VALUES ('start_date', CAST('2026-01-15' AS DATE))") cursor.execute("SELECT value FROM #config ORDER BY key") rows = cursor.fetchall() # Each value comes back as the correct Python type assert rows[0][0] == "MyApp" # str assert rows[1][0] == 5 # int assert rows[2][0] == date(2026, 1, 15) # datetime.date assert rows[3][0] == 30.5 # float

All 23+ base types are supported, including int, float, Decimal, bool, str, date, time, datetime, bytes, uuid.UUID, and None.

Native UUID support

Previously, UNIQUEIDENTIFIER columns were returned as strings, requiring manual conversion to uuid.UUID. Version 1.5 changes the default: UUID columns now return native uuid.UUID objects.

import uuid cursor.execute("SELECT NEWID() AS id") row = cursor.fetchone() # Native uuid.UUID object - no manual conversion needed assert isinstance(row[0], uuid.UUID) print(row[0]) # e.g., UUID('550e8400-e29b-41d4-a716-446655440000')

UUID values also bind natively as input parameters:

my_id = uuid.uuid4() cursor.execute("INSERT INTO Users (id, name) VALUES (?, ?)", my_id, "Alice")

Migration compatibility

If you're migrating from pyodbc and your code expects string UUIDs, you can opt out at three levels:

# Module level - affects all connections mssql_python.native_uuid = False # Connection level - affects all cursors on this connection conn = mssql_python.connect(conn_str, native_uuid=False)

When native_uuid=False, UUID columns return strings as before.

Row class export

The Row class is now publicly exported from the top-level mssql_python module. This makes it easy to use in type annotations and isinstance checks:

from mssql_python import Row cursor.execute("SELECT 1 AS id, 'Alice' AS name") row = cursor.fetchone() assert isinstance(row, Row) print(row[0]) # 1 (index access) print(row.name) # "Alice" (attribute access)

Bug fixes

Qmark false positive fix

The parameter style detection logic previously misidentified? characters inside SQL comments, string literals, bracketed identifiers, and double-quoted identifiers as qmark parameter placeholders. A new context-aware scanner correctly skips over these SQL quoting contexts:

# These no longer trigger false qmark detection: cursor.execute("SELECT [is this ok?] FROM t") cursor.execute("SELECT 'what?' AS col") cursor.execute("SELECT /* why? */ 1")

NULL VARBINARY parameter fix

Fixed NULL parameter type mapping for VARBINARY columns, which previously could fail when passing None as a binary parameter.

Bulkcopy auth fix

Fixed stale authentication fields being retained in the bulk copy context after token acquisition. This could cause Entra ID-authenticated bulk copy operations to fail on subsequent calls.

Explicit module exports

Added explicit __all__ exports from the main library module to prevent import resolution issues in tools like mypy and IDE autocompletion.

Credential cache fix

Fixed the credential instance cache to correctly reuse and invalidate cached credential objects, preventing unnecessary re-authentication.

datetime.time microseconds fix

Fixed datetime.time values incorrectly having their microseconds component set to zero when fetched from TIME columns.

The road to 1.5

Release	Date	Highlights
1.0.0	November 2025	GA release - DDBC architecture, Entra ID auth, connection pooling, DB API 2.0 compliance
1.1.0	December 2025	Parameter dictionaries, Connection.closed property, Copilot prompts
1.2.0	January 2026	Param-as-dict, non-ASCII path handling, fetchmany fixes
1.3.0	January 2026	Initial BCP implementation (internal), SQLFreeHandle segfault fix
1.4.0	February 2026	BCP public API, spatial types, Rust core upgrade, encoding & stability fixes
1.5.0	April 2026	Apache Arrow fetch, sql_variant, native UUIDs, qmark & auth fixes

Get started today

pip install --upgrade mssql-python

Documentation: github.com/microsoft/mssql-python/wiki
Release notes: github.com/microsoft/mssql-python/releases
Roadmap: github.com/microsoft/mssql-python/blob/main/ROADMAP.md
Report issues: github.com/microsoft/mssql-python/issues
Contact: mssql-python@microsoft.com

We'd love your feedback. Try the new Arrow fetch API with your data workflows, let us know how it performs, and file issues for anything you run into. This driver is built for the Python data community, and your input directly shapes what comes next.

Help Shape the Future of Microsoft 365: Join Research Sessions at Microsoft 365 Community Conference

JonJones_MSFT — Fri, 10 Apr 2026 18:06:00 GMT

One of the best ways to get value from the Microsoft 365 Community Conference isn’t just attending sessions, it’s helping shape what gets built next.

The Research sessions at Microsoft 365 Community Conference give attendees a rare, behind-the-scenes chance to collaborate directly with the Microsoft teams designing the products millions of people use every day. These sessions are designed for customers, practitioners, and IT professionals who want their real-world experiences to influence what’s coming next across Microsoft 365.

What to Expect

These aren’t traditional lectures or breakouts. Research sessions are small-group, interactive conversations designed to bring your voice into the product design process.

In a typical session, you can expect:

Spending dedicated time with Microsoft researchers (and sometimes partner team members)
Discuss scenarios drawn from real customer workflows
Review early ideas or prototypes and share what would (or wouldn’t) work in your environment
Offer candid feedback to help prioritize and refine future experiences

Topics That Matter to You

The Research sessions focus on some of the most widely used and fast-evolving Microsoft 365 experiences, including:

SharePoint
OneDrive
Microsoft Teams
Microsoft Planner
Microsoft Lists
Viva Engage

Whether you’re managing these tools at scale, supporting adoption, or building solutions on top of them, your perspective helps teams understand what’s working today and what needs to change next.

How to Participate

Research sessions are invite-only to keep the groups small and ensure everyone has time to contribute.

Here’s how it works:

Registered conference attendees will receive an email invitation to sign up for Research sessions.
The invitation includes short descriptions of each session and a brief signup form so you can indicate which topics you’re interested in.
Participants are required to complete a consent form and a non-disclosure agreement. Participation in Research sessions is optional. Completing the survey does not affect your ability to attend the conference if you choose not to participate.
Spots are filled first-come, first-served, so early registration is encouraged.

Be Part of What’s Next

The Microsoft 365 Community Conference is all about learning, connection, and community—and the Research sessions take that mission one step further. This is your opportunity to go beyond listening and actively contribute to the evolution of Microsoft 365.

If you’ve ever wanted to influence the tools you rely on every day, the Research sessions are one of the most meaningful ways to do it. Keep an eye out for the invitation, choose a session that matches your interests, and bring your real-world experience to the table.

Attendees of the research sessions must be registered attendees of the Microsoft 365 Community Conference.

The AI-powered partner: Winning in the Microsoft ecosystem

Richard-WorkSpan — Fri, 10 Apr 2026 17:45:16 GMT

About the author: Richard Jean-Felix, Cloud Marketplace Architect, WorkSpan has spent his career at the intersection of cloud marketplace strategy and partner operations, with hands-on experience helping organizations scale their presence on both AWS and Microsoft Marketplace. At WorkSpan, he works directly with partners navigating the operational complexity of Microsoft co-sell, from integrating leads in Partner Central to building the processes that turn marketplace listings into repeatable revenue. He's the person in the room who's actually done the work.
About WorkSpan: WorkSpan provides AI agents for sellers and partner managers through the WorkSpan.AI Marketplace and Co-sell Platform

For Sellers: WorkSpan's in‑CRM AI drives earlier, smarter co‑sell actions.
For Partner Managers: WorkSpan's AI‑powered insights help launch and scale Microsoft partnerships.

_________________________________________________________________________________________________________________________________________________________________

How AI is rewriting the rules of co-sell, Microsoft Marketplace success, and enterprise procurement — and why the window to act is now.

For years, success in Microsoft's partner ecosystem came down to relationships, hustle, and knowing the right people. Those things still matter. But the gap between partner organizations that are winning and those that are stalling has opened — and increasingly, the difference isn't effort, it's intelligence.

The volume of signals a modern partner leader is expected to act on — pipeline health, seller engagement, marketplace activity, incentive windows, account targeting, co-sell alignment — has grown faster than any team can process manually. At the same time, a seismic shift in how enterprise software is bought and sold is reshaping every go-to-market strategy. Cloud marketplaces are becoming the default procurement channel. AI is becoming the operating system of high-performing partnerships and selling with Microsoft's ecosystem is rewarding the prepared, the consistent, and the fast.

This guide brings together the most critical insights from across the Microsoft partner landscape — the marketplace mistakes that cost software companies millions, the signals Microsoft sellers act on, the future of enterprise procurement, and the AI capabilities becoming table stakes for partner leaders who intend to win.

Part 01 / The new procurement reality

Cloud marketplaces are becoming the default buying channel

For decades, enterprise software procurement followed a familiar path: a vendor sold directly to the customer, procurement teams negotiated contracts, finance approved the purchase, and software was deployed within the customer's infrastructure. That model is rapidly replaced.

Cloud marketplaces like Microsoft Marketplace are no longer simply listing directories. They have evolved into strategic procurement channels that align the interests of customers, cloud providers, and software vendors simultaneously.

The committed spend driver

Large enterprises frequently commit hundreds of millions of dollars to cloud providers through multi-year agreements. When customers purchase software through a cloud marketplace, that purchase often counts toward their cloud spend commitments, uses existing cloud budgets, and avoids adding new vendor contracts to finance's plate.

Procurement simplicity changes everything

Traditional enterprise procurement can take months: vendor onboarding, contract negotiation, security reviews, procurement approvals, payment processing. Cloud marketplaces streamline this entire process. Because the software vendor is already integrated with the cloud provider's billing infrastructure, procurement teams can often purchase using the same contract they already have with the cloud provider. For software vendors, this means faster sales cycles and dramatically reduced time-to-revenue. For customers, it means deploying solutions in days, not months.

The ecosystem reshaping partner relationships

Marketplaces introduce new collaboration opportunities: partners can bundle solutions together, participate in multiparty private offers, transact jointly, and align services with software purchases.

AI automation opportunity: AI can automate the monitoring of Marketplace performance metrics — pipeline health, private offer status, renewal windows, and Azure consumption contribution — surfacing next-best actions before opportunities slip. What once required manual reporting across multiple systems becomes a continuous, intelligent feed of actionable insight.

Part 02 / Common pitfalls

The 7 biggest mistakes software companies make with Microsoft Marketplace

Microsoft Marketplace has become one of the fastest-growing enterprise software procurement channels. Many companies struggle to gain traction — and in most cases, the problem isn't Marketplace itself. It's the strategy behind how it's used.

Mistake 01 — Treating Marketplace as a "listing requirement" Publishing a listing to satisfy a partner requirement — but never actively using it. Little internal awareness, minimal seller adoption, no real revenue impact. ✓ Fix: Treat your listing as a core sales asset integrated into every deal.

Mistake 02 — Waiting until the end of the deal to introduce Marketplace Introducing Marketplace only at procurement stage creates friction and stalled deals. The deal structure is already set, and changing it feels disruptive. ✓ Fix: Position Marketplace as a buying advantage from first contact.

Mistake 03 — Not enabling Microsoft sellers Without enablement, Microsoft sellers don't know what your solution does, which customers it fits, or how it drives Azure consumption — so they won't bring it to deals. ✓ Fix: Provide a one-page seller pitch, target profiles, and Azure architecture alignment.

Mistake 04 — Making private offers operationally difficult When creating a private offer requires multiple approval steps, manual calculations, and cross-team coordination, deals stall and sales teams avoid it. ✓ Fix: Automate private offer creation — it should be as easy as generating a quote.

Mistake 05 — Ignoring internal sales enablement If your own sellers don't understand compensation for Marketplace deals or see it as friction, they'll actively avoid it regardless of customer readiness. ✓ Fix: Ensure sales compensation neutrality and train teams on marketplace value.

Mistake 06 — Not tracking Marketplace performance Without visibility into pipeline influence, co-sell rates, and revenue flow, leadership can't justify investment and the program stalls from neglect. ✓ Fix: Track Marketplace pipeline, win rates, and Azure consumption as core revenue metrics.

Mistake 07 — Failing to build a repeatable Marketplace motion Celebrating a first Marketplace deal but never scaling beyond it. The real value comes from repeatability — automated offer creation, seller training, co-sell alignment, renewals, and upsell offers built into a consistent operating model. ✓ Fix: Think of Marketplace as an operational capability, not a transactional tool.

AI automation opportunity: AI can directly address the most painful of these mistakes. Automated private offer generation reduces Mistake 04 from a multi-day process to minutes. Intelligent seller enablement surfaces the right pitch and customer profile in context — eliminating Mistakes 03 and 05 without manual coordination. Performance dashboards powered by AI turn Mistake 06 into a continuous leadership advantage rather than a quarterly scramble.

Part 03 / The co-sell engine

How Microsoft sellers decide which partners to co-sell with

Microsoft's field organization includes thousands of account executives and cloud sellers working with enterprise customers across the globe. In theory, this presents a massive opportunity. Microsoft sellers prioritize only a small number of partners in their daily sales motions.

Does the solution drive Azure consumption? The single most important factor. Every Microsoft cloud seller is measured on Azure revenue growth. Solutions driving AI/ML workloads, data and analytics, security, or industry-specific Azure infrastructure receive the most attention.
Is the solution easy to sell? Microsoft sellers operate with aggressive targets and little time. Top partners provide a simple one-page field brief: value proposition, ideal customer scenario, Azure architecture, and Marketplace purchasing instructions.
Is the solution available through Microsoft Marketplace? Microsoft sellers strongly prefer solutions purchasable through Marketplace. Transactions simplify procurement and help customers apply purchases toward Azure consumption commitments — a win for the customer, Microsoft, and the partner.
Is the partner actively engaged in selling with Microsoft? Publishing a listing is not enough. Effective partners register opportunities in Partner Center, share deal updates with Microsoft account teams, and participate in joint customer meetings.
Does the partner have strong customer proof? Solutions with strong customer validation — case studies, referenceable deployments, measurable business outcomes — are much easier for sellers to recommend with confidence.
Is the partner easy to work with? Partners who respond quickly, provide clear pricing, simplify contracting through Marketplace, and support joint selling activities build trust over time.
Do Microsoft sellers know you exist? Even the best solution struggles if sellers aren't aware of it. Successful partners invest in seller briefings, joint webinars, and account planning sessions to actively build visibility.

AI automation opportunity: The most transformative AI application in co-sell is moving from "here's our content, go find it" to one where intelligence is delivered to the seller proactively: the right account, the right partner fit, the right "better together" message — all surfaced automatically in the flow of how sellers actually work. Partners that crack seller activation at scale build a structural advantage that's very hard for competitors to close.

Part 04 / The intelligence layer

The partner leader's attention problem is real and structural. A typical partner organization is simultaneously managing dozens to hundreds of active co-sell opportunities, seller relationships across Microsoft field teams, Marketplace offers with expiration dates, incentive programs with changing eligibility, and account targeting decisions that should be data-driven but rarely are.

Most partner teams are operating on instinct and heroics. Things fall through the cracks not because people aren't working hard — but because the volume of decisions requiring good information exceeds what's humanly possible to track. AI addresses this at the root: not by replacing the partner leader's judgment, but by ensuring that judgment is applied to the right things, at the right time, with the right context.

🔍 Pipeline intelligence — AI continuously monitors pipeline health, flags deals going cold before it's too late, scores accounts by fit based on historical win patterns, and surfaces at-risk opportunities automatically.

✍️ Content generation — AI generates targeted value propositions for specific verticals, drafts seller-ready one-pagers, creates account-specific "better together" narratives, and produces ROI examples grounded in real customer data.

⚡ Offer automation — AI automates private offer creation workflows, proactively surfaces renewal windows, and reduces time-to-offer from days to minutes.

🎯 Account targeting — AI identifies accounts that look like past wins, generates lookalike account lists, surfaces applicable incentives in context, and ensures the right partner-to-account fit reaches the right seller at the right moment.

📊 Unified reporting — AI connects co-sell data, Marketplace data, seller activation data, and partner relationship data into a single view of partnership health — enabling leaders to see around corners and catch at-risk relationships before QBRs.

🔄 Repeatability — AI transforms one-time Marketplace transactions into repeatable operational playbooks, automating renewals, surfacing upsell signals, and systematizing institutional knowledge.

Part 05 / The compounding return

The ecosystem intelligence layer: Where it all connects

Individual AI capabilities are valuable. But the real step-change comes when those capabilities are connected — when co-sell data, Marketplace data, seller activation data, and partner relationship data inform a unified view of partnership health.

Most partner organizations today operate with fragmented data: CRM in one place, partner portal data in another, Marketplace reporting somewhere else, and seller feedback captured nowhere. Every leadership meeting requires someone to manually pull everything together — and even then, the picture is incomplete.

Partner leaders who build a connected ecosystem intelligence layer gain the ability to see around corners — to know before a QBR that a key co-sell relationship is at risk, to catch a Marketplace renewal window before the customer's procurement cycle closes, to see that a particular vertical is outperforming and double down before the opportunity peaks.

This is the compounding return on AI investment in partnerships. The longer you run on connected data, the smarter your decisions get — and the harder it becomes for competitors operating on intuition to catch up.

AI turns co-sell from a relationship management problem into a performance management discipline. Partner leaders who make this shift stop asking "are we aligned with Microsoft?" and start asking, "what does our data say about where we win, where we stall, and what the next best action is?"

Conclusion

The window to build this advantage is now

The enterprise software buying process is evolving faster than most organizations are moving. Cloud marketplaces are rapidly becoming one of the most important channels for software procurement. Microsoft's selling programs reward partners who are prepared, consistent and responsive - and AI enables partners to meet those expectations at scale.

The partners building this capability today are already seeing the effects — in seller engagement, pipeline conversion, Marketplace performance, and the quality of their strategic conversations with Microsoft. The infrastructure to do this exists, and it doesn't require a multi-year transformation.

Success in the Microsoft ecosystem doesn't come from simply publishing a Marketplace listing or registering as a co-sell partner. It comes from building a structured, AI-powered go-to-market operation that turns every signal — every deal, every seller interaction, every Marketplace transaction — into compounding intelligence.

Those who adapt early and build strong Marketplace strategies, powered by AI, will be well positioned to capture the growing opportunity of this new procurement model.

Join us on April 28th for a live webinar to learn more and ask questions. Maximize selling with Microsoft and Marketplace ROI - Microsoft Marketplace Community. If you are unable to attend, the session will be recorded and available on demand via the same link.

Title Plan Update - April 10, 2026

anbordianu — Fri, 10 Apr 2026 17:34:47 GMT

📁April 10, 2026 - Title Plan Now Available

Access the latest Instructor-Led Training (ILT) updates anytime at http://aka.ms/Courseware_Title_Plan to ensure you're always working from the most current version.

📌 Reminder: To help you stay informed more quickly and consistently, we’ve moved to a weekly publishing cadence for the title plan. This means each update may include fewer changes but ensures you’re always up to date.

Introducing the 2026 Imagine Cup Top Launch Startup

StudentDeveloperTeam — Fri, 10 Apr 2026 17:24:08 GMT

Early momentum. Clear direction.

The Launch path highlights student founders who are at an earlier stage but already showing strong signals in how they are approaching what they are building.

L-Guard Ltd. stood out for how clearly the problem was defined, how intentionally the solution is taking shape, and the direction it is heading next.

As the Top Launch Startup, L-Guard Ltd. receives $50,000 USD along with continued visibility and support from Microsoft as they move their solution forward.

Meet the startup

L-Guard Ltd.: AI-powered road safety, built for real-time response

Rwanda

L-Guard Ltd. is addressing a critical gap in road safety across Africa, where many accident victims lose their lives not from the crash itself, but from delayed emergency response.

The startup has built an AI- and IoT-powered system that monitors vehicle activity, detects crashes in real time, and automatically alerts nearby hospitals and emergency responders. By combining sensor data with machine learning models on Azure, L-Guard transforms real-time vehicle signals into actionable emergency intelligence.

This shifts road safety from reactive response to proactive intervention, issuing risky driving warnings, detecting incidents as they happen, and ensuring that help is activated as quickly as possible, even in low-connectivity environments.

As the startup continues to move from pilot validation toward broader deployment, the focus is on strengthening reliability, expanding partnerships, and scaling across high-risk transport markets. By making timely rescue the standard, L-Guard is working to reduce preventable fatalities and bring more accountability to emergency response systems.

Helen Ugoeze Okereke – Growing up in Ebonyi State, Nigeria, Helen set out to become what she called a “computer wizard,” focused on building real solutions with technology. Today, she leads L-Guard’s vision and strategy, driven by a mission to use technology to save lives.

Ramadhani Wanjenja – With a background in embedded systems and intelligent hardware, Ramadhani leads the technical architecture of L-Guard. His personal experience surviving a motorcycle accident shaped the direction of the solution and its focus on immediate response.

Terry Manzi – Raised in Kigali, Terry brings a systems and operations mindset, leading software-hardware integration, deployment, and partnerships to ensure L-Guard works effectively in real environments.

Erioluwa Olowoyo – With a focus on product design and user experience, Erioluwa ensures L-Guard remains intuitive and accessible. His path into technology was self-driven, shaped by a commitment to building solutions that work for real users in real contexts.

What this represents

The Top Launch startup reflects what it means to build with intention from the start.

This is not about having everything finished. It is about identifying a real problem, building toward a solution, and continuing to move forward with clarity and purpose.

As L-Guard Ltd. continues to develop, their work highlights the impact student founders can have when they combine technical skill with lived experience and a clear mission.

Partner tools behind the build

Alongside mentorship and community, Imagine Cup startups gain access to tools that support how their solutions continue to take shape.

Through GitHub Education, teams use the Student Developer Pack, collaborate with AI-assisted coding through Copilot, and build on a platform used by developers around the world.

With Replit, teams build, test, and deploy using natural language in an AI-powered environment designed for rapid iteration.

Together, these tools give startups the flexibility and support to keep moving forward as they scale their solutions.

OneDrive Office Hours | April 2026

sophiapeng — Fri, 10 Apr 2026 17:19:42 GMT

Get ready for April’s OneDrive Customer Office Hours! This session creates space for open conversation around the latest updates and how they support the way you use your files every day. In this month’s session, we’ll walk through what’s new and open the floor for questions, feedback, and shared experiences.

Join us for our next call

Date: April 29, 2026

Time: 8:00 AM-9:00 AM Pacific Time (US & Canada)

Special Topic: Markdown in OneDrive with Lesha Bhansali & Stephen Rice

Register Today: OneDrive Office Hours | April 29

Our goal is to make it easier to work with Markdown files right where you store them. With built‑in support in OneDrive and SharePoint, you can open, read, and update Markdown files directly in your browser. Whether you’re reviewing notes, documentation, or shared files, everything stays simple and in one place. Anyone can join this one-hour webinar to ask us questions, share feedback, and learn more about the features we’re releasing soon and our roadmap. We can't wait to share, listen, and engage every month!

Note: Our monthly public calls are not an official support tool. To open support tickets, go to see Get support for Microsoft 365; distinct support for educators and education customers is available, too.

New way to register and watch on demand!

Go to: Microsoft OneDrive: Customer Office Hours – Microsoft Adoption to see upcoming sessions, to register and rewatch previous sessions!

Save the Calendar invite so you never miss a call: https://aka.ms/OfficeHoursCalendar

Each call is recorded and made available on demand shortly after.

Stay up to date on Microsoft OneDrive adoption on adoption.microsoft.com. Join our community to catch all news and insights from the OneDrive community blog. And follow us on X: @OneDrive. Thank you for your interest in making your voice heard and taking your knowledge and depth of OneDrive to the next level. and depth of OneDrive to the next level.

You can ask questions and provide feedback in the event Comments below and we will do our best to address what we can during the call.

😎 Register and join live: aka.ms/OneDriveOfficeHours.

April update: What’s new for partners in AI Business Solutions

JillArmourMicrosoft — Fri, 10 Apr 2026 17:11:25 GMT

Navigate to

News and Announcements | Incentives and Offers | Skilling and Events | Go-To-Market | Customer Success

News and Announcements

Introducing Microsoft 365 E7, the Frontier Suite built to empower customers to seize the agentic moment and drive Frontier Transformation. Microsoft 365 E7 and Microsoft Agent 365 will be generally available as of May 1, 2026. Read more in our blog post and explore Frontier Transformation resources for tools and strategies to move AI from experiment to enterprise-wide impact. You can also build capabilities for Microsoft 365 E7 and Agent 365 with our development guide, launch kit, and partner incentives.
The new Dynamics 365 Blog from Mike Morton, VP of Microsoft Dynamics Business Central, highlights findings from a Forrester Total Economic Impact™ (TEI) study, providing third-party validation you can use in customer conversations.
Expanded Immersion Briefings and assessment updates reinforce partners’ role in driving hands‑on adoption, not just selling. Discover the Expanded Scope + Copilot Studio for Customer Relationship Management (CRM) & Employee Resource Planning (ERP) Envisioning Workshops, with updated eligibility and refreshed assets for CRM, ERP, and Business Central. Stay informed with the AI Business Processes Partner Activities (ABPA) partner blog.  Access the ready-to-deliver Business Central Immersion Briefings Kit.
Explore AI Business Solutions & Security Partner eXperience (ASPX), a new Partner Center experience that brings Microsoft-aligned insights into partner workflows. ASPX provides a unified view of customer usage, licensing, renewals, security readiness, and incentive eligibility—aligned with the same models used by the Microsoft global sales force. Explore ASPX in Partner Center and identify priority customers and opportunities. Bring ASPX data directly to your sellers via API to reduce manual work. Learn more and level up by joining us for the Making ASPX real: Partner showcase community call on April 28, 2026.
The M365 Copilot, Copilot Chat, and Agents Activation Kits are purpose-built for sellers to confidently lead customer conversations and accelerate opportunities with corporate and small and medium-sized business (SMB) customers. Each kit includes a one-page seller guide and ready-to-send customer engagement resources, including a customer summary, IT readiness mini-guide, and pitch deck for each solution. Download the kits, use them in your next customer meeting or workshop, and bookmark the links for quick access to this content and future refreshes.
Microsoft is expanding in-market offers and investments to accelerate Copilot adoption throughout each part of customer organizations. Increase license coverage, build momentum beyond pilots, and position Microsoft 365 Copilot as the foundation for scalable AI productivity with a limited-time 30% Cloud Solution Provider (CSP) promotion that’s complementary to the existing 15% and 20% promotions. 
Month-to-month CSP billing flexibility is now available for Microsoft 365 Copilot Business and respective bundles.
We’re increasing the maximum license cap for eligible CSP promotions from 2,400 to 9,999 licenses to support high-volume deals and reduce friction. This update aligns guidance across Core, Security, and Copilot to accelerate upsell momentum.
The new, digital Microsoft Commercial Partner Incentives Guide delivers clear navigation, direct paths to engagement, and faster access to the most up-to-date guidance—all in one place. Now, you can search incentives by category, quickly confirm eligibility, and act swiftly on opportunities with live links that connect you to the next action. Sign in to access the new incentives guide.

Incentives and Offers

Accelerate Microsoft 365 E7 adoption with three-year and annual offers. Offer your customers a discounted rate for the new Frontier Suite. From May 1, 2026, to December 31, 2026, Small, Medium, Enterprise, and Corporate (SME&C) CSP customers worldwide can receive up to 15% off their Microsoft 365 E7 subscription. Offers vary by subscription length and seat purchase. Check out the offer FAQ for more details and next actions.
Save up to 35% with Microsoft 365 Copilot Business promotional offers, available to all CSP partners on annual commitments (monthly or annual billing) through June 30. Explore offer details and learn how to activate using the Microsoft 365 Copilot Business Launch Kit.
Tap into Microsoft 365 opportunities and deliver Secure AI Productivity Envisioning and Proof of Concept (PoC) engagements. These funded engagements help customers move forward with Microsoft 365 adoption—while positioning partners to drive incremental revenue ahead of upcoming pricing and packaging changes.  
Strengthen data security for Copilot at a lower cost with Microsoft Purview Suite for Microsoft 365 Copilot, which is available at 50% off through June 30, 2026. 
Explore new promotions for three-year CSP subscriptions. Transition customers from on-premises solutions or upgrade from Microsoft Office 365 with 10% discount promotions for new-to-E3 or new-to-E5 customers or Defender and Purview Suites on CSP three-year subscription terms through June 30, 2026.  
Lead a 90-minute interactive Security Immersion Briefing on Microsoft Defender for Business Premium and Microsoft Purview for Business Premium (50–300 licenses). Serve as a trusted security advisor and empower customers to tackle rising cybersecurity threats.  We’ve removed execution caps, so partners can now run unlimited briefings with up to 20 open at a time.  With new delivery options, distributors and resellers can collaborate or deliver directly—creating more flexibility and scale.

Skilling and Events

Explore AI Business Solutions Partner Events for curated virtual experiences focused on empowering partners with the insights, frameworks, and go-to-market strategies needed to drive AI adoption, deliver measurable customer outcomes, and accelerate revenue growth. Each event is tailored to specific partner audiences and designed to bridge vision and execution—equipping you with the knowledge and tools to confidently guide customers through their AI transformation journey.
Visit the Partner Skilling Hub for the latest training resources to attain Solutions Partner designations and earn specializations.  
Join us for the Making ASPX real: Partner showcase community call on April 28, 2026. Through real‑world examples, hear how partners are accelerating insights, improving execution, and realizing tangible business benefits using ASPX. This session is designed to inspire practical adoption and highlight proven best practices from the field. Register now (8:00 AM–9:00 AM PST [Americas/EMEA], 7:00 PM–8:00 PM PST [Asia])
Register for the LevelUp CSP technical bootcamp: Building secure, cost-controlled agent solutions on May 5, 2026. Learn how to assess customer readiness for intelligent agents, design secure and cost-controlled agent architectures, and confidently prepare customer environments for enterprise deployment. Gain clear guidance on positioning Agent 365 and first-party agents as scalable, repeatable solutions that meet customer security, governance, and financial expectations. Register now (8:00 AM–12:00 PM CET [EMEA], 8:00 AM–12:00 PM PST [Americas])
Watch Digital Airlift: Leading Frontier Transformation for CSP and SI Partners. Alex Zagury and Jeremy Welch hosted a special airlift digital partner event focused on leading Frontier Transformation. This session shows how to move beyond AI pilots and guide customers from AI experimentation to secure, governed, organization-wide adoption using Microsoft 365 E7—shifting the conversation from capabilities to consistent governance and measurable business outcomes that enable Frontier Transformation. Watch the session on demand.

Go-To-Market

Explore a curated portfolio of partner-ready, customizable marketing campaigns designed for partners to showcase how Microsoft AI can transform productivity, streamline processes, and drive measurable business outcomes. These campaigns provide ready-to-use messaging, assets, and guidance tailored to accelerate adoption of Microsoft 365, Microsoft 365 Copilot, and Dynamics 365—all grounded in secure, responsible AI principles. Visit Partner Marketing Center to explore AI Business Solutions campaigns, align to customer needs, and activate your next go-to-market motion. 
The Partner Center AI assistant now highlights which Microsoft 365 Business customers are approaching renewal—and which are strong candidates for Copilot Business—so your team can prioritize high-potential accounts, quickly identify eligible promotions, and turn renewals into targeted upsell opportunities with less manual effort. Sign in to Partner Center to access the AI assistant and request your Microsoft 365 Business renewal recommendations. 
The ASPX (AI Business Solutions and Security Partner eXperience) partner page equips you with ASPX guidance, including the walking deck and playbook, to drive AI Business Solutions plays across Copilot, Agents at Work, and Secure AI Productivity.

Customer Success

IDC Technologies revolutionizes higher education with Microsoft 365 Copilot: With strategic implementation and tailored workshops, IDC Technologies equipped a government education institution in the UAE to adopt, embrace, and thrive with Copilot. 
ITCG boosts an accounting firm’s precision with Microsoft 365 Copilot: ITCG created an integrated experience with Microsoft 365 Copilot that resulted in precision, streamlined workflows, and impactful business decisions for G K Choksi & Co, a well-known Chartered Accountant Firm based in Ahmedabad, Gujarat, India. 
Insight Canada empowers clients to maximize Microsoft 365 Copilot value: With a robust readiness assessment and customizable adoption pilot program, Insight Canada teaches clients how to customize Copilot and create value across industries. 
RSM reimagines the future of work: Leading professional services firm RSM acted as Customer Zero by globally scaling Microsoft 365 Copilot to transform operations, upskill teams, and act as a knowledge repository.

Click "follow" in the top right of the tag AI Business Solutions to stay updated on monthly AI Business Solutions partner news.

FinOps Hub Privado: Implementação Manual em Ambientes Corporativos

carolinamelo — Fri, 10 Apr 2026 16:51:20 GMT

O que é o FinOps Hub?

O FinOps Hub é uma solução open source da Microsoft, parte do FinOps Toolkit, que fornece uma base escalável e extensível para análise, governança e otimização de custos em nuvem. A solução centraliza dados de custos por meio de recursos de armazenamento e pipelines de dados, permitindo que as organizações padronizem a forma como analisam seus gastos na nuvem, adotando o modelo de dados FOCUS definido pela FinOps Foundation.

Além de disponibilizar relatórios e dashboards prontos, o FinOps Hub expõe os dados de custos de forma estruturada por meio do Azure Data Explorer ou do Microsoft Fabric, possibilitando a criação de relatórios customizados no Power BI e o desenvolvimento de soluções internas sob medida, de acordo com as necessidades do negócio.

Objetivo

Esse artigo visa orientar a implementação manual do acesso privado ao FinOps Hub após uma implementação pública, sem usar diretamente a opção de implementação privada oferecida pelo template.

Por que implementar o FinOps Hub com acesso privado de forma manual?

O template disponibilizado para a implementação do FinOps Hub permite que selecionemos duas formas de implementação:

Pública: forma de implementação mais simples e comum. Os recursos são provisionados com acesso público habilitado, sendo acessados por meio de seus endpoints públicos padrões do Azure. O controle de acesso é feito exclusivamente via permissões RBAC.
Privada: forma de implementação mais segura. Os recursos são provisionados com acesso público desabilitado e expostos apenas por meio de private endpoints, ficando acessíveis somente através de redes privadas que possuem conectividade com a rede onde esses endpoints estão implementados.

Embora a comunicação privada traga ganhos significativos de segurança, sua habilitação através do template do FinOps Hub introduz algumas implicações importantes no processo de implantação. O template, de forma automática, tenta:

Criar uma rede virtual (/26);
Provisionar Private DNS Zones;
Criar os registros DNS associados aos private endpoints;
Configurar os links entre as VNets e as zonas DNS.

Em muitas organizações, esse tipo de configuração é restrito por políticas internas. A criação de redes, zonas DNS e seus respectivos vínculos costuma ser responsabilidade de times especializados, que garantem a padronização e a aderência às diretrizes arquiteturais definidas pela empresa.

Em cenários onde a organização adota, por exemplo, uma topologia Hub & Spoke, com landing zones bem definidas para workloads e conectividade, é fundamental considerar alguns pontos adicionais:

Garantir que a rede criada para os private endpoints não tenha sobreposição (overlap) com outras redes existentes;
Assegurar que exista peering com a VNet de hub;
Integrar os registros DNS dos novos private endpoints às Private DNS Zones centralizadas;
Configurar corretamente os VNet links;
Garantir que a resolução de nomes esteja funcional no ambiente on-premises, permitindo o acesso ao FinOps Hub por meio de VPN, ExpressRoute ou outras formas de conectividade híbrida.

Esses fatores explicam por que, em muitos casos, o uso do template com configuração privada se torna inviável quando utilizado de forma isolada. Isso ocorre porque, frequentemente, o time de FinOps não é o mesmo time responsável por redes e DNS, possuindo permissão para implantar apenas parte dos recursos necessários.

Nesses cenários, a implementação privada exige a orquestração entre diferentes times, cada um atuando dentro de suas responsabilidades. Como resultado, algumas etapas que o template tenta executar automaticamente precisam ser realizadas manualmente, conforme descrito nas próximas seções.

Passo a Passo para Implementação

Faça a implementação do template seguindo o tutorial documentado, com “Networking” em modo público.
Assim que o template é implementado, alguns scripts de configuração são executados. Aguarde até que esses scripts sejam executados, ou seja, desapareçam do grupo de recursos onde o FinOps Hub foi implementado para seguir com os próximos passos. Exemplos dos “Deployment Scripts” que desaparecerão:

Crie uma rede de tamanho mínimo /26 – valide com o time de infraestrutura o espaçamento que pode ser utilizado. Dentro dessa rede implemente uma subrede:
- private-endpoint-subnet (/28) – subrede para os private endpoints.
Garanta a existência das Private DNS Zones: se seu ambiente possui zonas de DNS privadas centralizadas pré-configuradas. Garanta que as seguintes zonas já existam na subscription padrão para os seus recursos de rede:
- privatelink.blob.core.windows.net– para o Data Explorer e storage
- privatelink.dfs.core.windows.net– para o Data Explorer and o data lake hospedando os dados de FinOps data e configuração das pipelines
- privatelink.table.core.windows.net– para Data Explorer
- privatelink.queue.core.windows.net– para o Data Explorer
- privatelink.{location}.kusto.windows.net– para Data Explorer

Configurando a Storage Account com Acesso Privado

O primeiro recurso que a ser configurado será a Storage Account.

A configuração a seguir deve ser realizada duas vezes uma para o target sub-resource “blob” e outra para o target sub-resource “dfs”.
- Acesse “Networking” e a aba “Private Endpoints”
- Na aba “Basics” defina:
  - Subscription: mesma que o FinOps Hub foi implementado
  - Resource Group: mesmo que o FinOps Hub foi implementado
  - Name: use um nome que remeta ao recurso criado (private endpoint) e o sub recurso que ele fará exposição (blob/dfs). Exemplo: pe-storageaccount-blob/ pe-storageaccount-dfs
- Na aba “Resource” defina o target sub-resource para o qual a configuração está sendo feita. No caso, primeiro foi feito para “blob” e depois “dfs”.
- Na aba “Virtual Network”, deve-se selecionar a rede criada para os private endpoints bem como a subrede (private-endpoint-subnet).
- Na aba “DNS” selecione a private DNS zone na qual são realizados os registros do seus private endpoints. Quando estiver configurando o private endpoint para blob será privatelink.blob.core.windows.net e para dfs privatelink.dfs.core.windows.net.
- Adicione Tags caso seja necessário.
- Clique em “Review + create”.
- Ao final, dois private endpoints devem estar criados para a storage account:

Agora será necessário configurar o private endpoint usado pelo Data Factory para acessar a Storage Account.
- Acesse o Data Factory e clique em "Launch Studio".
- No menu lateral, selecione a opção "Manage" -> "Linked services":
- Selecione o serviço correspondente ao Azure Data Lake Storage Gen2.
- Em “Connect via integration runtime” substitua “AutoResolveIntegrationRuntime” por New+:
- Em “Integration runtime setup” selecione “Azure” -> Botão “Continue”:
- Na aba “Settings”, apenas altere o campo “Name”. Use algo como “ManagedIntegrationRuntime”. Os demais campos, mantenha como estão:
- Na aba “Virtual Network”, configure conforme a imagem abaixo:
- Por fim, na aba “Data flow runtime”, use as configurações abaixo:
- Clique em “Create”.
- Agora, voltando a página “Edit linked Service”, adicione o “Managed Private Endpoint”. Ele ficará em estado “Pending”.
- Clique em “Save”.
- Além disso, use a managed identity fornecida na página “Edit linked Service”, e lhe dê os seguintes acessos na storage account:
  - Reader
  - Storage Account Contributor
  - Storage Blob Data Contributor
- Por fim, acesse a seção “Networking” da Storage Account novamente, selecione o private endpoint criado pelo Data Factory e clique no botão “Approve”.

Configurando o Linked Service ftkRepo no Data Factory

Voltando na seção “Manage” do Azure Data Factory, será necessário editar o serviço “ftkRepo”. Nele, o único campo a ser alterado é o “Connect via integration runtime” usando o “ManagedIntegrationRuntime” criado na etapa de configuração da storage account.

Clique em “Save”.

Configurando o Azure Data Explorer com Acesso Privado

Acesse a seção “Networking” cluster do Data Explorer criado pelo script do FinOps Hub e acesse a aba “Private Endpoint Connections”
Clique em “+ Private Endpoint”.
Em “Basics” inclua um nome para o private endpoint e garanta que a região selecionada é a de implementação do seu FinOps Hub e da vnet criada para ele.
Na aba “Virtual Network” selecione a rede e subrede criadas para os private endpoints.
Na aba “DNS”, associar cada configuração a sua private DNS zone correspondente. Se essas zonas já existirem no ambiente e forem utilizadas de forma centralizada, usar as existentes. Caso contrário, a configuração poderá criar private DNS zones novas:
Novamente será preciso configurar o private endpoint gerenciado pelo Data Factory. Para isso, acesse “Managed” -> “Linked Services” e selecione o serviço referente ao Azure Data Explorer.
Nessa seção, o único campo a ser editado é o “Connect via integration runtime” usando o “ManagedIntegrationRuntime” criado na etapa de configuração da storage account.
Agora ainda em “Manage” no Data Factory, selecione a opção “Managed Private Endpoints”. Clique em “+New” -> “Azure Data Explorer (Kusto)”
Forneça um nome para o private endpoint, marque a subscription na qual o Data Explorer foi implementado e em "Cluster" selecione o recurso implementado via template do FinOps Hub:
Ao final, deve-se ter dois private endpoints configurados no Azure Data Explorer:

Ajustes Finais e Validações de Conectividade

Tanto para a Storage Account quanto para o Data Explorer, acesse as configurações de rede e altere o Public network access para “Disabled”.
Por fim, no seu servidor local de DNS, crie o registro para o Data Explorer apontando para o forwarder correto no Azure seja ele uma máquina virtual ou o inbound endpoint do Azure Private Resolver. Não use o domínio com privatelink, mas sim o padrão, no caso do Data Explorer a forma geral é <localização>.kusto.windows.net conforme o exemplo abaixo:

Ao configurar os apontamentos corretamente, será possível configurar os dashboards em máquinas locais/on-premises que tenham acesso privado ao ambiente Azure. Os dashboards precisam ser capazes de resolver a URL do cluster Data Explorer que é apontado como parâmetro do Dashboard em PowerBI.
Se desejar validar a comunicação antes de configurar o dashboard de Power BI, teste da sua máquina local a resolução da URI do Data Explorer implementado para o FinOps Hub, usando nslookup conforme o exemplo abaixo.

Service Mesh-Aware Request Tracing in AKS with Istio and Application Insights

Siddhi_Singh — Fri, 10 Apr 2026 16:37:58 GMT

Introduction

As platforms evolve toward microservice‑based architectures, observability becomes more complex than ever. In Azure Kubernetes Service (AKS), teams often rely on Istio to manage service‑to‑service communication and Azure Application Insights for application‑level telemetry.

While both are powerful, they operate at different layers and without deliberate configuration, correlating a single request across the service mesh and the application layer is not straightforward.

This blog walks through a practical, production‑ready solution to enable Istio (Envoy) access logging in AKS and correlate those logs with Application Insights telemetry, allowing engineers to trace a request end‑to‑end for faster troubleshooting and deeper visibility.

Platform Observability Context

The environment consists of:

AKS with managed Istio enabled
Envoy sidecars injected into application pods
Azure Application Insights SDK running inside workloads
Log Analytics as the centralized log store

Istio is responsible for traffic management, while Application Insights captures application‑level telemetry. The goal was to align these layers using a common trace context, without introducing additional tracing systems or custom agents.

Enabling Istio Access Logging at the Mesh Level

The first step is to ensure that Envoy access logs are emitted consistently across the service mesh. Istio provides the Telemetry API, which allows access logging to be enabled centrally without modifying individual workloads.

Apply a Telemetry resource in the Istio system namespace to enable Envoy access logging:

apiVersion: telemetry.istio.io/v1 kind: Telemetry metadata: name: mesh-access-logs namespace: aks-istio-system spec: accessLogging: - providers: - name: envoy

This configuration ensures that:

All Envoy sidecars emit access logs
Logging behavior is uniform across the mesh
The setup remains compatible with AKS managed Istio

Standardizing Envoy Logs Using EnvoyFilter

Access logs must be structured to be useful at scale. In AKS managed Istio, direct Envoy configuration is restricted, so EnvoyFilter is used to customize logging behavior.

EnvoyFilters are configured to:

Emit logs in structured JSON format
Write logs to /dev/stdout
Include trace and request correlation headers

To achieve full visibility, separate EnvoyFilters are applied for inbound and outbound sidecar traffic.

apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: json-access-logs namespace: aks-istio-system spec: configPatches: - applyTo: NETWORK_FILTER match: context: SIDECAR_INBOUND listener: filterChain: filter: name: envoy.filters.network.http_connection_manager patch: operation: MERGE value: typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager access_log: - name: envoy.access_loggers.file typed_config: "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog path: /dev/stdout log_format: json_format: timestamp: "%START_TIME%" method: "%REQ(:METHOD)%" path: "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%" response_code: "%RESPONSE_CODE%" response_flags: "%RESPONSE_FLAGS%" duration_ms: "%DURATION%" downstream_remote_address: "%DOWNSTREAM_REMOTE_ADDRESS%" x_request_id: "%REQ(X-REQUEST-ID)%" traceparent: "%REQ(TRACEPARENT)%" tracestate: "%REQ(TRACESTATE)%" x_b3_traceid: "%REQ(X-B3-TRACEID)%"

This configuration ensures inbound traffic logs contain both request metadata and correlation identifiers.

Configuring Outbound Envoy Access Logs

Outbound logging is required to observe downstream calls made by a service. Apply a second EnvoyFilter for outbound traffic:

apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: json-access-logs-outbound namespace: aks-istio-system spec: configPatches: - applyTo: NETWORK_FILTER match: context: SIDECAR_OUTBOUND listener: filterChain: filter: name: envoy.filters.network.http_connection_manager patch: operation: MERGE value: typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager access_log: - name: envoy.access_loggers.file typed_config: "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog path: /dev/stdout log_format: json_format: timestamp: "%START_TIME%" method: "%REQ(:METHOD)%" path: "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%" response_code: "%RESPONSE_CODE%" response_flags: "%RESPONSE_FLAGS%" duration_ms: "%DURATION%" downstream_remote_address: "%DOWNSTREAM_REMOTE_ADDRESS%" x_request_id: "%REQ(X-REQUEST-ID)%" traceparent: "%REQ(TRACEPARENT)%" tracestate: "%REQ(TRACESTATE)%" x_b3_traceid: "%REQ(X-B3-TRACEID)%"

Inbound and outbound logs now follow the same schema, enabling consistent querying and analysis.

Automating the Configuration with PowerShell

To standardize and repeat the setup across environments, wrap the configuration in a PowerShell script. The script should:

Validate the Istio system namespace
Apply the Telemetry resource
Apply inbound and outbound EnvoyFilters

$MeshRootNamespace = "aks-istio-system" $TelemetryName = "mesh-access-logs" $EnvoyFilterName = "json-access-logs" kubectl get ns $MeshRootNamespace --ignore-not-found $telemetryYaml | kubectl apply -f - $envoyFilterYaml | kubectl apply -f - $envoyFilterOutboundYaml | kubectl apply -f -

Log Ingestion into Azure Monitor

Because Envoy access logs are written to standard output:

AKS automatically collects them
Logs are ingested into Log Analytics
Data appears in the ContainerLogV2 table

No additional agents or custom log pipelines are required.

Aligning with Application Insights Telemetry

Application Insights uses W3C Trace Context, where the operation_Id represents the trace identifier. Since Envoy access logs capture the traceparent header, both systems expose the same trace ID.

This alignment allows service mesh logs and application telemetry to be correlated without changing application code.

Correlating Requests Using KQL

To analyze request flow:

Parse JSON access logs from ContainerLogV2
Extract the trace ID from traceparent
Join with Application Insights request telemetry

To validate end‑to‑end tracing, use Log Analytics to query Istio access logs collected in the ContainerLogV2 table. Since Envoy access logs include the traceparent header, the trace‑id embedded in it directly maps to the Application Insights operation_Id. By filtering istio-proxy logs on this trace‑id, it becomes possible to view the full Envoy request record for a specific application request and trace it across the service mesh and application layers.

KQL (filter Istio access logs using an Application Insights operation_Id)

let operationId = "<OperationID>"; // Replace with your actual operation_Id ContainerLogV2 | where TimeGenerated >= ago(24h) | where ContainerName == "istio-proxy" | where LogSource == "stdout" | where LogMessage startswith "{" | extend AccessLog = parse_json(LogMessage) | extend ExtractedOperationId = extract(@"00-([a-f0-9]{32})-", 1, tostring(AccessLog.traceparent)) | where ExtractedOperationId == operationId | project TimeGenerated, PodName, Method = tostring(AccessLog.method), Path = tostring(AccessLog.path), ResponseCode = toint(AccessLog.response_code), RequestId = tostring(AccessLog.x_request_id), TraceParent = tostring(AccessLog.traceparent), TraceState = tostring(AccessLog.tracestate), Authority = tostring(AccessLog.authority), RawLogMessage = LogMessage | order by TimeGenerated asc

Closing Thoughts

End‑to‑end request tracing in AKS is achieved by aligning service mesh logging and application telemetry around shared standards. By enabling structured Istio access logs and correlating them with Application Insights, platforms gain clear visibility into request flow across networking and application layers using Azure‑native tools.

This process scales well in managed Istio environments and provides meaningful observability without adding platform complexity.

Watch our video series: Getting started with the Copilot app

AliciaAl-Aryan — Fri, 10 Apr 2026 16:06:44 GMT

Hello, Insiders! We are Alicia Al-Aryan, Oby Omu, and Patrick Gan, program managers on the Microsoft 365 Copilot app team. We’re excited to share a video series we created in collaboration with our wider team that will show you how Copilot can help you at work.

From meetings to momentum: Learn how to use Copilot at work

This video series is inspired by real work. Instead of walking through features, each video focuses on common, everyday moments where a little clarity can make a big difference. You’ll see how Copilot can fit into workflows you encounter every day.

Download the Microsoft 365 app and let’s get started!

🛠️ Video 1 | Downloading the Microsoft 365 Copilot App

Constance shares a quick walkthrough of the app, showing you how to download it and start getting productive right away.

Presenter: Constance Gervais

🚀 Video 2 | From insights to impact: Turn action items into deliverables

Copilot can help you turn action items into deliverables that are polished, impactful, and executive-ready.

📊 Video 3 | From chaos to coordination: Gather vital information and deliver it fast

There’s no need to chase updates to ever-changing data and information alone. Use Copilot to gather and organize vital details and create content that makes it easy to digest and share with others.

🕒 Video 4 | Catch Up After Time Away

Coming back from out‑of‑office or a packed meeting calendar? Cora shows you how Copilot can help you quickly catch up, prepare, and re‑orient yourself for the workday ahead.

Presenter: Cora Chen

✨ Video 5 | Create with confidence using brand kits

Oby shows you how Copilot supports content creation with Brand Kits, helping you turn everyday ideas into on-brand materials.

Presenter: Oby Omu

🤝 Video 6 | Prepare for your next presentation

A beautiful PowerPoint deck won’t get you far if you’re not prepared for the presentation. Copilot can help you prepare and be ready with answers to likely questions you’ll get during your presentation.

Presenter: Ishita Sharma

Stay connected

We’ll continue building this series with additional short videos and deeper learning moments that can help you get more value from the Microsoft 365 Copilot app as part of your everyday work.

Continue the conversation by joining us in the Microsoft 365 community. Want to share best practices or join community events? Become a member!

For tips & tricks or to stay up to date on the latest news and announcements directly from the product teams, make sure to Follow or Subscribe to the Microsoft 365 community blog.

📚 Keep learning

Try the Microsoft 365 Copilot app and learn more ways to be productive.
Dig deeper into real-world Microsoft 365 app scenarios with our webinar series.
Find tools for Microsoft 365 Copilot Chat, Microsoft 365 Copilot, and agent deployment and adoption that deliver value and employee satisfaction.
Learn how to use the Microsoft 365 Copilot app from Microsoft Support.
Follow @Copilot on X.
Follow @MicrosoftLoop on X.
Join the "Microsoft Loop Community" public group on LinkedIn.
Follow the Microsoft 365 public roadmap.

Learn about the Microsoft 365 Insider program and sign up for the Microsoft 365 Insider newsletter to get the latest information about Insider features in your inbox once a month!

How to Ingest Microsoft Intune Logs into Microsoft Sentinel

PaulineMbabu — Fri, 10 Apr 2026 16:00:00 GMT

For many organizations using Microsoft Intune to manage devices, integrating Intune logs into Microsoft Sentinel is an essential for security operations (Incorporate the device into the SEIM). By routing Intune’s device management and compliance data into your central SIEM, you gain a unified view of endpoint events and can set up alerts on critical Intune activities e.g. devices falling out of compliance or policy changes. This unified monitoring helps security and IT teams detect issues faster, correlate Intune events with other security logs for threat hunting and improve compliance reporting. We’re publishing these best practices to help unblock common customer challenges in configuring Intune log ingestion. In this step-by-step guide, you’ll learn how to successfully send Intune logs to Microsoft Sentinel, so you can fully leverage Intune data for enhanced security and compliance visibility.

Prerequisites and Overview

Before configuring log ingestion, ensure the following prerequisites are in place:

Microsoft Sentinel Enabled Workspace: A Log Analytics Workspace with Microsoft Sentinel enabled; For information regarding setting up a workspace and onboarding Microsoft Sentinel, see: Onboard Microsoft Sentinel - Log Analytics workspace overview. Microsoft Sentinel is now available in the Defender Portal, connect your Microsoft Sentinel Workspace to the Defender Portal: Connect Microsoft Sentinel to the Microsoft Defender portal - Unified security operations.
Intune Administrator permissions: You need appropriate rights to configure Intune Diagnostic Settings. For information, see: Microsoft Entra built-in roles - Intune Administrator.
Log Analytics Contributor role: The account configuring diagnostics should have permission to write to the Log Analytics workspace. For more information on the different roles, and what they can do, go to Manage access to log data and workspaces in Azure Monitor.

Intune diagnostic logging enabled: Ensure that Intune diagnostic settings are configured to send logs to Azure Monitor / Log Analytics, and that devices and users are enrolled in Intune so that relevant management and compliance events are generated. For more information, see: Send Intune log data to Azure Storage, Event Hubs, or Log Analytics.

Configure Intune to Send Logs to Microsoft Sentinel

Sign in to the Microsoft Intune admin center.
Select Reports > Diagnostics settings. If it’s the first time here, you may be prompted to “Turn on” diagnostic settings for Intune; enable it if so. Then click “+ Add diagnostic setting” to create a new setting:
Microsoft Intune Diagnostics settings page – Add diagnostic settings.
- Select Intune Log Categories. In the “Diagnostic setting” configuration page, give the setting a name (e.g. “Microsoft Sentinel Intune Logs Demo”). Under Logs to send, you’ll see checkboxes for each Intune log category. Select the categories you want to forward. For comprehensive monitoring, check AuditLogs, OperationalLogs, DeviceComplianceOrg, and Devices. The selected log categories will be sent to a table in the Microsoft Sentinel Workspace.
  Microsoft Intune Diagnostics settings page – Log categories.
Configure Destination Details – Microsoft Sentinel Workspace. Under Destination details on the same page, select your Azure Subscription then select the Microsoft Sentinel workspace.

Microsoft Intune Diagnostics settings page - Destination details.
Save the Diagnostic Setting. After you click save, the Microsoft Intune Logs will will be streamed to 4 tables which are in the Analytics Tier. For pricing on the analytic tier check here: Plan costs and understand pricing and billing.

Microsoft Intune Diagnostics settings page – Saved Diagnostic settings.

Verify Data in Microsoft Sentinel.

After configuring Intune to send diagnostic data to a Microsoft Sentinel Workspace, it’s crucial to verify that the Intune logs are successfully flowing into Microsoft Sentinel. You can do this by checking specific Intune log tables both in the Microsoft 365 Defender portal and in the Azure Portal. The key tables to verify are:

IntuneAuditLogs
IntuneOperationalLogs
IntuneDeviceComplianceOrg
IntuneDevices

Microsoft 365 Defender Portal (Unified)

Azure Portal (Microsoft Sentinel)

1. Open Advanced Hunting: Sign in to the https://security.microsoft.com (the unified portal). Navigate to Advanced Hunting.
– This opens the unified query editor where you can search across Microsoft Defender data and any connected Sentinel data.

2. Find Intune Tables: In the Advanced hunting Schema pane (on the left side of the query editor), scroll down past the Microsoft Sentinel Tables. Under the LogManagement Section Look for IntuneAuditLogs, IntuneOperationalLogs, IntuneDeviceComplianceOrg, and IntuneDevices in the list.

Microsoft Sentinel in Defender Portal – Tables

1. Navigate to Logs: Sign in to the https://portal.azure.com and open Microsoft Sentinel. Select your Sentinel workspace, then click Logs (under General).

2. Find Intune Tables: In the Logs query editor that opens, you’ll see a Schema or tables list on the left. If it’s collapsed, click >> to expand it. Scroll down to find LogManagement and expand it; look for these Intune-related tables: IntuneAuditLogs, IntuneOperationalLogs, IntuneDeviceComplianceOrg, and IntuneDevices

Microsoft Sentinel in Azure Portal – Tables

Querying Intune Log Tables in Sentinel – Once the tables are present, use Kusto Query Language (KQL) in either portal to view and analyze Intune data:

Microsoft 365 Defender Portal (Unified)

Azure Portal (Microsoft Sentinel)

In the Advanced Hunting page, ensure the query editor is visible (select New query if needed). Run a simple KQL query such as:

IntuneDevice | take 5

Click Run query to display sample Intune device records. If results are returned, it confirms that Intune data is being ingested successfully. Note that querying across Microsoft Sentinel data in the unified Advanced Hunting view requires at least the Microsoft Sentinel Reader role.

Microsoft Sentinel in the Microsoft Defender Portal - Advanced hunting query.

In the Azure Logs blade, use the query editor to run a simple KQL query such as:

IntuneDevice | take 5

Select Run to view the results in a table showing sample Intune device data. If results appear, it confirms that your Intune logs are being collected successfully. You can select any record to view full event details and use KQL to further explore or filter the data - for example, by querying IntuneDeviceComplianceOrg to identify devices that are not compliant and adjust the query as needed.

Microsoft Sentinel in the Azure Portal - Sentinel logs query.

Once Microsoft Intune logs are flowing into Microsoft Sentinel, the real value comes from transforming that raw device and audit data into actionable security signals.
To achieve this, you should set up detection rules that continuously analyze the Intune logs and automatically flag any risky or suspicious behavior. In practice, this means creating custom detection rules in the Microsoft Defender portal (part of the unified XDR experience) see [https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules] and scheduled analytics rules in Microsoft Sentinel (in either the Azure Portal or the unified Defender portal interface) see:[Create scheduled analytics rules in Microsoft Sentinel | Microsoft Learn].

These detection rules will continuously monitor your Intune telemetry – tracking device compliance status, enrollment activity, and administrative actions – and will raise alerts whenever they detect suspicious or out-of-policy events. For example, you can be alerted if a large number of devices fall out of compliance, if an unusual spike in enrollment failures occurs, or if an Intune policy is modified by an unexpected account. Each alert generated by these rules becomes an incident in Microsoft Sentinel (and in the XDR Defender portal’s unified incident queue), enabling your security team to investigate and respond through the standard SOC workflow. In turn, this converts raw Intune log data into high-value security insights: you’ll achieve proactive detection of potential issues, faster investigation by pivoting on the enriched Intune data in each incident, and even automated response across your endpoints (for instance, by triggering playbooks or other automated remediation actions when an alert fires).

Use this Detection Logic to Create a detection Rule
IntuneDeviceComplianceOrg | where TimeGenerated > ago(24h) | where ComplianceState != "Compliant" | summarize NonCompliantCount = count() by DeviceName, TimeGenerated | where NonCompliantCount > 3

Additional Tips: After confirming data ingestion and setting up alerts, you can leverage other Microsoft Sentinel features to get more value from your Intune logs. For example:
- Workbooks for Visualization: Create custom workbooks to build dashboards for Intune data (or check if community-contributed Intune workbooks are available). This can help you monitor device compliance trends and Intune activities visually.
- Hunting and Queries: Use advanced hunting (KQL queries) to proactively search through Intune logs for suspicious activities or trends. The unified Defender portal’s Advanced Hunting page can query both Sentinel (Intune logs) and Defender data together, enabling correlation across Intune and other security data. For instance, you might join IntuneDevices data with Azure AD sign-in logs to investigate a device associated with risky sign-ins.
- Incident Management: Leverage Sentinel’s Incidents view (in Azure portal) or the unified Incidents queue in Defender to investigate alerts triggered by your new rules. Incidents in Sentinel (whether created in Azure or Defender portal) will appear in the connected portal, allowing your security operations team to manage Intune-related alerts just like any other security incident.
- Built-in Rules & Content: Remember that Microsoft Sentinel provides many built-in Analytics Rule templates and Content Hub solutions. While there isn’t a native pre-built Intune content pack as of now, you can use general Sentinel features to monitor Intune data.

Frequently Asked Questions

If you’ve set everything up but don’t see logs in Sentinel, run through these checks:
1. Check Diagnostic Settings
  1. Go to the Microsoft Intune admin center → Reports → Diagnostic settings.
  2. Make sure the setting is turned ON and sending the right log categories to the correct Microsoft Sentinel workspace.
2. Confirm the Right Workspace
  1. Double-check that the Azure subscription and Microsoft Sentinel workspace are selected.
  2. If you have multiple tenants/directories, make sure you’re in the right one.
3. Verify Permissions
4. Make Sure Logs Are Being Generated
  1. If no devices are enrolled or no actions have been taken, there may be nothing to log yet.
  2. Try enrolling a device or changing a policy to trigger logs.
5. Check Your Queries
  1. Make sure you’re querying the correct workspace and time range in Microsoft Sentinel.
  2. Try a direct query like:
    IntuneAuditLogs | take 5
6. Still Nothing?
  1. Try deleting and re-adding the diagnostic setting.
  2. Most issues come down to permissions or selecting the wrong workspace.
How long are Intune logs retained, and how can I keep them longer?
1. The analytics tier keeps data in the interactive retention state for 90 days by default, extensible for up to two years. This interactive state, while expensive, allows you to query your data in unlimited fashion, with high performance, at no charge per query: Log retention tiers in Microsoft Sentinel.

We hope this helps you to successfully connect your resources and end-to-end ingest Intune logs into Microsoft Sentinel. If you have any questions, leave a comment below or reach out to us on X @MSFTSecSuppTeam!

The Microsoft 365 Community Conference Experience Starts with Community

JonJones_MSFT — Fri, 10 Apr 2026 15:15:20 GMT

At the Microsoft 365 Community Conference, the learning does not stop when a session ends. Some of the most meaningful moments happen between the keynotes, in shared conversations, hands on exploration, and spontaneous connection with others who are solving similar challenges.

This year in Orlando, we are creating more opportunities for the Microsoft 365 community to come together through interactive activations, informal meetups, creative experiences, and live product engagement inside the Microsoft Innovation Hub within the Expo Hall.

Here is a look at what you can expect throughout the week.

Women in Tech and Allies Lunch Discussion

Grab your lunch and network with peers, discuss progress, and focus on how we can continue to make the Microsoft ecosystem the best in the world for supporting women. All individuals are welcome regardless of gender for an open and compassionate conversation on allyship and inclusiveness.

The discussion will be hosted by Heather Cook, Principal Customer Experience PM and distinguished panelists including:

Vasu Jakkal, Corporate Vice President, Microsoft Security Business

Jaime Teevan, Chief Scientist & Technical Fellow

Lan Ye, Corporate Vice President, Microsoft Teams

Sumi Singh, Corporate Vice President, Microsoft Teams

Karuana Gatimu, Director, Customer Advocacy - AI & Collaboration, Microsoft

Kate Faaland, Program Manager of Data and AI, AvePoint

Celebrity meet-n-greet

Stop by the Microsoft Community News Desk on Tuesday from 2pm to 4pm right outside of the Expo Hall, for a special photo meet and greet with guest speakers and former WNBA athletes Chasity Melvin and Kia Vaughn. Snap a photo with these legendary pros at our on-site photobooth and celebrate the spirit of teamwork and leadership they bring to conversations on collaboration and the future of AI at this year’s Microsoft 365 Community Conference.

More Than Code: SharePoint Movie Premiere

Tuesday, April 21, 12:30 PM to 1:30 PM

Be among the first to watch More Than Code, a documentary styled short film honoring the global community behind SharePoint’s 25 year journey. Featuring voices from MVPs, customers, and Microsoft leaders, this film explores how connection, creativity, and collaboration helped turn a product into a movement that powers teamwork and knowledge sharing around the world today.

SharePoint 25th Birthday Celebration Panel

Tuesday, April 21, 5:00 PM to 6:30 PM

Join longtime community leaders and Microsoft experts as we celebrate 25 years of SharePoint.

From early on premises deployments to today’s AI powered experiences, this special birthday panel reflects on the moments, milestones, and people who helped shape SharePoint into the platform it is today, and what comes next.

Stick around after the discussion for birthday cake and photo moments with fellow community members.

Microsoft 365 Champions Community Meetup + Session

Join Karuana Gatimu for a Microsoft 365 Champions Community Meetup, where you can connect with peers and learn more about growing your AI and Microsoft skills while engaging with the product team.

Then, attend the separate Champions Program session on Tuesday, April 21 from 1:45 PM to 2:30 PM to learn how to build, nurture, and measure the success of your internal Champions program to drive Copilot and broader technology adoption.

Microsoft Global Community Initiative (MGCI)

The Microsoft Global Community Initiative (MGCI) will be onsite all week connecting organizers, speakers, board members, and regional leaders from across our global tech communities.

Meet up with Heather Cook, Principal Customer Experience PM, MGCI Board Members, and Regional Leaders on Tuesday at 4:15 PM to connect with the people powering Microsoft’s grassroots ecosystem, join the MGCI Roundtable on Wednesday at 1:30 PM to discover how MGCI and CommunityDays.org are transforming grassroots tech engagement. And don’t miss the MGCI Lightning Talk on the power of community and how local engagement can create global impact.

Stop by the Microsoft Innovation Hub to learn more about how MGCI supports community‑driven learning around the world.

MVP Presence at #M365Con26

Microsoft MVPs will be onsite all week bringing community insight directly into the Microsoft Innovation Hub inside the Expo Hall. Join us on Tuesday, April 21 at 5:00 PM for a special MVP Photo Opportunity with an executive sponsor in the Innovation Hub (Microsoft Booth). We will also be hosting an MVP Meetup during the event with more details to come. Stop by the booth or connect with Bryan Wofford to collect exclusive MVP swag available only onsite.

Reservable Podcast Room

Microsoft FTEs, MVPs, and community leaders can reserve time in the on-site Podcast Room at Microsoft 365 Community Conference to record interviews, podcast episodes, or social content. The space will be equipped with branded backdrops along with professional video and audio equipment to support high quality content creation. Complete the reservation form to request a time slot. Calendar invites will be sent once confirmed. Questions can be directed to Jonathan Jones.

Community News Desk + Interviews:

Stop by the Community News Desk to catch live conversations from across the ecosystem and explore opportunities for 1:1 executive and customer interviews taking place throughout the week inside the Microsoft Innovation Hub.

Community Meetups and Product Roundtables

Community meetups are informal, connection first gatherings where attendees can meet others who share a role, interest, or identity. These sessions are designed to bring people together in a relaxed environment to build relationships and exchange ideas.

Product roundtables offer a more focused space for discussion. In these small group conversations, attendees can share real world use cases, common pain points, and direct feedback with Microsoft teams and peers.

Please use this signup sheet to reserve a social meetup with your community.

Lightning Talks in the Microsoft Innovation Hub

Lightning Talks are quick, TED talk style sessions designed to deliver real world learnings fast. Stop by the Microsoft Innovation Hub within the Expo Hall for rapid insights from community experts and Microsoft teams, along with a few surprises throughout the week.

Explore the Microsoft Surface Device Bar

Visit the Microsoft Device Bar for an interactive, hands on experience with the latest Copilot+ PCs and Surface for Business devices.

You can engage with real world demos, explore Windows 11 and Copilot capabilities, and connect with Microsoft experts for live demonstrations, Q&A, and practical guidance across modern work scenarios and enterprise security needs.

Attendees who visit the Device Bar will also have the opportunity to enter a daily drawing to win a Surface Pro for Business by following Microsoft Surface on LinkedIn and sharing a photo from the event.

Build Your Own Mini LEGO Figurine

After exploring a demo scenario, stop by for a quick creative break and build a mini LEGO figurine. It is a fun, hands-on moment that adds some play and personality to your conference experience and gives you something to take home with you.

Guided Demo Stations

The Microsoft Innovation Hub will feature multiple demo stations offering guided, live walkthroughs led by experts who can answer questions in real time.

Each station is designed for scenario based conversations and hands on exploration, giving you the chance to see how Microsoft 365 solutions come to life across different roles, industries, and business needs.

Stay loose with facilitated posture improvement and seated stretching

Tuesday, April 21, 5:00 PM to 6:30 PM

Recharge during the conference with a low impact seated session designed to relieve muscle tension and reduce screen fatigue.

Join us in the Microsoft Innovation Hub to learn simple posture checks, guided eye exercises, and gentle mobility movements that can help improve comfort and restore energy during long workdays.

Join Us in Orlando!

Whether you are attending your first Microsoft 365 Community Conference or returning to reconnect with peers and colleagues, these community experiences are designed to help you build relationships, learn from others, and get more out of your time onsite.

We look forward to seeing you in the Microsoft Innovation Hub within the Expo Hall.

Register now to be part of the Microsoft 365 Community Conference experience.

Securing multicloud (Azure, AWS & GCP) with Microsoft Defender for Cloud: Connector best practices

ckyalo — Fri, 10 Apr 2026 18:03:39 GMT

Many organizations run workloads across multiple cloud providers and need to maintain a strong security posture while ensuring interoperability. Microsoft Defender for Cloud is a cloud-native application protection platform (CNAPP) solution that helps secure these environments by providing unified visibility and protection for resources in AWS and GCP alongside Azure.

Planning for multicloud security with Microsoft Defender for Cloud

As customers adopt Microsoft Defender for Cloud in multicloud environments, Microsoft provides several resources to support planning, deployment, and scalable onboarding:

Planning Guides: Multicloud Protection Planning Guide that walks through key design considerations for securing multicloud with Microsoft Defender for Cloud.
Deployment Guides: Connect your Azure subscriptions - Microsoft Defender for Cloud.

With the right planning and adoption strategy, onboarding to Microsoft Defender for Cloud can be smooth and predictable. However, support cases show that some common challenges can still arise during or after onboarding AWS or GCP environments. Below, we walk through frequent multicloud scenarios, their symptoms, and recommended troubleshooting steps.

Common multicloud connector problems and how to resolve them

1. Problem: Removed cloud account still appears in Microsoft Defender for Cloud

The AWS/GCP account is deleted or removed from your organization, but in Microsoft Defender for Cloud it still appears under connected environments. Additionally, security recommendations for resources in the deleted account may still show up in recommendations page.

Cause

Microsoft Defender for Cloud does not automatically delete a cloud connector when the external account is removed. The security connector in Azure is a separate object that remains unless explicitly removed. Microsoft Defender for Cloud isn’t aware that the AWS/GCP side was decommissioned as there’s no automatic callback to Azure when an AWS account is closed. Therefore, the connector and its last known data linger until manually removed.

Solution

Delete the connector to clean up the stale entry. Use one of the following methods.

Option 1: Use the Azure portal

Sign in to the Azure portal.
Go to Microsoft Defender for Cloud > Environment settings.
Select the AWS account or GCP project that no longer exists.
Select Delete to remove the connector.

Option 2: REST API

Delete the connector by using the REST API: Security Connectors - Delete - REST API (Azure Defender for Cloud).

Note: If a multicloud organization connector was set up and the organization was later decommissioned or some accounts were removed, there would be several connectors to clean up. Start by deleting the organization’s management account connector, then remove any remaining child connectors. Removing connectors in this order helps prevent leftover dependencies.

Additional guidance see: What you need to know when deleting and re-creating the security connector(s) in Defender for Cloud.

2. Problem: Identity provider is missing or partially configured

After running the AWS CloudFormation template, the connector setup fails. Microsoft Defender for Cloud shows the AWS environment in an error state because the identity link between Azure and AWS is not established.

On the AWS side, the CloudFormation stack exists, but the required OIDC identity provider or the IAM role trust policy that allows Microsoft Defender for Cloud to assume the role via web identity federation is missing or misconfigured.

Cause

The AWS CloudFormation template doesn’t match the correct Azure subscription or tenant. This can happen if:

You were signed in to the wrong Azure directory when generating the template.
You deployed the template to a different AWS account than intended.

In both cases, the Azure and AWS IDs won’t align, and the connector setup will fail.

Solution

Verify your Azure directory and subscription.
- In the Azure portal, go to Directories + subscriptions and make sure the correct directory and subscription are selected before you set up the connector.

Clean up the incorrect configuration
- In AWS, delete the CloudFormation stack and any IAM roles or identity providers it created.
- In Microsoft Defender for Cloud, remove the failed connector from Environment settings.

Re-create the connector.
- Follow the steps in Connect your Azure subscriptions - Microsoft Defender for Cloud to generate and deploy a new CloudFormation template using the correct Azure and AWS accounts.

Verify the connection.
- After the connection succeeds, the AWS environment shows Healthy in Microsoft Defender for Cloud. Resources and recommendations begin appearing within about an hour.

3. Problem: Duplicate security connector prevents onboarding

When an AWS or GCP connector is added in Microsoft Defender for Cloud, onboarding fails with an error that indicates another connector with the same hierarchyId already exists. In the Azure portal, the environment shows Failed, and no resources appear in Microsoft Defender for Cloud.

Cause

Microsoft Defender for Cloud allows only one connector per cloud account within the same Microsoft Entra ID tenant. The hierarchyId uniquely identifies the cloud account (for example, an AWS account ID or a GCP project ID). If the account was previously onboarded in another Azure subscription within the same tenant, you can’t onboard it again until the existing connector is removed.

Solution
Find and remove the existing connector and then retry onboarding.

Step 1: Identify the existing connector

Sign in to the Azure portal.
Go to Microsoft Defender for Cloud > Environment settings.
Check each subscription in the same tenant for a pre-existing AWS account or GCP project connector.

If you have access, you can also query Azure Resource Graph to locate existing connectors:

| resources | where type == "microsoft.security/securityconnectors" | project name, location, properties.hierarchyIdentifier, tenantId, subscriptionId

Step 2: Remove the duplicate connector
Delete the connector that uses the same hierarchyId. Follow the steps outlined in the previous troubleshooting scenario for deleting security connectors.

Step 3: Retry onboarding After the connector is removed, add the AWS or GCP connector again in the target subscription. If the error persists, verify that all duplicate connectors were deleted and allow a short time for changes to propagate.

Conclusion

Microsoft Defender for Cloud supports a strong multicloud security strategy, but cloud security is an ongoing effort. Onboarding multicloud environments is only the first step. After onboarding, regularly review security recommendations, alerts, and compliance posture across all connected clouds. With the right configuration, Microsoft Defender for Cloud provides a single source of truth to maintain visibility and control as threats continue to evolve.

Further Resources:

Microsoft Defender for Cloud – Multicloud Security Planning Guide – Start here to design your strategy for AWS/GCP integration, with guidance on prerequisites and best practices.
Connect your AWS account - Microsoft Defender for Cloud.
Connect your GCP project - Microsoft Defender for Cloud.
Troubleshoot connectors guide - Microsoft Defender for Cloud.

We hope this guide helps you successfully implement end-to-end ingestion of Microsoft Intune logs into Microsoft Sentinel. If you have any questions, feel free to leave a comment below or reach out to us on X @MSFTSecSuppTeam.

PHP 8.5 is now available on Azure App Service for Linux

TulikaC — Fri, 10 Apr 2026 10:11:11 GMT

PHP 8.5 is now available on Azure App Service for Linux across all public regions. You can create a new PHP 8.5 app through the Azure portal, automate it with the Azure CLI, or deploy using ARM/Bicep templates.

PHP 8.5 brings several useful runtime improvements. It includes better diagnostics, with fatal errors now providing a backtrace, which can make troubleshooting easier. It also adds the pipe operator (|>) for cleaner, more readable code, along with broader improvements in syntax, performance, and type safety. You can take advantage of these improvements while continuing to use the deployment and management experience you already know in App Service.

For the full list of features, deprecations, and migration notes, see the official PHP 8.5 release page: https://www.php.net/releases/8.5/en.php

Getting started

A simpler way to deploy your code to Azure App Service for Linux

TulikaC — Fri, 10 Apr 2026 09:48:40 GMT

We’ve added a new deployment experience for Azure App Service for Linux that makes it easier to get your code running on your web app.

To get started, go to the Kudu/SCM site for your app:

<sitename>.scm.azurewebsites.net

From there, open the new Deployments experience.

You can now deploy your app by simply dragging and dropping a zip file containing your code. Once your file is uploaded, App Service shows you the contents of the zip so you can quickly verify what you’re about to deploy.

If your application is already built and ready to run, you also have the option to skip server-side build. Otherwise, App Service can handle the build step for you.

When you’re ready, select Deploy.

From there, the deployment starts right away, and you can follow each phase of the process as it happens. The experience shows clear progress through upload, build, and deployment, along with deployment logs to help you understand what’s happening behind the scenes.

After the deployment succeeds, you can also view runtime logs, which makes it easier to confirm that your app has started successfully.

This experience is ideal if you’re getting started with Azure App Service and want the quickest path from code to a running app. For production workloads and teams with established release processes, you’ll typically continue using an automated CI/CD pipeline (for example, GitHub Actions or Azure DevOps) for repeatable deployments.

We’re continuing to improve the developer experience on App Service for Linux. Give it a try and let us know what you think.

The "IQ Layer": Microsoft’s Blueprint for the Agentic Enterprise

harshul05 — Fri, 10 Apr 2026 07:00:00 GMT

The "IQ Layer": Microsoft’s Blueprint for the Agentic Enterprise

Modern enterprises have experimented with artificial intelligence for years, yet many deployments have struggled to move beyond basic automation and conversational interfaces. The fundamental limitation has not been the reasoning power of AI models—it has been their lack of organizational context.

In most organizations, AI systems historically lacked visibility into how work actually happens. They could process language and generate responses, but they could not fully understand business realities such as:

Who is responsible for a project
What internal metrics represent
Where corporate policies are stored
How teams collaborate across tools and departments

Without this contextual awareness, AI often produced answers that sounded intelligent but lacked real business value.

To address this challenge, Microsoft introduced a new architectural model known as the IQ Layer. This framework establishes a structured intelligence layer across the enterprise, enabling AI systems to interpret work activity, enterprise data, and organizational knowledge.

The architecture is built around three integrated intelligence domains:

Work IQ
Fabric IQ
Foundry IQ

Together, these layers allow AI systems to move beyond simple responses and deliver insights that are aligned with real organizational context.

The Three Foundations of Enterprise Context

For AI to evolve from a helpful assistant into a trusted decision-support partner, it must understand multiple dimensions of enterprise operations. Microsoft addresses this need by organizing contextual intelligence into three distinct layers.

IQ Layer	Purpose	Platform Foundation
Work IQ	Collaboration and work activity signals	Microsoft 365, Microsoft Teams, Microsoft Graph
Fabric IQ	Structured enterprise data understanding	Microsoft Fabric, Power BI, OneLake
Foundry IQ	Knowledge retrieval and AI reasoning	Azure AI Foundry, Azure AI Search, Microsoft Purview

Each layer contributes a unique type of intelligence that enables enterprise AI systems to understand the organization from different perspectives.

Work IQ — Understanding How Work Gets Done

The first layer, Work IQ, focuses on the signals generated by daily collaboration and communication across an organization.

Built on top of Microsoft Graph, Work IQ analyses activity patterns across the Microsoft 365 ecosystem, including:

Email communication
Virtual meetings
Shared documents
Team chat conversations
Calendar interactions
Organizational relationships

These signals help AI systems map how work actually flows across teams.

Rather than requiring users to provide background context manually, AI can infer critical information automatically, such as:

Project stakeholders
Communication networks
Decision makers
Subject matter experts

For example, if an employee asks:

"What is the latest update on the migration project?"

Work IQ can analyse multiple collaboration sources including:

Project discussions in Microsoft Teams
Meeting transcripts
Shared project documentation
Email discussions

As a result, AI responses become grounded in real workplace activity instead of generic information.

Fabric IQ — Understanding Enterprise Data

While Work IQ focuses on collaboration signals, Fabric IQ provides insight into structured enterprise data.

Operating within Microsoft Fabric, this layer transforms raw datasets into meaningful business concepts.

Instead of interpreting information as isolated tables and columns, Fabric IQ enables AI systems to reason about business entities such as:

Customers
Products
Orders
Revenue metrics
Inventory levels

By leveraging semantic models from Power BI and unified storage through OneLake, Fabric IQ establishes a shared data language across the organization.

This allows AI systems to answer strategic questions such as:

"Why did revenue decline last quarter?"

Instead of simply retrieving numbers, the AI can analyse multiple business drivers, including:

Product performance trends
Regional sales variations
Customer behaviour segments
Supply chain disruptions

The outcome is not just data access, but decision-oriented insight.

Foundry IQ — Understanding Enterprise Knowledge

The third layer, Foundry IQ, addresses another major enterprise challenge: fragmented knowledge repositories.

Organizations store valuable information across numerous systems, including:

SharePoint repositories
Policy documents
Contracts
Technical documentation
Internal knowledge bases
Corporate wikis

Historically, connecting these knowledge sources to AI required complex retrieval-augmented generation (RAG) architectures.

Foundry IQ simplifies this process through services within Azure AI Foundry and Azure AI Search.

Capabilities include:

Automated document indexing
Semantic search capabilities
Document grounding for AI responses
Access-aware information retrieval

Integration with Microsoft Purview ensures that governance policies remain intact. Sensitivity labels, compliance rules, and access permissions continue to apply when AI systems retrieve and process information.

This ensures that users only receive information they are authorized to access.

From Chatbots to Autonomous Enterprise Agents

The full potential of the IQ architecture becomes clear when all three layers operate together.

This integrated intelligence model forms the basis of what Microsoft describes as the Agentic Enterprise—an environment where AI systems function as proactive digital collaborators rather than passive assistants.

Instead of simple chat interfaces, organizations will deploy AI agents capable of understanding context, reasoning about business situations, and initiating actions.

Example Scenario: Supply Chain Disruption

Consider a scenario where a shipment delay threatens delivery commitments.

Within the IQ architecture:

Fabric IQ
Detects anomalies in shipment or logistics data and identifies potential risks to delivery schedules.

Foundry IQ
Retrieves supplier contracts and evaluates service-level agreements to determine whether penalties or mitigation clauses apply.

Work IQ
Identifies the logistics manager responsible for the account and prepares a contextual briefing tailored to their communication patterns.

Tasks that previously required hours of investigation can now be completed by AI systems within minutes.

Governance Embedded in the Architecture

For enterprise leaders, security and compliance remain critical considerations in AI adoption.

Microsoft designed the IQ framework with governance deeply embedded in its architecture.

Key governance capabilities include:

Permission-Aware Intelligence

AI responses respect user permissions enforced through Microsoft Entra ID, ensuring individuals only see information they are authorized to access.

Compliance Enforcement

Data classification and protection policies defined in Microsoft Purview continue to apply throughout AI workflows.

Observability and Monitoring

Organizations can monitor AI agents and automation processes through tools such as Microsoft Copilot Studio and other emerging agent management platforms.

This provides transparency and operational control over AI-driven systems.

The Strategic Shift: AI as Enterprise Infrastructure

Perhaps the most significant implication of the IQ architecture is the transformation of AI from a standalone tool into a foundational enterprise capability.

In earlier deployments, organizations treated AI as isolated applications or experimental tools.

With the IQ Layer approach, AI becomes deeply integrated across core platforms including:

Microsoft 365
Microsoft Fabric
Azure AI Foundry

This integrated intelligence allows AI systems to behave more like experienced digital employees.

They can:

Understand organizational workflows
Analyse complex data relationships
Retrieve institutional knowledge
Collaborate with human teams

Enterprises that successfully implement this intelligence layers will be better positioned to make faster decisions, respond to change more effectively, and unlock new levels of operational intelligence.

References:

Agent Governance Toolkit: Architecture Deep Dive, Policy Engines, Trust, and SRE for AI Agents

mosiddi — Fri, 10 Apr 2026 04:55:22 GMT

Last week we announced the Agent Governance Toolkit on the Microsoft Open Source Blog, an open-source project that brings runtime security governance to autonomous AI agents. In that announcement, we covered the why: AI agents are making autonomous decisions in production, and the security patterns that kept systems safe for decades need to be applied to this new class of workload.

In this post, we'll go deeper into the how: the architecture, the implementation details, and what it takes to run governed agents in production.

The Problem: Production Infrastructure Meets Autonomous Agents

If you manage production infrastructure, you already know the playbook: least privilege, mandatory access controls, process isolation, audit logging, and circuit breakers for cascading failures. These patterns have kept production systems safe for decades.

Now imagine a new class of workload arriving on your infrastructure, AI agents that autonomously execute code, call APIs, read databases, and spawn sub-processes. They reason about what to do, select tools, and act in loops. And in many current deployments, they do all of this without the security controls you'd demand of any other production workload.

That gap is what led us to build the Agent Governance Toolkit: an open-source project, that applies proven security concepts from operating systems, service meshes, and SRE to the emerging world of autonomous AI agents.

To frame this in familiar terms: most AI agent frameworks today are like running every process as root, no access controls, no isolation, no audit trail. The Agent Governance Toolkit is the kernel, the service mesh, and the SRE platform for AI agents.

When an agent calls a tool, say, `DELETE FROM users WHERE created_at < NOW()`, there is typically no policy layer checking whether that action is within scope. There is no identity verification when one agent communicates with another. There is no resource limit preventing an agent from making 10,000 API calls in a minute. And there is no circuit breaker to contain cascading failures when things go wrong.

OWASP Agentic Security Initiative

In December 2025, OWASP published the Agentic AI Top 10: the first formal taxonomy of risks specific to autonomous AI agents. The list reads like a security engineer's nightmare: goal hijacking, tool misuse, identity abuse, memory poisoning, cascading failures, rogue agents, and more.

If you've ever hardened a production server, these risks will feel both familiar and urgent. The Agent Governance Toolkit is designed to help address all 10 of these risks through deterministic policy enforcement, cryptographic identity, execution isolation, and reliability engineering patterns.

Note: The OWASP Agentic Security Initiative has since adopted the ASI 2026 taxonomy (ASI01–ASI10). The toolkit's copilot-governance package now uses these identifiers with backward compatibility for the original AT numbering.

Architecture: Nine Packages, One Governance Stack

The toolkit is structured as a v3.0.0 Public Preview monorepo with nine independently installable packages:

Package	What It Does
Agent OS	Stateless policy engine, intercepts agent actions before execution with configurable pattern matching and semantic intent classification
Agent Mesh	Cryptographic identity (DIDs with Ed25519), Inter-Agent Trust Protocol (IATP), and trust-gated communication between agents
Agent Hypervisor	Execution rings inspired by CPU privilege levels, saga orchestration for multi-step transactions, and shared session management
Agent Runtime	Runtime supervision with kill switches, dynamic resource allocation, and execution lifecycle management
Agent SRE	SLOs, error budgets, circuit breakers, chaos engineering, and progressive delivery, production reliability practices adapted for AI agents
Agent Compliance	Automated governance verification with compliance grading and regulatory framework mapping (EU AI Act, NIST AI RMF, HIPAA, SOC 2)
Agent Lightning	Reinforcement learning training governance with policy-enforced runners and reward shaping
Agent Marketplace	Plugin lifecycle management with Ed25519 signing, trust-tiered capability gating, and SBOM generation
Integrations	20+ framework adapters for LangChain, CrewAI, AutoGen, Semantic Kernel, Google ADK, Microsoft Agent Framework, OpenAI Agents SDK, and more

Agent OS: The Policy Engine

Agent OS intercepts agent tool calls before they execute:

from agent_os import StatelessKernel, ExecutionContext, Policy

kernel = StatelessKernel()
ctx = ExecutionContext(
    agent_id="analyst-1",
    policies=[
        Policy.read_only(),                    # No write operations
        Policy.rate_limit(100, "1m"),          # Max 100 calls/minute
        Policy.require_approval(
            actions=["delete_*", "write_production_*"],
            min_approvals=2,
            approval_timeout_minutes=30,
        ),
    ],
)

result = await kernel.execute(
    action="delete_user_record",
    params={"user_id": 12345},
    context=ctx,
)

The policy engine works in two layers: configurable pattern matching (with sample rule sets for SQL injection, privilege escalation, and prompt injection that users customize for their environment) and a semantic intent classifier that helps detect dangerous goals regardless of phrasing. When an action is classified as `DESTRUCTIVE_DATA`, `DATA_EXFILTRATION`, or `PRIVILEGE_ESCALATION`, the engine blocks it, routes it for human approval, or downgrades the agent's trust level, depending on the configured policy.

Important: All policy rules, detection patterns, and sensitivity thresholds are externalized to YAML configuration files. The toolkit ships with sample configurations in `examples/policies/` that must be reviewed and customized before production deployment. No built-in rule set should be considered exhaustive. Policy languages supported: YAML, OPA Rego, and Cedar.

The kernel is stateless by design, each request carries its own context. This means you can deploy it behind a load balancer, as a sidecar container in Kubernetes, or in a serverless function, with no shared state to manage. On AKS or any Kubernetes cluster, it fits naturally into existing deployment patterns. Helm charts are available for agent-os, agent-mesh, and agent-sre.

Agent Mesh: Zero-Trust Identity for Agents

In service mesh architectures, services prove their identity via mTLS certificates before communicating. AgentMesh applies the same principle to AI agents using decentralized identifiers (DIDs) with Ed25519 cryptography and the Inter-Agent Trust Protocol (IATP):

from agentmesh import AgentIdentity, TrustBridge

identity = AgentIdentity.create(
    name="data-analyst",
    sponsor="alice@company.com",          # Human accountability
    capabilities=["read:data", "write:reports"],
)
# identity.did -> "did:mesh:data-analyst:a7f3b2..."

bridge = TrustBridge()
verification = await bridge.verify_peer(
    peer_id="did:mesh:other-agent",
    required_trust_score=700, # Must score >= 700/1000
)

A critical feature is trust decay: an agent's trust score decreases over time without positive signals. An agent trusted last week but silent since then gradually becomes untrusted, modeling the reality that trust requires ongoing demonstration, not a one-time grant.

Delegation chains enforce scope narrowing: a parent agent with read+write permissions can delegate only read access to a child agent, never escalate.

Agent Hypervisor: Execution Rings

CPU architectures use privilege rings (Ring 0 for kernel, Ring 3 for userspace) to isolate workloads. The Agent Hypervisor applies this model to AI agents:

Ring	Trust Level	Capabilities
Ring 0 (Kernel)	Score ≥ 900	Full system access, can modify policies
Ring 1 (Supervisor)	Score ≥ 700	Cross-agent coordination, elevated tool access
Ring 2 (User)	Score ≥ 400	Standard tool access within assigned scope
Ring 3 (Untrusted)	Score < 400	Read-only, sandboxed execution only

New and untrusted agents start in Ring 3 and earn their way up, exactly the principle of least privilege that production engineers apply to every other workload.

Each ring enforces per-agent resource limits: maximum execution time, memory caps, CPU throttling, and request rate limits. If a Ring 2 agent attempts a Ring 1 operation, it gets blocked, just like a userspace process trying to access kernel memory.

These ring definitions and their associated trust score thresholds are fully configurable via policy. Organizations can define custom ring structures, adjust the number of rings, set different trust score thresholds for transitions, and configure per-ring resource limits to match their security requirements.

The hypervisor also provides saga orchestration for multi-step operations. When an agent executes a sequence, draft email → send → update CRM, and the final step fails, compensating actions fire in reverse. Borrowed from distributed transaction patterns, this ensures multi-agent workflows maintain consistency even when individual steps fail.

Agent SRE: SLOs and Circuit Breakers for Agents

If you practice SRE, you measure services by SLOs and manage risk through error budgets. Agent SRE extends this to AI agents:

When an agent's safety SLI drops below 99 percent, meaning more than 1 percent of its actions violate policy, the system automatically restricts the agent's capabilities until it recovers. This is the same error-budget model that SRE teams use for production services, applied to agent behavior.

We also built nine chaos engineering fault injection templates: network delays, LLM provider failures, tool timeouts, trust score manipulation, memory corruption, and concurrent access races. Because the only way to know if your agent system is resilient is to break it intentionally.

Agent SRE integrates with your existing observability stack through adapters for Datadog, PagerDuty, Prometheus, OpenTelemetry, Langfuse, LangSmith, Arize, MLflow, and more. Message broker adapters support Kafka, Redis, NATS, Azure Service Bus, AWS SQS, and RabbitMQ.

Compliance and Observability

If your organization already maps to CIS Benchmarks, NIST AI RMF, or other frameworks for infrastructure compliance, the OWASP Agentic Top 10 is the equivalent standard for AI agent workloads. The toolkit's agent-compliance package provides automated governance grading against these frameworks.

The toolkit is framework-agnostic, with 20+ adapters that hook into each framework's native extension points, so adding governance to an existing agent is typically a few lines of configuration, not a rewrite.

The toolkit exports metrics to any OpenTelemetry-compatible platform, Prometheus, Grafana, Datadog, Arize, or Langfuse. If you're already running an observability stack for your infrastructure, agent governance metrics flow through the same pipeline.

Key metrics include: policy decisions per second, trust score distributions, ring transitions, SLO burn rates, circuit breaker state, and governance workflow latency.

Getting Started

# Install all packages
pip install agent-governance-toolkit[full]

# Or individual packages
pip install agent-os-kernel agent-mesh agent-sre

The toolkit is available across language ecosystems: Python, TypeScript (`@microsoft/agentmesh-sdk` on npm), Rust, Go, and .NET (`Microsoft.AgentGovernance` on NuGet).

Azure Integrations

While the toolkit is platform-agnostic, we've included integrations that help enable the fastest path to production, on Azure:

Azure Kubernetes Service (AKS): Deploy the policy engine as a sidecar container alongside your agents. Helm charts provide production-ready manifests for agent-os, agent-mesh, and agent-sre.

Azure AI Foundry Agent Service: Use the built-in middleware integration for agents deployed through Azure AI Foundry.

OpenClaw Sidecar: One compelling deployment scenario is running OpenClaw, the open-source autonomous agent, inside a container with the Agent Governance Toolkit deployed as a sidecar. This gives you policy enforcement, identity verification, and SLO monitoring over OpenClaw's autonomous operations. On Azure Kubernetes Service (AKS), the deployment is a standard pod with two containers: OpenClaw as the primary workload and the governance toolkit as the sidecar, communicating over localhost. We have a reference architecture and Helm chart available in the repository.

The same sidecar pattern works with any containerized agent, OpenClaw is a particularly compelling example because of the interest in autonomous agent safety.

Tutorials and Resources

34+ step-by-step tutorials covering policy engines, trust, compliance, MCP security, observability, and cross-platform SDK usage are available in the repository.

git clone https://github.com/microsoft/agent-governance-toolkit
cd agent-governance-toolkit
pip install -e "packages/agent-os[dev]" -e "packages/agent-mesh[dev]" -e "packages/agent-sre[dev]"

# Run the demo
python -m agent_os.demo

What's Next

AI agents are becoming autonomous decision-makers in production infrastructure, executing code, managing databases, and orchestrating services. The security patterns that kept production systems safe for decades, least privilege, mandatory access controls, process isolation, audit logging, are exactly what these new workloads need. We built them. They're open source.

We're building this in the open because agent security is too important for any single organization to solve alone:

Security research: Adversarial testing, red-team results, and vulnerability reports strengthen the toolkit for everyone.
Community contributions: Framework adapters, detection rules, and compliance mappings from the community expand coverage across ecosystems.

We are committed to open governance. We're releasing this project under Microsoft today, and we aspire to move it into a foundation home, such as the AI and Data Foundation (AAIF), where it can benefit from cross-industry stewardship. We're actively engaging with foundation partners on this path.

The Agent Governance Toolkit is open source under the MIT license. Contributions welcome at github.com/microsoft/agent-governance-toolkit.

Azure IoT Operations 2603 is now available: Powering the next era of Physical AI

seanparham — Fri, 10 Apr 2026 00:03:01 GMT

Industrial AI is entering a new phase.

For years, AI innovation has largely lived in dashboards, analytics, and digital decision support. Today, that intelligence is moving into the real world, onto factory floors, oil fields, and production lines, where AI systems don’t just analyze data, but sense, reason, and act in physical environments. This shift is increasingly described as Physical AI: intelligence that operates reliably where safety, latency, and real‑world constraints matter most.

With the Azure IoT Operations 2603 (v1.3.38) release, Microsoft is delivering one of its most significant updates to date, strengthening the platform foundation required to build, deploy, and operate Physical AI systems at industrial scale.

Why Physical AI needs a new kind of platform

Physical AI systems are fundamentally different from digital‑only AI. They require:

Real‑time, low‑latency decision‑making at the edge
Tight integration across devices, assets, and OT systems
End‑to‑end observability, health, and lifecycle management
Secure cloud‑to‑edge control planes with governance built in

Industry leaders and researchers increasingly agree that success in Physical AI depends less on isolated models, and more on software platforms that orchestrate data, assets, actions, and AI workloads across the physical world.

Azure IoT Operations was built for exactly this challenge.

What’s new in Azure IoT Operations 2603

The 2603 release delivers major advancements across data pipelines, connectivity, reliability, and operational control, enabling customers to move faster from experimentation to production‑grade Physical AI.

Cloud‑to‑edge management actions

Cloud‑to‑edge management actions enable teams to securely execute control and configuration operations on on‑premises assets, such as invoking methods, writing values, or adjusting settings, using Azure Resource Manager and Event Grid–based MQTT messaging. This capability extends the Azure control plane beyond the cloud, allowing intent, policy, and actions to be delivered reliably to physical systems while remaining decoupled from protocol and device specifics. For Physical AI, this closes the loop between perception and action: insights and decisions derived from models can be translated into governed, auditable changes in the physical world, even when assets operate in distributed or intermittently connected environments. Built‑in RBAC, managed identity, and activity logs ensure every action is authorized, traceable, and compliant, preserving safety, accountability, and human oversight as intelligence increasingly moves from observation to autonomous execution at the edge.

No‑code dataflow graphs

Azure IoT Operations makes it easier to build real‑time data pipelines at the edge without writing custom code. No‑code data flow graphs let teams design visual processing pipelines using built‑in transforms, with improved reliability, validation, and observability.

Visual Editor – Build multi-stage data processing systems in the Operations Experience canvas. Drag and connect sources, transforms, and destinations visually. Configure map rules, filter conditions, and window durations inline. Deploy directly from the browser or define in Bicep/YAML for GitOps.
Composable Transforms, Any Order – Chain map, filter, branch, concatenate, and window transforms in any sequence. Branch splits messages down parallel paths based on conditions. Concatenate merges them back. Route messages to different MQTT topics based on content. No fixed pipeline shape.
Expressions, Enrichment, and Aggregation – Unit conversions, math, string operations, regex, conditionals, and last-known-value lookups, all built into the expression language. Enrich messages with external data from a state store. Aggregate high-frequency sensor data over tumbling time windows to compute averages, min/max, and counts.
Open and Extensible – Connect to MQTT, Kafka, and OpenTelemetry (OTel) endpoints with built-in security through Azure Key Vault and managed identities. Need logic beyond what no-code covers? Drop a custom Wasm module (even embed and run ONNX AI ML models) into the middle of any graph alongside built-in transforms. You're never locked into declarative configuration.

Together, these capabilities allow teams to move from raw telemetry to actionable signals directly at the edge without custom code or fragile glue logic.

Expanded, production‑ready connectivity

The MQTT connector enables customers to onboard MQTT devices as assets and route data to downstream workloads using familiar MQTT topics, with the flexibility to support unified namespace (UNS) patterns when desired. By leveraging MQTT’s lightweight publish/subscribe model, teams can simplify connectivity and share data across consumers without tight coupling between producers and applications. This is especially important for Physical AI, where intelligent systems must continuously sense state changes in the physical world and react quickly based on a consistent, authoritative operational context rather than fragmented data pipelines. Alongside MQTT, Azure IoT Operations continues to deliver broad, industrial‑grade connectivity across OPC UA, ONVIF, Media, REST/HTTP, and other connectors, with improved asset discovery, payload transformation, and lifecycle stability, providing the dependable connectivity layer Physical AI systems rely on to understand and respond to real‑world conditions.

Unified health and observability

Physical AI systems must be trustworthy. Azure IoT Operations 2603 introduces unified health status reporting across brokers, dataflows, assets, connectors, and endpoints, using consistent states and surfaced through both Kubernetes and Azure Resource Manager. This enables operators to see—not guess—when systems are ready to act in the physical world.

Optional OPC UA connector deployment

Azure IoT Operations 2603 introduces optional OPC UA connector deployment, reinforcing a design goal to keep deployments as streamlined as possible for scenarios that don’t require OPC UA from day one. The OPC UA connector is a discrete, native component of Azure IoT Operations that can be included during initial instance creation or added later as needs evolve, allowing teams to avoid unnecessary footprint and complexity in MQTT‑only or non‑OPC deployments. This reflects the broader architectural principle behind Azure IoT Operations: a platform built for composability and decomposability, where capabilities are assembled based on scenario requirements rather than assumed defaults, supporting faster onboarding, lower resource consumption, and cleaner production rollouts without limiting future expansion.

Broker reliability and platform hardening

The 2603 release significantly improves broker reliability through graceful upgrades, idempotent replication, persistence correctness, and backpressure isolation—capabilities essential for always‑on Physical AI systems operating in production environments.

Physical AI in action: What customers are achieving today

Azure IoT Operations is already powering real‑world Physical AI across industries, helping customers move beyond pilots to repeatable, scalable execution.

Procter & Gamble

Consumer goods leader P&G continually looks for ways to drive manufacturing efficiency and improve overall equipment effectiveness—a KPI encompassing availability, performance, and quality that’s tracked in P&G facilities around the world. P&G deployed Azure IoT Operations, enabled by Azure Arc, to capture real-time data from equipment at the edge, analyze it in the cloud, and deploy predictive models that enhance manufacturing efficiency and reduce unplanned downtime. Using Azure IoT Operations and Azure Arc, P&G is extrapolating insights and correlating them across plants to improve efficiency, reduce loss, and continue to drive global manufacturing technology forward. More info.

Husqvarna

Husqvarna Group faced increasing pressure to modernize its fragmented global infrastructure, gain real-time operational insights, and improve efficiency across its supply chain to stay competitive in a rapidly evolving digital and manufacturing landscape. Husqvarna Group implemented a suite of Microsoft Azure solutions—including Azure Arc, Azure IoT Operations, and Azure OpenAI—to unify cloud and on-premises systems, enable real-time data insights, and drive innovation across global manufacturing operations. With Azure, Husqvarna Group achieved 98% faster data deployment and 50% lower infrastructure imaging costs, while improving productivity, reducing downtime, and enabling real-time insights across a growing network of smart, connected factories. More info.

Chevron

With its Facilities and Operations of the Future initiative, Chevron is reimagining the monitoring of its physical operations to support remote and autonomous operations through enhanced capabilities and real-time access to data. Chevron adopted Microsoft Azure IoT Operations, enabled by Azure Arc, to manage and analyze data locally at remote facilities at the edge, while still maintaining a centralized, cloud-based management plane. Real-time insights enhance worker safety while lowering operational costs, empowering staff to focus on complex, higher-value tasks rather than routine inspections. More info.

A platform purpose‑built for Physical AI

Across manufacturing, energy, and infrastructure, the message is clear: the next wave of AI value will be created where digital intelligence meets the physical world.

Azure IoT Operations 2603 strengthens Microsoft’s commitment to that future—providing the secure, observable, cloud‑connected edge platform required to build Physical AI systems that are not only intelligent, but dependable.

Get started

To explore the full Azure IoT Operations 2603 release, review the public documentation and release notes, and start building Physical AI solutions that operate and scale confidently in the real world.

Estimate Microsoft Sentinel Costs with Confidence Using the New Sentinel Cost Estimator

shubh_khandhadia — Thu, 09 Apr 2026 22:26:18 GMT

One of the first questions teams ask when evaluating Microsoft Sentinel is simple: what will this actually cost? Today, many customers and partners estimate Sentinel costs using the Azure Pricing Calculator, but it doesn’t provide the Sentinel-specific usage guidance needed to understand how each Sentinel meter contributes to overall spend. As a result, it can be hard to produce accurate, trustworthy estimates, especially early on, when you may not know every input upfront. To make these conversations easier and budgets more predictable, Microsoft is introducing the new Sentinel Cost Estimator (public preview) for Microsoft customers and partners.

The Sentinel Cost Estimator gives organizations better visibility into spend and more confidence in budgeting as they operate at scale.

You can access the Microsoft Sentinel Cost Estimator here: https://microsoft.com/en-us/security/pricing/microsoft-sentinel/cost-estimator

What the Sentinel Cost Estimator does

The new Sentinel Cost Estimator makes pricing transparent and predictable for Microsoft customers and partners. The Sentinel Cost Estimator helps you understand what drives costs at a meter level and ensures your estimates are accurate with step-by-step guidance.

You can model multi-year estimates with built-in projections for up to three years, making it easy to anticipate data growth, plan for future spend, and avoid budget surprises as your security operations mature. Estimates can be easily shared with finance and security teams to support better budgeting and planning.

When to Use the Sentinel Cost Estimator

Use the Sentinel Cost Estimator to:

Model ingestion growth over time as new data sources are onboarded
Explore tradeoffs between Analytics and Data Lake storage tiers
Understand the impact of retention requirements on total spend
Estimate compute usage for notebooks and advanced queries
Project costs across a multi‑year deployment timeline

For broader Azure infrastructure cost planning, the Azure Pricing Calculator can still be used alongside the Sentinel Cost Estimator.

Cost Estimator Example

Let’s walk through a practical example using the Cost Estimator. A medium-sized company that is new to Microsoft Sentinel wants a high-level estimate of expected costs. In their previous SIEM, they performed proactive threat hunting across identity, endpoint, and network logs; ran detections on high-security-value data sources from multiple vendors; built a small set of dashboards; and required three years of retention for compliance and audit purposes. Based on their prior SIEM, they estimate they currently ingest about 2 TB per day.

In the Cost Estimator, they select their region and enter their daily ingestion volume. As they are not currently using Sentinel data lake, they can explore different ways of splitting ingestion between tiers to understand the potential cost benefit of using the data lake.

Their retention requirement is three years. If they choose to use Sentinel data lake, they can plan to retain 90 days in the Analytics tier (included with Microsoft Sentinel) and keep the remaining data in Sentinel data lake for the full three years.

As notebooks are new to them, they plan to evaluate notebooks for SOC workflows and graph building. They expect to start in the light usage tier and may move to medium as they mature. Since they occasionally query data older than 90 days to build trends—and anticipate using the Sentinel MCP server for SOC workflows on Sentinel lake data—they expect to start in the medium query volume tier.

Note: These tiers are for estimation purposes only; they do not lock in pricing when using the Microsoft Sentinel platform.

Because this customer is upgrading from Microsoft 365 E3 to E5, they may be eligible for free ingestion based on their user count. Combined with their eligible server data from Defender for Servers, this can reduce their billable ingestion.

In the review step, the Cost Estimator projects costs across a three-year window and breaks down drivers such as data tiers, commitment tiers, and comparisons with alternative storage options. From there, the customer can go back to earlier steps to adjust inputs and explore different scenarios. Once done, the estimate report can be exported for reference with Microsoft representatives and internal leadership when discussing the deployment of Microsoft Sentinel and Sentinel Platform.

Finalize Your Estimate with Microsoft

The Microsoft Sentinel Cost Estimator is designed to provide directional guidance and help organizations understand how architectural decisions may influence cost. Final pricing may vary based on factors such as deployment architecture, commitment tiers, and applicable discounts. We recommend working with your Microsoft account team or a Security sales specialist to develop a formal proposal tailored to your organization’s requirements.

Try the Microsoft Sentinel Cost Estimator

Start building your Microsoft Sentinel cost estimate today: https://microsoft.com/en-us/security/pricing/microsoft-sentinel/cost-estimator.

Getting Started with GitHub Copilot SDK

anishekkamal — Thu, 09 Apr 2026 21:43:21 GMT

GitHub Copilot has been a staple in developer workflows for a while — it suggests code, completes functions, and generally keeps you from looking up that one syntax for the hundredth time. But what if you could take that same intelligence and embed it directly into your own applications? That's exactly what the GitHub Copilot SDK lets you do.

Launched in technical preview in January 2026 and entering public preview on April 2nd, 2026, the SDK gives you programmatic access to Copilot's agentic engine. It's the same runtime that powers the Copilot CLI — just exposed as a library you can import into your own code, in your language of choice.

What Is the GitHub Copilot SDK?

The SDK is a multi-language library — Python, TypeScript, Go, .NET, and Java — that lets your application talk directly to Copilot's agent runtime. You don't have to build your own orchestration layer, manage model contexts, or figure out tool invocation protocols from scratch. All of that is handled for you.

Three core concepts are worth understanding upfront:

CopilotClient — your main entry point. It manages the connection to the Copilot CLI running in server mode.
Sessions — hold a persistent conversational context, meaning the agent remembers what's been said across multiple turns and can handle genuinely stateful workflows.
Tools — regular Python functions you register with the session. The agent calls them autonomously when it needs to interact with the outside world: query a database, hit an API, read a file.

For Python, getting started is a single command:

pip install github-copilot-sdk

You'll also need the Copilot CLI (https://docs.github.com/en/copilot/how-tos/set-up/install-copilot-cli) installed and accessible in your PATH, plus Python 3.11 or higher.

Read this on how to setup: copilot-sdk/python

Sending Your First Message

import asyncio from copilot import CopilotClient from copilot.session import PermissionHandler async def main(): async with CopilotClient() as client: async with await client.create_session( on_permission_request=PermissionHandler.approve_all, model="gpt-5", ) as session: done = asyncio.Event() def on_event(event): if event.type.value == "assistant.message": print(event.data.content) elif event.type.value == "session.idle": done.set() session.on(on_event) await session.send("Explain the difference between a list and a tuple in Python.") await done.wait() asyncio.run(main())

A couple of things to notice. The `async with` pattern handles all setup and teardown — no manual cleanup required. The `on_permission_request` parameter is required for every session; it's a handler the SDK calls before the agent executes any tool, allowing you to approve or deny the action. `PermissionHandler.approve_all` is the simplest option and perfect for getting started, but in production you'll want something more selective. More on that below.

Giving Your Agent Real Capabilities

Text in, text out is fine. But the real value of the SDK is that you can give the agent *tools* — functions it can call to interact with real systems. The `@define_tool` decorator makes this clean using Pydantic for parameter validation:

import asyncio from pydantic import BaseModel, Field from copilot import CopilotClient, define_tool from copilot.session import PermissionHandler class GetPriceParams(BaseModel): ticker: str = Field(description="Stock ticker symbol, e.g. MSFT") @define_tool(description="Fetch the current stock price for a given ticker") async def get_stock_price(params: GetPriceParams) -> str: # Replace with a real API call return f"The current price of {params.ticker} is $150.00" async def main(): async with CopilotClient() as client: async with await client.create_session( on_permission_request=PermissionHandler.approve_all, model="gpt-5", tools=[get_stock_price], ) as session: done = asyncio.Event() def on_event(event): if event.type.value == "assistant.message": print(event.data.content) elif event.type.value == "session.idle": done.set() session.on(on_event) await session.send("What's the current price of Microsoft stock?") await done.wait() asyncio.run(main())

When the prompt arrives, the agent works out that it should call `get_stock_price` with `ticker="MSFT"`, runs your function, and folds the result into its response. You don't wire up the function-calling logic yourself — the SDK handles dispatch, parameter parsing, and return value handling. Your job is just writing the function.

Streaming Responses in Real Time

If you're building anything interactive, waiting for a complete response before displaying anything feels slow. Setting `streaming=True` and listening for `assistant.message_delta` events fixes that immediately:

async with await client.create_session( on_permission_request=PermissionHandler.approve_all, model="gpt-5", streaming=True, ) as session: done = asyncio.Event() def on_event(event): match event.type.value: case "assistant.message_delta": print(event.data.delta_content or "", end="", flush=True) case "session.idle": done.set() session.on(on_event) await session.send("Write a Python function that validates an email address.") await done.wait()

Each chunk arrives as a `delta_content` string. Print it directly for a terminal UI, or accumulate chunks if you need the full response as a single string.

A Few Things Worth Knowing Before You Build

Billing: Every prompt counts against your GitHub Copilot subscription's premium request quota. If you're building automated workflows that fire off many requests — think CI pipelines or scheduled jobs — monitor usage. The SDK also supports BYOK (Bring Your Own Key), so you can plug in your own API keys from OpenAI, Azure AI Foundry, or Anthropic, which is a good option if you already have model deployments or want to separate usage billing.

Stability: The SDK is in public preview. It follows semantic versioning, so breaking changes come with a major version bump, but check the release notes between upgrades.

Permissions: For anything beyond experiments, replace `PermissionHandler.approve_all` with a custom handler. The SDK lets you inspect each tool request by kind — `shell`, `write`, `read`, `url`, `custom-tool` — and return `approved` or `denied` per request. That's where your security posture lives.

If You Want to Start — Start Here

One thing I've found working is that the best way to help customers adopt a technology is to actually use it yourself first. The Copilot SDK is a good candidate for that approach.

On the internal side, there are a handful of workflows that translate really well to agents.

Customer health reviews, for example — instead of manually pulling data from multiple tools before a call, you could build an agent that gathers recent Azure consumption,

Copilot seat usage, and open support tickets, then produces a plain-language summary. Account preparation used to mean 30 minutes of tab-switching; an agent with the right custom tools can reduce that to a prompt.

Incident prep is another one. When a customer hits an issue and needs a root cause summary fast, an agent that can read recent deployment logs, scan for known patterns, and draft a timeline is genuinely useful — both internally and as something you can walk through with the customer.

Building these tools yourself also gives you hands-on credibility when the architecture conversation comes up. You've already worked through the permission model, you've thought about BYOK, and you know where the rough edges are. That context matters more than any slide.

How to Help Customers Get Started

Most enterprise customers land in one of two places: they see Copilot as a developer IDE tool and haven't thought about embedding it in applications, or they've heard about agentic AI and don't know what a framework like this actually handles versus what they need to build themselves.

The clearest entry point is to start with a specific, bounded use case — not "let's build an AI agent" but "your support team answers the same 40 questions every week; let's route those through an agent that queries your internal knowledge base." That scope is small enough to deliver in a few days, concrete enough to measure, and immediately demonstrates how custom tools connect to real systems.

A few things worth surfacing early in the architecture conversation:

BYOK vs. Copilot subscription: Customers with existing Azure AI Foundry or OpenAI contracts can connect their own models. A quick win for enterprises who already have model deployments and don't want to provision Copilot seats for non-developer workloads.
Permission governance: The `on_permission_request` handler is where the security conversation lives. For customers in regulated industries, showing that every tool action can be audited and restricted at the code level — not just policy — tends to land well.
MCP integration: Customers with existing tool ecosystems (Jira, ServiceNow, internal APIs) can expose those as MCP servers rather than rewriting everything as custom tools. Worth raising early to avoid unnecessary rework.

Customer Use Cases

DevOps and platform engineering — Agents that validate infrastructure-as-code before deployment, flag security misconfigurations, or triage incidents by reading runbooks and change logs. These are high-value because they touch production workflows and have clear, measurable ROI.
Internal knowledge and support — An agent over internal documentation — wikis, policies, architecture decisions — that answers employee questions without requiring someone to search three separate systems. Especially valuable for large organizations where institutional knowledge is fragmented.
Developer productivity — Automating pull request summaries, generating release notes from commit history, or flagging potential issues in code changes. These compound fast: save 10 minutes per PR across a 500-developer org and you notice it quickly.
Reporting and operations — Generating weekly status reports, customer-facing summaries, or executive briefings by pulling from live data sources. The agent handles gathering and formatting; the human handles the judgment call.

The common thread is that the best use cases aren't about replacing people. They're about removing the repetitive connective tissue between tasks — so that your team, and your customers' teams, spend more time on the work that actually requires their expertise.

Where to Go from Here

The official SDK repo (https://github.com/github/copilot-sdk) has a Python cookbook with practical recipes, active documentation, and an Issues page that the team monitors closely. Session hooks, MCP server integration, and the system message API are all worth exploring once you're comfortable with the basics.

The hardest part is usually just the first 20 lines. Once the client is running and you've got a session sending messages, the rest clicks pretty quickly — and that first working agent is a compelling starting point for the customer conversation too.

The GitHub Copilot SDK is available in public preview at (https://github.com/github/copilot-sdk). Python 3.11+ required.

New blog articles in Microsoft Community Hub

mssql-python 1.5: Apache Arrow, sql_variant, and Native UUIDs

Apache Arrow fetch support

Three methods for different workflows

How it works under the hood

Community contribution

sql_variant type support

Native UUID support

Migration compatibility

Row class export

Bug fixes

Qmark false positive fix

NULL VARBINARY parameter fix

Bulkcopy auth fix

Explicit module exports

Credential cache fix

datetime.time microseconds fix

The road to 1.5

Get started today

Help Shape the Future of Microsoft 365: Join Research Sessions at Microsoft 365 Community Conference

What to Expect

Topics That Matter to You

How to Participate

Be Part of What’s Next

The AI-powered partner: Winning in the Microsoft ecosystem

How AI is rewriting the rules of co-sell, Microsoft Marketplace success, and enterprise procurement — and why the window to act is now.

Part 01 / The new procurement reality

Part 02 / Common pitfalls

Part 03 / The co-sell engine

Part 04 / The intelligence layer

Part 05 / The compounding return

Conclusion

Title Plan Update - April 10, 2026

📁April 10, 2026 - Title Plan Now Available

Access the latest Instructor-Led Training (ILT) updates anytime at http://aka.ms/Courseware_Title_Plan to ensure you're always working from the most current version.

Introducing the 2026 Imagine Cup Top Launch Startup

Early momentum. Clear direction.

Meet the startup

L-Guard Ltd.: AI-powered road safety, built for real-time response

What this represents

Partner tools behind the build

OneDrive Office Hours | April 2026

Join us for our next call

New way to register and watch on demand!

April update: What’s new for partners in AI Business Solutions

News and Announcements

Incentives and Offers

Skilling and Events

Go-To-Market

Customer Success

Click "follow" in the top right of the tag AI Business Solutions to stay updated on monthly AI Business Solutions partner news.

FinOps Hub Privado: Implementação Manual em Ambientes Corporativos

Service Mesh-Aware Request Tracing in AKS with Istio and Application Insights

Introduction

Platform Observability Context

Enabling Istio Access Logging at the Mesh Level

Standardizing Envoy Logs Using EnvoyFilter

Configuring Outbound Envoy Access Logs

Automating the Configuration with PowerShell

Log Ingestion into Azure Monitor

Aligning with Application Insights Telemetry

Correlating Requests Using KQL

Closing Thoughts

Watch our video series: Getting started with the Copilot app

From meetings to momentum: Learn how to use Copilot at work

🛠️ Video 1 | Downloading the Microsoft 365 Copilot App

🚀 Video 2 | From insights to impact: Turn action items into deliverables

📊 Video 3 | From chaos to coordination: Gather vital information and deliver it fast

🕒 Video 4 | Catch Up After Time Away

✨ Video 5 | Create with confidence using brand kits

🤝 Video 6 | Prepare for your next presentation

Stay connected

📚 Keep learning

How to Ingest Microsoft Intune Logs into Microsoft Sentinel

Prerequisites and Overview

Configure Intune to Send Logs to Microsoft Sentinel

Frequently Asked Questions

The Microsoft 365 Community Conference Experience Starts with Community

Women in Tech and Allies Lunch Discussion

Celebrity meet-n-greet

April update: What’s new for partners in AI Business Solutions