This idea’s been sitting in the back of my mind for a while now. I’ve wanted to create something for the version of me who was just getting started in IT unsure of where the road might lead, full of questions, and searching for stories that sounded like my own. I’ve always been curious about the journeys people take in this industry. What were the detours? What did they learn the hard way? What advice do they wish they had sooner?

That curiosity is the heartbeat of The Panda Award Show, a new podcast I’m hosting with my friend Abhi Saini. Abhi and I go way back. We worked together on Information Technology Disaster Resource Center (ITDRC) deployments, and when we reconnected at MSPGeekCon—Abhi now an MSP owner, it just felt right. We knew we had to build something together.

The name

You're probably wondering about the name.

As we started tossing around ideas, we knew we wanted a mascot, and both of us liked the idea of a bear. But I had one bear in mind specifically.

Back when I was an intern at my first MSP, we had this tradition of passing around a stuffed panda bear each week. It would go to whoever best embodied the company’s values, including hard work, helpfulness, the kind of stuff you can’t always measure on paper. It was goofy, yeah, but it meant something. It was a symbol of appreciation, of recognition from your peers. That stuck with me.

So we decided to bring the panda back. On this show, we’ll be passing the panda to guests who represent the best of what this industry can be, people who’ve stayed curious, lifted others, and stayed true to their values through the ups and downs of tech careers.

The Panda Award Show is a casual podcast about real people in IT. We talk about the paths taken, the lessons learned, and the things you’d go back and tell your younger self if you could. No polished success stories, just the kind of honest conversations that remind you you’re not alone on the journey.

If you're in tech—or just figuring out what comes next—I hope you’ll listen. You might just find the story you needed to hear.

Where to find it:
Watch for our first episode to drop on July 1st:

https://pandaawardshow.com/

Hi, I'm Ben Climer. I’ve been taking things apart and figuring out how they work for as long as I can remember. I built my first computer at age eight, mostly out of necessity after breaking the family one. By twelve, I was coding websites with streaming embedded music. As a teenager, I competed in national contests for web design and computer repair, and discovered early on that I enjoyed solving problems that others found frustrating.

After high school, I started working in IT, eventually spending over a decade in the MSP world. I held a mix of technical and leadership roles, often jumping between fixing urgent issues and planning long-term solutions. That experience shaped how I think about automation today. Automation started as something the MSP I was working for didn’t do, scripting, and turned in a career passion.

I now work at Rewst, where I help others build better workflows and automation. I focus on making tools that are reusable, easy to understand, and built to scale. I'm also involved in community training, internal process improvements, and building things like Schema Doctor to make technical work a little smoother for everyone.

Outside of work, I’m into cars, road trips, and co-hosting my podcast, Panda Award Show.

I live in Kansas City, Kansas, and I still find joy in chasing down bugs that make no sense on paper.

Crushing the Demo Goal

We went into the event with the idea that most attendees would already be Rewst customers or at least familiar with us. That turned out to be only partially true. Perhaps in part due to Eddie’s talk and Zentop's pre-day event, we had a great influx of interest from folks who hadn’t used Rewst yet or hadn’t even heard of us before.

Quick Wins and Real-Time Problem Solving

One standout moment was hearing people talk about how Schema Doctor helped them at their job. While there, I even showed new users the tool and empowered them to integrate their CRM, which opened up more automation possibilities for them and their clients. That kind of hands-on help is one of my favorite parts of being at these events.

I also spent time with an existing partner. I destroyed them at Exploding Kittens on game night — although they got the last laugh during a chaotic round of Incoherent.

Community Conversations and Feedback

A big chunk of my time was spent talking with other power users about their friction points in the platform. Many provided feedback about small features that could make a big difference in usability.

I also had some great conversations with n8n users curious about Rewst. I think there’s room for more than one automation tool in a stack and Rewst has some clear advantages for MSPs.

Internal Collaboration and Churn Reduction Ideas

The event wasn’t just outward-facing. I had some valuable conversations with Rewst members about ways to improve the client experience.

Sessions and Takeaways

Eddie’s session was solid, and I was especially impressed by the panel with Jason Slagle, Matt Lee, and Dustin Bolander. It gave me a fresh perspective on how to evolve solutions I had made in the past. I also caught a neurodiversity panel that stuck with me. One thing I plan to explore further is manualof.me, a site that helps individuals explain how they work best. It’s something I might personally use and recommend to other team members.

It was a packed couple of days, and I came back with a lot of insights, a few new ideas, and some great conversations still rattling around in my head. I’ve always enjoyed hearing what others bring back from conferences, so I hope this recap offers some of that same value.

MSPGeekCon will be uploading their sessions and panels on their youtube channel.

That’s what sparked the idea behind tenantidfinder.com.

It started from a personal need. I was working through a list of domains and needed to find their associated Microsoft 365 tenant IDs. Not one or two, dozens. And doing it manually was quickly becoming a pain. I knew the information was publicly accessible with the right OpenID Connect call, but there wasn’t a quick, no-login tool to do it in bulk. So I built one.

The Problem

If you've worked at an MSP or supported clients with multiple brands, you're probably familiar with the mess that is tracking which domain belongs to which tenant. Sometimes there’s one tenant per brand, sometimes not. When a client asks you to verify something, or you’re building automation that needs a tenant ID, you're left hopping between portals, logging into each tenant, checking verified domains, and wasting a ton of time.

You can’t look up domains from a tenant ID (at least not easily or reliably), but thanks to OpenID Connect, you can look up the tenant ID from a domain. That tiny asymmetry is where this tool lives.

What It Does

tenantidfinder.com takes in a list of domains, just type or paste them in, and gives you back:

• The tenant ID, pulled using an OpenID Connect .well-known discovery call.

• MX, SPF, and DMARC DNS records, resolved using DNS over HTTPS.

• Autodiscover CNAME records for Microsoft Exchange.

• CSV export so you can save results or import them into another tool.

It’s designed to be dead simple. No login. No OAuth. Just paste and go.

This isn’t meant to replace complex domain tooling or security tools, but it fills a very specific gap: figuring out what tenant a domain belongs to and confirming it behaves like a typical Microsoft-hosted domain.

Technical Notes

The two core pieces of functionality are:

• OpenID Connect for tenant discovery. Specifically, I’m querying https://login.microsoftonline.com/{domain}/.well-known/openid-configuration and parsing the returned JSON for the issuer value. That’s where the tenant ID is embedded.

• DNS lookups via DNS over HTTPS. I’m using a public DoH endpoint (like Cloudflare or Google) to fetch DNS records. This means the lookups are consistent, fast, and don’t rely on browser or network-specific behavior.

Everything is built into a static site. There’s no backend, no logging, no analytics—just client-side JavaScript. That keeps it fast and private. You could use it on an airplane Wi-Fi connection or a locked-down client network and it would still do its job.

Why I Shared It

My friend Joel once told me to keep dropping “MSP cheat codes” in the form of LinkedIn posts. I liked that term. It sums up the spirit of this kind of work: solving problems just enough to turn them into tools or shortcuts for others.

That’s really why I built and shared Tenant ID Finder. Not just to save myself time, but to put something useful in the hands of other techs who run into the same wall. I’ve seen people do this the hard way, and while it’s not hard, it’s tedious and repetitive. If this tool saves someone 20 minutes or prevents a wrong tenant ID in a PowerShell script, I’m calling it a win.

What started as a simple utility to help me get work done faster has evolved into a lightweight, client-side tool that cleans up messy OpenAPI schemas. It was originally built to scratch my own itch. I needed something that could help with schema debugging, and I didn’t want to rely on slow online validators or bulky local installs just to make a few fixes.

Schema Doctor now lives on a clean static site, and I’ve begun sharing it more widely so others can get value from it too. It still has plenty of room to grow, but the core functionality already solves several major pain points in schema work.

Why Schema Validation Sucks

OpenAPI is an excellent standard on paper. It provides a consistent way to describe REST APIs, enabling everything from documentation to testing to code generation. But in practice? It’s a bit of a mess.

The problem is that not everyone uses the spec consistently. Some vendors treat it like a rough suggestion. Others lean heavily on auto-generated output from frameworks that don’t prioritize clean specs. Even open-source tools that claim OpenAPI support often fail to produce valid or usable schemas.

As someone automating workflows and integrating with third-party services, I found myself constantly:

• Chasing down syntax errors buried in thousand-line JSON files

• Hitting reference loops that break tools like Swagger UI or Postman

• Manually adding missing operation IDs just so my generator wouldn’t crash

I realized I was repeating a lot of the same cleanup steps over and over. That’s where Schema Doctor began.

What It Does

Schema Doctor is a browser-based utility that parses and fixes OpenAPI 3.0 and 3.1 schemas. It doesn’t try to be an all-in-one solution for editing or generating specs. Instead, it focuses on automating the most annoying fixes.

Here’s what it helps with right now:

• Handling Circular References
  It identifies and restructures circular $ref loops so they no longer break tools that expect trees instead of graphs.

• Fixing Syntax Errors
  It runs basic JSON parsing and schema-level checks to spot and report common formatting mistakes.

• Adding Missing Operation IDs
  For tools that require every operation to have a unique operationId, Schema Doctor can auto-generate these based on method and path.

• Flattening Complex Schemas (experimental)
  If a schema is split across multiple components with deep nesting, Schema Doctor can flatten it into a more portable format.

The best part? It all runs client-side. No uploading sensitive schema data to a third-party server, and no dependency hell. Just open the page, paste your schema, and hit the button.

Building It: Fast and Functional

Schema Doctor was built with simplicity in mind. I wanted something that could load instantly, work offline, and run in any modern browser. The tech stack reflects that:

• Plain HTML + JavaScript
  No frameworks, no dependencies, just browser-native code.

• Swagger-Parser under the hood
  For validation and parsing, I used the excellent Swagger-Parser library. It handles a lot of the heavy lifting and catches edge cases I might miss.

• Modular JS functions
  Each fix is implemented as a standalone helper, so I can continue adding new ones without overcomplicating the codebase.

There’s no user login, no telemetry, no fluff. The goal was utility, not analytics.

Why Share It?

Initially, I wasn’t planning to release Schema Doctor publicly. It felt too rough, too specific to my workflow. But the more I used it, the more I realized others might benefit too. Every time I fixed a broken schema from a new vendor, I thought, "someone else is probably hitting the same wall."

So I cleaned up the UI, added better error handling, and hosted it with GitHub Pages. Now it's live, free to use, and something I genuinely hope saves others time.

If you’re an automation nerd, an API integrator, or someone stuck cleaning up vendor garbage on the regular, give it a try. It's already helped me clean up dozens of specs and get integrations running faster.

If you’ve got a schema that breaks something and want to see if Schema Doctor can help,
You can try it out at: https://schemadoctor.com

Chasing Breadcrumbs at CyberDrain CTF

One of the recurring events I always look forward to is the CyberDrain CTF. If you're in the MSP or sysadmin world and haven't checked it out yet, I highly recommend it. You can find it at ctf.cyberdrain.com. It's a capture-the-flag competition designed specifically for people in our industry, focusing on real-world scenarios that help sharpen both technical and problem-solving skills.

This past year marked the third time I've placed in the Top 5, and it's always an adrenaline-fueled experience going toe-to-toe with some of the sharpest minds in the field. The CTF is packed with cleverly hidden breadcrumbs and requires not just technical knowledge, but creativity and persistence. Every time I participate, I walk away having learned something new.

What makes this event special isn't just the challenge itself, but the community around it. I want to give a sincere thank you to Kelvin Tegelaar, Gavin Stone, Luke Whitelock, John Duprey, and Stephen Murphy for all the time, thought, and effort that goes into creating this experience. A lot of love and late nights go into building something this detailed and this useful. It's events like these that help grow the skillset of the entire community, and I’m always grateful to be a part of it.

Honored to Be Named a Kentucky Colonel

On a very different but equally meaningful note, I had the unexpected honor of being named a Kentucky Colonel by the Governor of Kentucky. For those unfamiliar, this is the highest civilian honor awarded by the Commonwealth of Kentucky, and it’s given in recognition of noteworthy accomplishments or service.

The recognition came as a result of my work with the Information Technology Disaster Resource Center (ITDRC) during the recovery efforts following the Eastern Kentucky flooding. The devastation was severe, and entire communities were left without basic services. Our team assisted in restoring communication infrastructure so that emergency services and residents could get back online, coordinate relief, and start rebuilding.

The work itself is always what matters most. You show up, get your boots muddy, and do what needs to be done. But it was moving to see the efforts of the team recognized in such a formal way. I share that honor with my fellow ITDRC volunteers who put in the long hours and worked through incredibly difficult conditions. If you’re unfamiliar with the ITDRC, I’d encourage you to learn more at itdrc.org. They do incredible work helping communities in times of crisis, and I’m proud to be part of that mission.

Bringing the PowerShell Community Back Together

This year also marked the return of something near and dear to me: the Middle Tennessee PowerShell User Group. Alongside Mick Pletcher, we brought the group back into action and shifted it to a virtual format to make it more accessible to folks inside and outside of the region.

PowerShell has always been one of my favorite tools in the sysadmin and automation toolbox, and user groups like this are a great way to stay sharp, share knowledge, and support one another in solving the tough technical challenges we all face. Whether you're just getting started or have been scripting for years, our sessions are open to all, and we’d love to have you join in. You can find more info and upcoming meeting details here.

A New Chapter: CTO at SNS

Finally, one of the most significant shifts for me this year has been a change in role. I stepped into the position of Chief Technology Officer at SNS. It’s a role that allows me to lean into the areas I’m most passionate about: systems architecture, automation, scalability, and adding real value to both the business and the customers we serve.

Taking on a CTO role isn't something I take lightly. It means stepping up, not just in terms of technical leadership, but also in supporting the team, aligning strategy with execution, and building a culture that encourages experimentation, learning, and excellence. I’m excited about where we’re headed and deeply motivated to help shape a future where our technology is not just functional, but transformative.

Looking back on 2023, the common thread through all these moments has been community. Whether it’s competing with peers at CyberDrain, serving disaster-stricken areas with ITDRC, rebooting the PowerShell user group, or stepping into a leadership role at SNS, none of it happens in a vacuum. It happens through collaboration, mentorship, shared challenges, and mutual respect.

If you're someone in tech trying to figure out where to plug in, my advice is simple: get involved. Show up. Whether it’s a user group, a volunteer effort, a hackathon, or just helping a peer solve a tough problem, those experiences will shape your career and your character in ways you can’t always predict. I’m thankful for everyone who’s been part of that journey with me this year.

Here's to what comes next.

— Ben Climer