As a quick follow-up to yesterday’s adventure, ConnectWise Support called me yesterday just before close of business to explain what went awry. In short: The third condition failed on thousands of tickets because prior to 2016, status changes were stored differently in the database. So the condition for “last ticket status update not more than 1 hour ago” was checking for the new kind of status change flag, not the old kind.

We had almost no way of knowing this would happen, short of memorizing every feature and function change over the course of a decade’s worth of software updates to this platform.

By the by, at one point we hit 3000 open tickets. Fun.

Two upsides: One, this should never happen again (on this particular service board) because, well, we’ve now re-closed all those tickets with the new status change flag. Two, my performance metrics for the month are through the roof:

Do I get a raise for this, boss?

It seemed like a simple request.

“If a technician closes a ticket without attaching a Configuration (device), reopen it, send them an email, and change the ticket’s status so they know they need to remedy the lack of Configuration before closing it again.”

Cool. I can do that.

(more…)

Ain’t this just the way things go?

(more…)

Most days, I’m just a fix-it man. Someone broke something, or entropy took its toll, whichever: I get the call and I (usually) find a way to fix the problem.

On rare, delightful occasions I get to actually build something, though. That’s the best.

Today at the office (as it were) I replaced the basically-defunct PHP Server Monitor setup with Uptime Kuma, which (if you install one extra piece of software) can send notifications to all kinds of things if a monitored website-or-whatever goes offline. Since our company lives in Microsoft Teams day in and day out, I set it to post alerts to a particular Teams channel. I showed the results to the VP and a couple of relevant coworkers and they’re all happy with it. Excellent!

A couple of hours of just hunkered down, putting a new thing into service, learning its ins and outs, and getting useful results at the end? Absolute heaven.

More of that, please.

Three years ago, my employers left the Kaseya remote management system behind and migrated to ConnectWise Automate (formerly known as LabTech before the CW juggernaut bought it up, along with a variety of other acquisitions). While there are large benefits to being on this new system, such as not having been part of a gigantic supply-chain malware attack, we do miss a few things from the Kaseya system. Kaseya’s agent status indicators were far superior to Automate’s indicators, its agent software installed and updated far more reliably than Automate’s does, the agent software could be removed via the remote management system, and Kaseya featured a built-in staging share function.

We used the heck out of that share system, mostly for patches but also for other kinds of software deployment. We’ve just kind of gone without that functionality in the years since, but every so often we lament the loss and wonder if there’s a solution.

So this month I’ve started building one. In the stupendously unlikely event that another Automate admin is looking to do something like this, here are the building blocks I’ve put together.

(more…)