How to monitor a printer with Powershell

When it comes to monitoring, as much I like scripting languages, it is never my first choice to rely only on a ‘custom’ script. Considering how many variables are involved: requirements, environments, the overall experience of the team that will manage that piece of software, and all efforts to develop, test, and support the solution over time.

I prefer the implementation of any monitoring solution with basic out-of-the-box features and add on top some scripts if required to reduce the overall codebase to read/maintain. It is not only an early optimisation of a cost/benefit analysis, but it is derived from my professional experiences in different companies and a consideration of the balance needed between the business goal/expectation and the technical value offered by the suggested solution.

In this article you will find something totally different, I wanted to take the opportunity of helping somebody to solve a real case of a Virtual Printer that was causing issues to users and the ops team. The printer needed to be monitored with a living-off-the-land approach, so without adding any software solution but just a few scripts.

Where the project started

ICTWebSolutions reached out to me. I decided to choose the form of a pro-bono consultation/collaboration for this project to keep the solution open source to let everyone the opportunity of learning, sharing, and contributing back to the project.

Why I’ve accepted it

I love my job and I love to contribute and share my passion. I thought that this small project could also show-case some of the structure or approach I have to solve issues and design code or software solutions.

Professional engagements have different expectations and boundaries that I tend to clarify from the start of any project, I liked the approach of ICTWebSolutions and that is the reason why I accepted.

Scenario and Requirements

An Autodoc HSE Printer (by streamlinesoftware.net) is installed on a window server and the number of printing jobs in the queue can grow during the day to a few thousand jobs.

Frequently the printer is (manually) rebooted to get it to function properly and users submit their print jobs again.

This is the full list of requirements.

Proof of Concept

In the first phases of any project regardless of the methodology (waterfall, agile, etc) is always best to verify if the suggested solution satisfies the requirements.

In this scenario, it was just a matter of a few minutes to verify that I was on the right track and gathering all the required information.

Documentation

All meeting notes and requirements were added to the code repository in a MarkDown format.

Project Structure

I need a clean structure from folders to naming conventions to work on a project from the beginning, it helps me to build up the foundations, to visualise my mental model and more intuitive for others.

Configuration

I’ve decoupled the configuration from the script, it is a common practice and it helps to save time when you want to find and to tweak one setting.

Logging

If a script needs to run unattended it needs to log what is doing. I have an article on this subject.

Unit and Functional Testing with Pester (v.5)

I was not looking for 100% test coverage, which is definitely simple to obtain for  100 lines of code, but I wanted to create few tests to make sure that the requirements were always met and if code changes will be applied running those tests will show if something would break. Limit the number of tests to a small number helped to keep the Pester script simple at the same time.

Testing Environment

After spinning up a Windows Server VM and installing the HSE printer it was the time for some manual testing. The simplest way that I could think of for creating a big queue of print jobs was to pause a printer and put some print test pages. A manual test is always required. QA is extremely important.

Notifications

I wanted to create a “pluggable” approach where it is simple to add new notifications in the future if needed, in case after Slack and MS Teams were not enough.  If you want to see some other example of Slack and Teams notifications I have written a couple of articles on this subject.

SLACK

MS TEAMS

 

Let’s review the code

I have tried to keep the code simple to read and hopefully easy to maintain as well.

Depending on the programming language I’m using and how much familiar I’m with it and confident that I can solve the issue, I’m in general pretty good with estimating how big the source code could be, like in this case my “guestimates” were right from the start.

Checking the dependencies, as usual, is done where it should be at the beginning of the script to fail fast.

The script can run unattended so the exit values in the source code are for helping out with the task scheduler log analysis.

Code Repository

I’ve decided to create a separate repository for this project: https://github.com/PaoloFrigo/monitor-printer

Wrap-Up

Using PowerShell as a monitoring solution for your printer is relatively simple, but this project could be also a good starting point for starting your own one and use it as boilerplate.

I hope you will find it useful and you will clone, fork, and share this project.