The first two posts in this series covered the mechanics (tokens, temperature, the four pillars) and the cost angle (why a sloppy prompt is a budget line, not just an annoyance). This one is the field guide that was implied but not fully delivered: a working set of bad/good/best examples across the techniques that actually separate a prompt that gets lucky once from one that reliably works. ...
Everything covered so far in this series works the same way regardless of company size — the mechanics of enrollment, compliance, Conditional Access, app deployment, and baselines don’t change because the org is a non-profit. What changes is the constraints: a much thinner budget, often a very small IT team (sometimes exactly one person wearing every hat), and a board that reasonably wants to know why any dollar isn’t going toward the mission. This post is about running Intune well inside those constraints, drawn from real lean-IT-shop experience rather than enterprise assumptions. ...
Every part of this series so far has been about building capability into Intune — enrollment, compliance, access control, apps, baselines. This last one is about the flip side: everything that makes Intune powerful for administration makes it equally powerful for whoever manages to compromise the administrative layer. Whoever controls Intune can push scripts, alter configurations, and remotely wipe devices across an entire fleet in one coordinated action — and in March 2026, that stopped being a theoretical concern. ...
Part 3 ended on a deliberately uncomfortable note: a compliance policy by itself doesn’t block anything. It grades a device and moves on. This post is the other half of that pairing — Conditional Access is the piece that actually turns “this device is noncompliant” into “this device doesn’t get in.” ...
Here’s an uncomfortable fact about compliance policies that a lot of tenants learn the hard way: a compliance policy, on its own, doesn’t block anything. It evaluates a device against a set of rules and labels it Compliant or Not Compliant — that’s it. Nothing downstream actually happens unless something else is watching that label and acting on it. Get this wrong and you can have a fully built-out compliance policy that’s pure checkbox theater, catching real problems and doing absolutely nothing about them. ...
Kicking off a new series here on Intune — this one’s going to run long, because there’s a lot of ground worth covering: architecture and enrollment, compliance policy design, conditional access, app deployment, configuration baselines, real lessons from running it as a one-person shop, and the attack surface it introduces once it’s live. Part 1 starts with the boring-but-necessary step: being precise about what Intune actually is before deploying anything. ...
Part 1 covered what Intune is. This one covers the decisions that are expensive to unwind once devices are already enrolled and policies are already assigned — because unlike a compliance policy you can just edit, ownership model and tenant structure tend to get baked into a fleet from day one. ...
It started as a small thing: a reader — well, me, reading my own site — noticed nine days in July with headlines but no “From the Trenches” commentary underneath them. Easy enough to backfill by hand. But backfilling isn’t fixing, and I’ve learned the hard way that a bug you patch around instead of root-causing just shows up again wearing a different date. ...
Most people talk to an LLM the way they’d talk to a search engine: type a few words, hope for the best, complain when the answer is generic. That’s not a model problem. It’s a prompting problem. ...
Every token an LLM API processes has a price tag, on the way in and on the way out. That fact turns “write better prompts” from a productivity tip into a line item. Most organizations treat AI spend as an unavoidable cost of doing business; in practice, a meaningful chunk of it is just badly engineered prompts paying for their own inefficiency. ...