I spent part of the workday making a script to perform two tasks on all machines at a particular client site:
Remove a specific named user from the local “Administrators” group on a PC.
Remove that user from the PC entirely.
Since I’ve been moving toward using PowerShell rather than various (potentially abandonware) utilities for handling command-line scripted jobs, I looked into if there were simple commands to perform those two tasks. Good news! Remove-LocalGroupMember and Remove-LocalUser exist!
The bad news? Microsoft’s documentation for both of those “cmdlets” stresses the fact that if you are on a 64-bit version of Windows and you try to use them in a 32-bit console, those cmdlets aren’t available at all.
Guess whose RMM system hasn’t yet gotten around to making 64-bit agent software? Surprise, that’d be ConnectWise’s “Automate” product. What does this mean? It means that the Automate agent’s “commands” are sent to a 32-bit console. Exactly what I don’t want.
Not to worry, however: With some testing I found that I can invoke PowerShell 7 (which lives separately from the “native” installed PowerShell) via the remote agent and those cmdlets are available! A heck of a workaround, but I’ll take what I can get. On the downside, the client for whom I needed this script didn’t yet have PowerShell 7 installed, not on any of their machines. This led to some time spent figuring out a fix for the PS7 installers not downloading reliably from our S3-compatible bucket. (Oh hey, Github links direct to the PS7 MSIs, thanks for existing.)
So… with PS7 deployed to the client’s machines (after I updated some automation to make sure all clients’ machines will get the PS7 product and/or update) I successfully ran my new script to eradicate the unwanted user account. A day well spent.
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:
“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.”
I took today off as a mental-health and personal-projects day, in advance of starting my on-call rotation tomorrow. I needed the break. Technically I need a longer break but I was so busy and stressed out and off-balance this month that I didn’t think to actually apply for time off until… yesterday.
I still got up with the alarm, though. Being on a pill-taking regimen sort of requires sticking to the daily routine; if I sleep through the alarm, my phone’s pill-taking reminder goes off a while later anyway. So I went through the regular start-of-day shuffle: shave, shower, etc.
While in the shower, the solution to a nagging work problem came to me. Because I am who I am, as soon as I got to my computer I confirmed the validity of the idea, then loaded up my work email and sent a message to my boss about the solution.
I get brownie points for that, right? Good. Thanks.