TALL GRASS COMPUTE
About Tall Grass Compute

Real environments.
Real problems.
Real lessons.

Tall Grass Compute is where I document the systems I build, the problems I run into, and what I learn by working through them.

Tall Grass Compute brand artwork

Hi, I’m Jason.

I’m an infrastructure and end-user computing engineer with nearly three decades of experience working with enterprise systems, virtualization, desktop infrastructure, monitoring, and automation.

Over the years, I’ve worked across a pretty wide range of technologies, but the areas I keep coming back to are the ones where infrastructure, user experience, and automation all intersect: Azure Virtual Desktop, IGEL, Microsoft infrastructure, virtualization, identity, networking, PKI, and the systems that tie all of those things together.

Tall Grass Compute is where I document that work.

Why Tall Grass Compute?

A lot of technical content starts with a perfectly clean environment and ends with a perfectly clean result.

That usually isn’t how things actually happen.

Most of the projects documented here start with a question:

“Can I automate this?”
“Why is this behaving that way?”
“What happens if I build it differently?”
“Can I make this work without adding another server, another manual process, or another dependency?”

From there, things tend to get built, tested, broken, rebuilt, automated, and tested again.

Tall Grass Compute grew out of my homelab as a place to document that process — not just the final configuration, but the troubleshooting, design decisions, unexpected behavior, and lessons learned along the way.

What I Work On

Much of the content here centers around technologies I use professionally or explore in my lab, including:

Azure Virtual Desktop
Linux infrastructure
IGEL OS and IGEL UMS
NGINX and web services
Proxmox VE
Networking and storage
Active Directory and Entra ID
Infrastructure automation
PKI and certificate services
Monitoring and observability

The Goal

The goal of Tall Grass Compute is pretty simple:

Build it. Break it. Learn from it. Repeat.

I try to write articles that I would want to find while troubleshooting a problem myself. That means including the details that are often left out — the configuration that didn’t work, the behavior that wasn’t expected, the commands used to verify the result, and why one approach was chosen over another.

If something worked only after three failed attempts, those failed attempts are often part of the story.