I’m Landon, a Systems Administrator and Engineer who spends most of my time keeping infrastructure running, secure, and well-documented, and the rest of it tinkering with technology nobody’s paying me to touch… just pure love of the game.

What I Do

My day-to-day work spans a pretty wide range of the stack:

  • Windows Server & Active Directory — design, migrations, and the occasional 2am recovery
  • Linux administration — Debian, SLES, RHEL, and Ubuntu, mostly, across bare metal, VMs, and containers
  • Microsoft 365 & Exchange Online — tenant management, mail flow, licensing
  • Azure & Entra ID — identity, access, and the steady creep toward Zero Trust
  • Networking — Fortinet, Cisco, WatchGuard, Palo Alto, and Aruba, depending on the client
  • CMMC & NIST compliance — the kind of work that makes you appreciate good documentation
  • Homelab & open source — Proxmox, Docker, Kubernetes, self-hosted everything

How I Got Here

I started where a lot of people in this field start: helpdesk, fielding password resets and “my mouse isn’t working” tickets. That didn’t last long. I moved into an MSP environment that was, charitably, a sink-or-swim kind of place, the fastest way to become a jack-of-all-trades systems engineer is to get handed a problem you’ve never seen before and told to figure it out before the client notices it broke. I learned more in those first couple of years than I would have in a much slower, more structured environment. Although it feels as if I aged 10 years for every 1 human year at that job, I honestly think the best place to start in IT is at a small to medium sized MSP. There is nothing like learning to thrive in the absolute chaos and unstoppable wave of tickets. You will learn more working at an MSP than you will in a combined 3 years doing internal IT.

From there I made my way into internal IT, including a stretch in aerospace manufacturing, an environment with its own particular flavor of constraints: legacy systems you can’t just swap out, security requirements that come with the territory, and zero tolerance for unplanned downtime on a production floor. These days I’m part of a great IT Team for a fabrication company, doing similar work, keeping the infrastructure running that keeps production running and helping our user base do the great work they love.

Why This Site Exists

I write a lot of internal documentation that nobody outside a ticket system ever sees. This is where the more interesting parts of that work get a second life, project breakdowns, troubleshooting notes, and the occasional strong opinion about how infrastructure should be built. I wrote more about the reasoning in my first post, if you’re curious.

Good documentation is just a kindness you do for your future self, who will, with total certainty, have forgotten everything by the time it matters again.

If you’re working through something similar to what’s written about here, I hope it saves you some time.