My name is Aaron. I’ve been doing this since 2000, back when we still had PDCs and BDCs and the writable copy of the account database lived on one machine.
Since then I’ve worked as an engineer in healthcare, banking, and insurance. Regulated environments shape how you think. You stop asking whether a control works and start asking who owns it, who can override it, and what the record shows six months later when somebody wants to know why it was set that way. That preoccupation runs through most of what I write here.
I moved into consulting in 2021, working for a VAR with clients across the United States. Most of my early career was datacenter work. VMware clusters, Cisco UCS, and the networking underneath them. I didn’t set out to end up in endpoint and security engineering, but domain join became Entra join, GPO became CSP, and the certificate hierarchy I used to run in a rack acquired a cloud counterpart with different rules about who holds the private key. The work I was already doing relocated, and I followed the authority. These days my engagements are mostly endpoint management, cloud architecture, and the security work that sits across both.
This site is a practitioner-to-peer publication about enterprise infrastructure. Microsoft is where most of it lands, because that’s where most of my engagements land, but that’s a center of gravity rather than a boundary. When CrowdStrike or Cato is the right answer to a problem, I’d rather write about that than pretend the Microsoft option covers it. The site exists because I was already forming these opinions on engagements and had nowhere to put them.
It isn’t a sales pitch, and there’s nothing to buy here. I don’t take work independently. Everything I do runs through my employer.
The positions here are mine, not my employer’s, and so are the mistakes. When I get something wrong I correct it in place rather than quietly deleting it. I use Claude and GPT in the research and drafting process, and the rest of this page explains how, because I’d rather describe it than have you guess.
How these articles get made
Nobody asked me to write this section. I’m including it because a fair number of readers will work out on their own that language models are involved in producing this site, and I’d rather describe the process accurately than have it inferred from tone.
Here’s the honest origin. I’ve been accumulating opinions about endpoint and identity architecture for years, mostly as engagement notes, half-finished diagrams, and arguments I’d had with other engineers. Turning any of that into something another person could follow meant hours of restructuring my own thinking into a sequence that made sense to someone who wasn’t in my head. I found that tedious enough that I mostly didn’t do it. The opinions were already there. The writing wasn’t.
What changed is that the cost of getting it out of my head dropped. The cost of having the opinion in the first place didn’t move at all, and that distinction is the whole point of this section.
An article starts as a position I already hold from an engagement. From there it’s a conversation. I argue the position, get pushed back on, research the parts I’m unsure about, and fairly often discover the position was wrong or incomplete. Drafts get attacked before they get published, usually by a different model than the one that helped write them, and I keep a record of which findings I accepted and which I overruled. Some articles die at that stage. A few have been rewritten from scratch after review found the architecture underneath them didn’t hold.
Every load-bearing claim gets verified against the vendor’s current documentation in the same session it’s written. I treat model training data as stale by default, because it is.
Usually that documentation is Microsoft Learn. This is the part that matters most, and it’s what separates this from the generated content currently flooding search results for anything Intune-related. A model will produce a confident, well-structured paragraph describing a CSP that was deprecated eighteen months ago, and it will sound exactly like a paragraph describing one that still exists. Checking against current documentation, every time, is the only defense.
The worked examples across the series are invented. Northfork Supply Co. and Cat Snack Jack are fictional companies with fictional domains, built specifically so I never have to reach for a real tenant to illustrate a point. Client work does not become article material.
None of this guarantees the articles are right. It does mean the claims in them can be checked, which is the more useful property. The architectural positions come from environments I’ve actually built, corrections get published when I get something wrong, and if you find an error I want to hear about it.
Getting in touch
The site and the way I run engagements come from the same instinct. When I build something in a client’s tenant, I want the team that inherits it to be able to operate it and change it without calling me. So I teach as I go, if that’s what you want. We walk through why a policy is scoped the way it is, what breaks if you move it, and where to look when something stops working. Handing back a working configuration nobody understands isn’t finishing the job.
Either of these works, whether it’s to tell me I got something wrong, argue about an architectural position, or ask how I’d approach something in your environment. I read everything, and I answer most of it.
