We’re kicking off a new interview series where we go behind the scenes with a worklet writer to see how the sausage gets made. @Mrichards graciously agreed to go first, so I chatted with him about how the Workstation Network Health Check worklet came to be.

Nic: What was the impetus for creating this worklet?

Matt: So this worklet was originally developed right after COVID work from home started, mainly because a handful of our users complained “IT gave me a bad laptop, it’s slow and disconnects from my home wifi all the time”. We had no real way to get any real data on what was going on at their house (we don’t do house calls). So we had no way to refute their claims about it being “IT’s fault!”. Originally it was just a wifi checker, but we desired more data. It slowly became a “workstation health” script over time.

Nic: What difficulties or obstacles did you run into getting it created?

Matt: The biggest difficulty was working with the Activity Log, honestly. It doesn’t really format things super well, and we want to get concise, real, useable data. So theres a lot of effort in the script to avoid unneeded characters/strings such as removing colons or lines altogether to get nice, readable data.

Nic: How well is it working and have you been able to identify any network issues with it?

Matt: Actually yes! It was a huge win for us when we were able to sit down with our end users and discuss home networking with them. We took the worst 10% wifi signal users and did 1 on 1 meetings with them. We found that they mostly had extremely old routers or were too far away from their access point. We mainly pushed them to either upgrade or invest in a mesh style system for those large mansions.

Nic: Have you seen feedback from your end users - are they more satisfied with IT now that this troubleshooting resource is available to the helpdesk?

Matt: We noticed a lot of our less technical users (e.g. the magic box isn’t working) are giving really positive feedback, since we are able to really pinpoint their issue (i.e.: lack of RAM, Tracert hop here looks bad, etc). This also empowered our users to be able to call their ISP and complain with real data.


The technical users tend to already have troubleshot on their own and just want IT to verify and fix whatever issue.

Nic: Have you had to upgrade or troubleshoot your WFH users’s networks? How is that going?

Matt: We realized that normally this was a boundary we never wanted to cross, but WFH changed that. First and foremost, we are trying to improve our organization’s efficiency, and with WFH, that includes home networks a bit now. We will try and do break-fix work on their network, or give guiding assistance, but there is still that separation of personal equipment from work equipment. It’s an odd line that we try and figure out on a case by case basis.

Nic: What would you add to a v2 of this worklet after having used it for a while?

Matt: v1.1 was adding wifi names (not uploaded to the community yet, some users get hung up on 2.4ghz/5ghz bands, so this helps). But for 2.0, I would like to setup a schedule so we have more consistent data, and pipe that into a nice looking BI for long term trends. (Maybe an Automox supported report instead 😉)

Nic: How did you get started writing scripts in Powershell?

Matt: I got hired on as an IT generalist doing mostly physical desktop setups with lots of manual tasks. It seemed smart to try and learn how to automate some of this stuff to give me more time to do other aspects of the job. One of my first big projects was figuring out how to do automated imaging, which mostly relied on FOG (fogproject.org - highly recommend this free solution) to get a base image on a machine, then it was all Powershell after that. I loved the idea of writing something small in Powershell that could be used over and over again to speed up our process.

Nic: What are your favorite scripting resources?

Matt: Oh man… google everything. docs.microsoft.com is surprisingly good once you learn how they lay things out and it’s my usual go-to. Then of course the normal suspects; Spiceworks, Stack Overflow, etc. Related - I can’t stress this enough - get yourself some sort of repo to store your code in. Nothing is more frustrating than remembering you already wrote this worklet but you cannot find it so you gotta re-write it.

Nic: What your number one feature request or improvement idea for the worklet system?

Matt: It has to be native x64 support with admin rights. Coding in x86(32bit) as SYSTEM actually sucks pretty bad. Most of my worklets in some way or another require a codeblock + calling an encoded x64 Powershell window. My security team hates it because encoded hidden Powershell gets lit up by our AV. In the same vein, would be digitally signed code in the same respect to trying to get my security team off my back. (Apparently they get spooked when I run long unsigned hidden encoded Powershell scripts across 200+ endpoints all at the same time, who knew??).

–

Thanks for the interview Matt! We’re looking forward to seeing what future worklet ideas you come up with.

If anyone has any follow-up questions for Matt, please post them below.