In this blog post I explain how to run AI models completely offline on a Mac with Microsoft Foundry Local. No Azure subscription, no API key, no internet connection. Everything runs on your own device.
I made a short video that walks through the whole thing. If you prefer watching over reading, here it is:
The rest of this post is the written version, so you can copy the commands and follow along.
Read More »
In this blog post I want to look at Microsoft Intune Advanced Analytics and compare it, in plain words, to the other analytics tools that are out there. This is the topic I know well. Before I started writing blogs and running my own company, I spent years as the tech lead for AIOps in a large enterprise. Part of my job was to evaluate analytics and digital employee experience (DEX) platforms — Nexthink, Aternity, HP’s analytics solution and several more. So this is not a marketing piece. It is what I learned from running these tools at scale, and where I think Microsoft’s approach is genuinely different.
Here is my honest summary up front: most of these platforms cook with water. They are mature and capable, but they largely solve the same problems in the same way. The hard part was never the dashboard — it was building a business case that survived a second look, because every one of them came with its own agent, its own data store, its own portal and its own license. That is exactly the cost that Microsoft Intune Advanced Analytics removes.
Worth knowing before you read on: From July 1, 2026, Microsoft Intune Advanced Analytics is included in Microsoft 365 E3 and Microsoft 365 E5 as part of Microsoft Intune Plan 2. The separate add-on that used to cost around 10 USD per user per month is now part of the plan. Many teams already own this and don’t know it yet.
Intune Advanced Analytics extends endpoint analytics inside Microsoft Intune. The important word is inside. It is not a separate product. It lives in the same admin center where you already enroll devices, push configuration and remediate.
That sounds like a small detail. After years of running the alternatives, I can tell you it is the whole game. Every DEX platform I operated needed its own agent on every device, its own data lake, and a second console to log into. With Advanced Analytics there is no extra agent. The devices you already manage are the devices you already analyze.
This is the part I wish more comparisons explained, so let me go a level deeper.
Your managed devices already send diagnostics and telemetry to Intune. Advanced Analytics builds on that same pipeline, so there is no new agent to deploy.
It helps to separate two things that often get mixed up:
Now the part that took me a while to get straight, and that most write-ups get wrong: single-device query and the fleet reports use two completely different channels.
createQuery POST to Microsoft Graph, a Windows Push Notification Services (WNS) message wakes the device and starts the PilotDeviceQuery workflow, and the Intune Management Extension (IME) takes over. The IME checks the EnableDeviceActionFeature registry flag, pulls down a DeviceQueryDetail payload that carries your KQL as a base64 string, and runs it through IntunePivotPlugin.dll against the matching WMI providers, CSP and the registry. The result is base64-encoded as DeviceQueryResult and returned within seconds. Because WNS is the transport, if WNS is blocked the query simply fails — and you need IME 1.75.4.0 or later. Rudy Ooms reverse-engineered this whole flow on call4cloud; it is the best under-the-hood write-up I have seen, and it is where the detail in the diagram above comes from.
Because everything stays inside Intune, you act on a finding in the same console where you found it. No export, no second tool.
Hint: If device query for multiple devices returns nothing on your Windows devices, the missing piece is almost always the properties catalog policy — set it up first (it is core Intune, not Advanced Analytics), then give the inventory time to roll in. Note that single-device query does not need it, because that path reads the device live over WNS.
Let me go through the parts I use most, at the level of detail that actually matters in production.
Device query lets you ask a device, or the fleet, a direct question in Kusto Query Language (KQL) — the same language your security team already uses in Microsoft Defender, Microsoft Sentinel and Azure Monitor. A single-device query gives you near real-time access to that device; a multi-device query runs over the collected inventory. In every other live-query tool I ran, the team had to learn that product’s own query dialect and operate yet another console. Here, if you write KQL, there is almost nothing new to learn:
// Find Windows devices that are low on disk space
DeviceData
| where FreeStorageGB < 10
| project DeviceName, Model, FreeStorageGB, OSVersion
| sort by FreeStorageGB asc
That shared query language across endpoint and security is, in my experience, a real differentiator. None of the standalone DEX tools could plug into the same query skills and the same security data my team already had.
My favorite part: let Copilot write the KQL. With Security Copilot in Intune you don’t even have to write the query yourself. You describe what you want in plain language — “show me Windows 11 devices with TPM 2.0 that haven’t synced in 14 days” — and Copilot generates the KQL, shows you the query, and explains how it built it. It works the other way too: paste a query a colleague wrote, ask “what does this do?”, and you get a plain-language explanation. For me this is the feature that makes device query usable by the whole team, not just the two people who are fluent in KQL. I have never had that with any other analytics tool — the natural-language-to-query step always lived in a separate product, if it existed at all.
The anomalies report is the feature that competes most directly with the premium DEX platforms, and it is where Microsoft’s data advantage shows. It watches for application hangs, crashes and Stop Error restarts, then groups affected devices so you can find the common cause.
The anomalies report, grouped by severity. Source: Microsoft Learn.
Behind it sit four statistical models, and it helps to know which is doing what:
When something is flagged, device correlation groups show the shared factors — app version, driver update, OS version, device model — and a prevalence rate tells you what share of a group is affected. In a large enterprise, this is exactly the view I always had to build by hand before: it points straight at the bad driver or the one hardware model, instead of leaving you to correlate it yourself.
The battery health report scores every Windows laptop battery, but the detail underneath is what makes it useful.
The battery health report with score and insights. Source: Microsoft Learn.
The battery health score is a weighted average of two scores, each from 0 (poor) to 100 (exceptional):
You also get the cycle count, and an App impact tab that shows which apps drained the most battery over the last 14 days. That last part is what turns “this laptop has bad battery life” into “this laptop runs a power-hungry app” — a different fix entirely. With the alternatives, getting this depth meant a separate hardware-analytics module, often at extra cost.
The device timeline is, day to day, the report I open most often, so it deserves more than a footnote. It shows a single device’s events — restarts, Stop Errors, app hangs and crashes, driver and update events — on one low-latency timeline. It replaces the older application reliability report and pulls the events that used to be scattered across logs into one ordered view.
Why it matters: when a VIP’s machine misbehaves, the first question is always “what changed and when?”. The timeline answers that directly. I can see that the crashes started right after a specific update or driver, line it up against the anomalies report, and hand the service desk a root cause instead of a guess. For tier-1 and tier-2 support this ends most tickets without escalation — and it does it without a forensic agent on the device. In the tools I ran before, getting this ordered, correlated view meant exporting event logs and stitching them together by hand.
Resource performance ranks CPU and RAM pain by device, model and manufacturer. That turns “we think the 2022 fleet is slow” into a defensible, data-backed purchasing argument. Together with battery health, it is the report that makes hardware-refresh planning a fact-based conversation with procurement rather than a gut feeling. It is built into the same console — no extra agent feeding it.
Here is how I weigh it. This is about fit, not a winner — every column is a capable, mature category, and the DEX platforms genuinely do some things better.
| Point | Intune Advanced Analytics | Dedicated DEX platform | osquery / live-query tool |
|---|---|---|---|
| Extra agent to deploy | None — uses Intune | Yes, per seat | Yes, separate |
| Separate data store | No | Yes | Usually |
| Query language | KQL (same as Defender/Sentinel) | Own language | osquery SQL |
| ML anomaly detection | Built in | Often a premium tier | Not built in |
| Fix it in the same console | Yes — it is Intune | No, go back to MDM | No |
| Cross-platform reach | Windows-first | Broad | Broad |
| Streaming telemetry | Near real-time | Strong | Strong |
| Cost | Included in M365 E3/E5 (from July 1, 2026) | Separate subscription | Separate / open source |
The honest take from the evaluations I ran — Nexthink, Aternity, HP’s analytics tooling and others: these are strong, mature products. They lead on breadth (Windows, macOS, mobile and rich experience scoring in one model) and on continuous streaming telemetry. If that breadth is your main need, they still win, and I will say so plainly.
But three differences kept showing up in my evaluations, and they are architectural, not cosmetic:
When it came to the business case, that combined overhead — a second agent, a second data lake, a second identity to reconcile, a second team to run it — was always the part that made the numbers thin.
The deepest differentiator is structural, and it is the one no standalone tool can copy: Microsoft owns all three layers at once — the OS telemetry, the management plane and the security graph. Nexthink, Aternity and the rest are excellent at the analytics layer, but they sit beside your management and security stack and have to integrate back into it. Advanced Analytics sits inside it. That is why a finding can flow straight into a configuration change, a compliance policy or a Microsoft Defender investigation without leaving the platform or re-identifying the device. Pulling the concrete differentiators together:
Enterprise — catching a bad driver before the storm. This is a real pattern from my AIOps days. A graphics driver goes out to a few thousand laptops on a Friday. By Monday the anomalies report shows a new medium-severity item: a spike in Stop Error restarts. Here the paired t-test model earns its place — it compares each device before and after the change, so the report isn’t guessing, it is pointing at a real regression. You open the device correlation group and it is unambiguous: one manufacturer, one model, one driver version, with a high prevalence rate. To be clear about what happens next, because this is where people overstate it: the anomalies report does not have a magic “roll back” button. What it gives you is the root cause and the affected and at-risk device lists. You then act with the core Intune tools — and crucially, without leaving Intune: confirm the spread with a multi-device device query, decline that driver version in your Windows driver update profile so it stops being offered to the rest of the fleet, and push an Intune remediation script (a pnputil driver rollback) to the devices already hit. Detect, find root cause, remediate — all in one platform, before the service desk volume even moves. With the standalone tools I ran, detection lived in one product and the fix lived in another, and bridging the two by hand was the slow part.
SMB — capabilities that used to be out of reach. A leaner IT team rarely had the budget or the headcount to run a dedicated DEX platform — someone has to own that agent and that data store. The packaging change matters most here: an organization on Microsoft 365 E3 or E5 now gets battery health, anomaly detection and device query as part of Microsoft Intune Plan 2, with no new agent, no new contract and nobody to train on a second console. (One honest caveat: this applies to Microsoft 365 E3/E5 — a tenant on Microsoft 365 Business Premium is not part of this change.) For a small team, near real-time single-device query alone — ask one misbehaving laptop a question and get an answer in seconds — replaces a lot of remote-session guesswork.
This is the part that changed the math for me, so it is worth repeating clearly. From July 1, 2026, Microsoft Intune Advanced Analytics is included in both Microsoft 365 E3 and Microsoft 365 E5 as part of Microsoft Intune Plan 2 — the old per-user add-on is gone. A few of the more advanced Intune capabilities stay with Microsoft 365 E5: Microsoft Intune Endpoint Privilege Management, Enterprise App Management and Microsoft Cloud PKI. But Advanced Analytics itself is in E3 and E5. The details are in the Microsoft Intune blog on the packaging changes.
After years of trying to justify a separate analytics platform, this is the change I find most exciting: the business case largely makes itself, because most teams already own the license.
If you want to read where all of this is heading, I wrote about it in AI-driven endpoint management: the future with Intune. For the official details, the Advanced Analytics overview on Microsoft Learn is the page I keep open.
I hope this helps when you compare Intune Advanced Analytics with the other tools out there.
Stay healthy, Cheers Jannik
If you have sat through a Microsoft keynote more than once, you know the pattern: a wall of product names, a couple of demos that feel like magic, and then weeks of work figuring out what is actually shipping versus what is a sizzle reel. Build 2026 (San Francisco, June 2–3) was the most agent-dense keynote Microsoft has ever given — seven in-house models, a whole context layer, a brand-new category of agent, a containment story that reaches from silicon to cloud, and a concept for hardware that runs agents instead of apps.
This post is the map I wish I’d had on the morning of June 2. I’ll walk every major announcement, explain each one the way I’d explain it to a colleague (not the way the press release phrases it), and — because that’s the job most of us actually have — call out what it means for whoever has to deploy, govern and secure this stuff. It is a round-up, not a feature comparison, and I’ll flag clearly what is generally available, what is preview, and what is still just a slide.
Read More »
A quick note up front: Oakywood provided the desk and accessories as part of a content partnership. Everything you read here is still 100% my own experience. I’ve been using this setup daily for several weeks.
I’ll be honest: I spend a huge portion of my life at a desk. Coding sessions for Frontier Engine, slide decks for conferences, podcast recordings, writing on this blog,… all of it happens on a surface of roughly 1.4 by 0.7 meters. My old desk was functional, but at some point it hit me: the piece of furniture I spend 70+ hours a week at probably deserves to be more than just “functional.”
That’s where Oakywood came in.
If you have built more than one AI tool in the past twelve months, you have noticed the same thing I have: the surface area of “how a model talks to systems” has exploded. Skills, MCP servers, CLI tools, Computer Use, function calling, declarative agents, custom engine agents, apps, actions, extensions, gems — every vendor uses a slightly different word for what looks like the same thing on a marketing slide. They are not the same thing. The trade-offs are real, the choice changes architecture, and picking the wrong one wastes weeks.
This post is the mental model I now apply by default when I sit down to build something agentic. It is opinionated. It is not a feature comparison. The goal is to help you decide which surface to reach for first, not to memorise the spec of each one.
I’ll cover seven surfaces (the original five, plus two that are too important to skip in 2026), map them across Anthropic, OpenAI, Microsoft, and Google terminology, and give you the decision tree I actually use.
Microsoft Agent 365 vs. Microsoft 365 Agents is the field guide distinction for IT teams and architects: one term describes governed agent operations, while the other describes the agents users build and run inside Microsoft 365 experiences.
If you’ve spent the last twelve months in the Microsoft AI ecosystem, you’ve watched the same pattern repeat: every announcement reframes the same thing under a slightly different banner. Copilot. Copilot Studio. Microsoft Foundry. Microsoft Agent Framework. Declarative agents. Custom engine agents. And now, two terms that sound almost identical but mean very different things Microsoft 365 Agents and Microsoft Agent 365.
I keep seeing them used interchangeably, including in serious technical posts. They are not interchangeable. With Agent 365 hitting general availability on May 1, 2026, getting this distinction right is no longer a pedantry exercise it’s a procurement, governance, and architecture decision.
This post is the version I would have wanted before I started building.
If you manage Microsoft Intune at scale, you know the pain: hundreds of policies, most of them with empty or outdated descriptions, and zero visibility into which settings overlap or even contradict each other across policies. I’ve seen this in pretty much every tenant I’ve worked with and honestly, it’s one of the most underestimated operational risks in modern endpoint management.
So I built a tool to fix it. It builds on the same idea I explored in Create your own Intune Co Pilot using Azure OpenAi Studio, but takes it further with policy documentation and conflict analysis. Let me walk you through it.
Let’s be honest: MCP (Model Context Protocol) was supposed to be the universal connector between AI models and the real world. A clean, structured protocol that lets your AI agent talk to any tool through a standardized interface. Sounds great in theory. In practice? I’m increasingly reaching for good old CLI tools instead — and I’m not alone.
After months of building AI agent solutions and working with both approaches in real-world enterprise scenarios, here’s my take: CLI tools are the better choice in many cases, and the reason is surprisingly simple — context efficiency.
Azure AI Content Safety is Microsoft’s AI-powered service for detecting harmful content in both user-generated and AI-generated text and images. It runs as the built-in content filtering system for all Azure OpenAI and Foundry model deployments, screening both prompts and completions through an ensemble of classification models. The service is available as a standalone API and is deeply integrated into the Microsoft Foundry portal. It went through major expansion, adding prompt injection defense, hallucination detection, copyright protection, and PII filtering alongside its core harm-category classifiers.
In my opinion, Microsoft did a great job with this service.
There’s a question I get asked very often: “What tools do you actually use every day?”
These are the ones I personally rely on to stay productive and creative — and if you use AI in your workflow too, my guide on prompt engineering is a good place to start.
So here it is – my complete daily toolkit, broken down by what each tool actually does for me and why I chose it over the alternatives.
