Interruptions in tech support

I recently read some posts on the damaging effects of interruptions and wanted to explore this in the context of my current job – sysadmin across multiple k-12/ks1-5 educational environments – and offer some thoughts on how to change things.

First off, the core educational environment itself is pretty much built around interruptions. You generally have a single teacher in a room of a few dozen kids. I’m simplifying here, but the teachers essentially have particular targets to hit each lesson (“teach this thing”, “make sure the group produces this result”, etc) and these lessons are typically somewhere around an hour long, though from what I’ve seen these lessons are shrinking in length to squeeze more different material into a day/week. Teachers have to hop between different targets every hour (or less) as the group they teach changes (the students have to similarly hop, but across entire subject ranges. Is there any surprise that, combined with the usual suspects (advertising, media, social medias’ infinite scroll, etc), young people have shorter attention spans?) Often these differing targets are in the same subject (Science, or English, or Mathematics, and so on) however different classes are at different points in the curriculum and even if some of those classes are at the same point in the curriculum (the students are of the same age) they’re often grouped by capability – some classes need more time and effort and revision of material than others, whilst the top groups delve into subjects at a deeper level.

A teacher has an hour to achieve a goal before moving on to the next goal with a different group. During this hour, they will typically outline the thing to be done or learned, then work with the class to help them get there. This naturally results in questions (interruptions) continuously. It’s in the teachers best interest to answer these questions well to ensure that individuals maintain pace with the group, but paradoxically the more questions that are asked the slower the group can move forward, as spending time explaining material again for the benefit of one means that those who do understand it already are not really learning for the time period it takes to get the one who asked caught up. Thus in my uneducated opinion, the priority for the teacher is to get the effectiveness of the first explanation of any material perfected (as closely as possible given the ability of the class) ensuring that most of the time most of the class (if not all) comprehends it to a suitable degree on the first attempt. This minimises interruptions and enhances learning for all, as the class learning velocity is kept high.

This problem is outside the scope of what I want to talk about but it is relevant, because one side effect of this we-must-acknowledge-interruptions behaviour is that I feel it becomes habit. Being interrupted a lot becomes the norm, and it is my opinion that this encourages the teaching individual to also be the one interrupting others more.

Let’s go back to the classroom. You have one hour to teach a group of 33 twelve year olds about some algebra. You fire up your laptop and switch the projector on to find that no matter how you try you can’t get an image to appear on the board. This unplanned interruption has immediately taken up brain power and, critically, time, even if you have backup plans for each and every lesson. As you have chosen to use the technology resource you have clearly decided that it is important, so we can assume that without that resource your teaching and the students learning will be less effective. You are after a fix for this problem quickly. The quality of your teaching is likely somewhat diminished and the longer this goes on the worse this gets.

So you do what anyone in your situation does – you try and get it fixed. This is where tech support comes in. You make a phone call or send an email to that tech you like, or if you’re a hero, log a ticket on the ticketing system. The hero did the right thing – logging a ticket. No complaints from me there. (Pro tip for techs reading this: make every avenue of communication a ticket generating event!)

However emailing an individual or phoning interrupts the support techs. This is often warranted and is always understandable, and your job is a constant stream of interruptions so one more won’t hurt, right? This is where, unfortunately, tech support suffer. We operate in the opposite universe. Your tech problem, as a teacher, is probably one of your biggest current problems. And we totally get that. Promise. We really do. But… it probably isn’t our biggest problem and is almost certainly not something we’re going to want to deal with right away.

An interruption to us does not progress anything, it in fact stops everything. If we are in the middle of resolving another problem, being forced to stop for a reason (whether it’s to deal with a major issue or respond to a phone ringing or being pulled out of the moment by a name being called) causes us to disconnect from “the flow” and at best mentally change gears, at worse slow the brain CPU way the heck down. This is jarring and as evidenced by the many articles published about interruptions can in fact be damaging, both mentally and economically.

The more this happens the less effective overall an individual or a team can be. I argue that an ops team lead (Helpdesk Manager, IT Director, etc) should put work into minimising interruptions for the betterment of the team and yourself, regardless of your vocation or the objectives of the team. Here’s what I propose you can do to help within your tech support team regardless of work environment… Though you will likely need managerial sign off on some or all of these. It’s worth noting that I didn’t come up with these, they’re merely an amalgamation of things I’ve learned and tested which have worked for me. I am assuming you’re part of a team instead of solo hero, too, though if you are solo then interruption reduction could potentially save you from burnout. Some of these might help.

Everything should (automatically) log a ticket

Make it easy to log tickets. Saying “no ticket no fix!” feels good but doesn’t actually achieve anything for the organisation, except to piss off someone with an issue (and let’s hope that person isn’t a C-Level.) Let people call, let people email, let people visit, let people knock on the door. You can more than likely automatically create tickets in your ticketing system that come through to email, and if you can’t, get a better ticketing system. Get a generic “techsupport@” inbox set up and configure your helpdesk to add everything sent to it as a ticket. Bonus points of you reply right away (automatically of course) telling the requester that their ticket has been logged. At least they know it’s in the queue instead of sitting unread in some mystery inbox.

Ten CC’s of Triage, STAT!

Yikes, you now have a flood of tickets. This looks bad. And hey, maybe it is, but at least now you know it’s bad instead of it just feeling bad. Maybe management would be surprised to see that you’ve got 143% more tickets than you last reported, because everything is a ticket now. No more invisible work.

Anyway, I digress. Triaging tickets is essentially reviewing a ticket and deciding if it’s a priority or not. There are many ways to judge this, but typically you want to take into account how urgently this needs to be fixed and how much of an impact it would have if it didn’t get fixed.

A PCI Compliance audit deadline of two hours ago is pretty urgent – it’s something that needs to have happened already. But… the banks aren’t going to block all transactions immediately. Business doesn’t stop because you’re a few hours late on submitting a self eval form (this is not an endorsement to delay PCI compliance!)

A projector in a classroom has a pretty high impact – that’s 30+ students (plus one pissed off teacher) per hour per day. That adds up quickly. And yes, it’s pretty urgent too, but worst case the teacher can still teach like they did in 1985. Right?

Triage is important for two main reasons:

  1. It helps you and your team decide on what to work on without having to decide on what to work on
    Generally, you work on the thing with the smallest SLA time left, and if you have negative SLA counting down then you should probably get on that ASAP. Assign the Priority (the urgency and the impact) an SLA (say, high impact high urgency = 4 hour SLA, low impact low urgency = 14 day SLA – whatever you decide will be unique to you and the organisation and likely requires understanding managements expectations as well as your teams abilities)
  2. Reporting, evidence, promotions, wage increase, redundancy protection, efficiency gains, areas of focus and more!
    Having all this triage data to look back on will highlight where things are working and where they’re not, but bigger picture style. You can use the data and the knowledge that you’ve gained to more closely align the team with the objectives *and reality* of the organisation. Perhaps when triaging your tickets you could also categorise them – hardware, software, licensing, accounts? Or go one level deeper – projector, laptop, desktop, TV, printer. Office, Web browser, MIS. After time passes you can really easily see where your team spends most of its time and where resources (like money) can be allocatied to reduce load in those areas.

Triaging tickets is generally not a full time job, so you could make this person…

Hero Assignment: Interrupt Shield

Designate an “interupt hero” – this can be one person or more and ideally they would triage tickets in the queue too. If you’re lucky enough to be able to do this, put them in another room and leave everyone else in the relative peace and quiet of the main office. Make everyone else go to this smaller interrupt room for direct in person support.

They deal with all phone calls and in person visits and group emails. They also deal with any quick support calls (when not on a phonecall) that don’t require them to leave their desk and that are interruptable, for example password changes, group membership updates, etc. You should rotate this person very regularly so you’re not moving the “interrupt problem” to one person all the time, as that’s a recipe for disaster. Let them do a day at a time, or two days if you use a hero team, rotating half the team out every day so handover and “current events” knowledge transfer (what were yesterdays big issues? What’s on the radar today?) can occur more naturally.

Redirect everyones incoming calls to the interrupt hero team. This further reduces interruptions to the main body, though you may want to make exceptions for VIPs. Your interrupt hero team should be able to forward calls to you, but generally they will be able to deal with most quick things (and push to the focus team via a ticket if not, of course)

This has two advantages. First off, the toil is reduced for the team at large – your senior sysadmin isn’t doing the third password change this week for little Joe – and secondly (and most relevantly) the rest of your team can focus for long periods of time on their work. Better work is done by most of the team. Better work is better results (whether those results are money/profit or a higher quality of education.)

Don’t overload on active tickets

Don’t assign anyone (including yourself) too many tickets. There is no perfect number – it’s different depending on role, personality, type of work, and many more factors. But try and get a ballpark. I would suggest starting with no more than 10 non-pending tickets (for clarity, I define a pending ticket as one which is waiting for something outside the control of any member of the team) and only one should be worked on actively at a time. You can’t install a printer whilst also diagnosing wireless issues. Pick one. Focus.

Low remaining (or negative/expired) SLA first

Plucking tickets from the queue because they look easy isn’t productive, long term. But it’s fine, short term. Don’t sweat it, manager. But keep an eye on it.

Tickets should be worked based on their SLA, accounting for the available suitable resources (don’t put the guy who sucks at DNS problems as the lead on critical DNS problems – train them? Yes. Rely on them? No.)

Sometimes it’s nice to jump 70% down the queue and grab a few easy tickets. It feels like a break.

Just don’t make it a habit.

Having repeat logs of the same call that has gone unanswered for three months is – you guessed it – yet another interruption. Old (the definition of which is, essentially, defined by your SLA – expired SLA? Ticket is old!) tickets should not exist (with very very few exceptions. Like budget availability.)

Don’t judge people on their call closure rates

How many tickets I’ve closed vs the other techs means absolutely nothing. Get honest feedback from the source – ask the staff and, yes, the students, to rate the support. Then pay it attention. This feedback is so valuable. Whenever a ticket is closed, automatically send a followup email asking for feedback, and make it quick. You want the emotional immediate feedback, not the “dwell on it for three days and [calm down/forget]” feedback.

  1. Was the support: [] Amazing! [] Ok! [] Shit!
  2. Optional comments here:

Negative feedback is the most valuable information you can possibly obtain

I argue that getting positive feedback means absolutely nothing, except as a “look how great we are, CEO!” line in the yearly review meeting. The feedback you really want, the feedback with actual damn value, is the negative feedback. And it’s all well and good getting it. But make sure to pay attention to it, don’t let it sit in the database doing nothing. Analyse it. Understand it. This is the closest you’ll get to dipping your hand in the metaphorical technological currents of your organisation. You’ll be able to feel the effect of the teams work, and when something goes against the current, you can fix it immediately.

This makes better, happier staff and students. Better happier staff and students equals better results. Which equals… you guessed it, fewer interruptions.

Interruptions aren’t going away, but you can reduce them. And when you do, that firefighting feeling will decrease, work quality and rate will improve and as a direct result the stability of the environment should improve, too. And when the stability of the environment improves, the interruptions decrease.

At least, that’s my experience.

There’s plenty more about this on the internet at large, much better explained and with additional steps than what I have listed here, however I feel that these steps are the big hitters that might just give you enough time to step back and take a real close look at the bigger picture without worrying about where the next fire will start. And it’ll take time. But it will work.

Receiving unsolicited blogging advice

TL;DR: me post more!!1!

I recently read a blog post about a blog post and came to realise that I too struggle to post stuff on this very blog. I am conscious that I suffer from the curse of “I must make everything interesting!” but… maybe I don’t have to suffer any more. Maybe I don’t have to care. After all, if you don’t like it, you don’t have to read it.

I started this corner of the web to document my renovation and tech stuff for me and myself only. And Ben. (Hi Ben) But somewhere along the way it started to be about what other people find interesting, and… nothing really felt big or important or interesting enough. Hence the lack of posts recently.

So, a reset. Time to post more. They may not fit the predetermined categories, they may be completely uninteresting, but it turns out that not only is that okay, it’s what I intended originally anyway. They’re interesting to me, and besides I suspect I read these posts more than anyone else. Maybe, just maybe, someone else will find something a little bit interesting or useful too? That’ll be a positive bonus.

The algorithms and view counts hold no sway. I forbid thee!

Don’t Trust Copy & Paste – even with JavaScript disabled

I’ve seen a few articles recently advising readers to not blindly copy/paste code from a website into your CLI directly because, with a small bit of JavaScript, you can overwrite the clipboard.

This is something that has been known about for a while and for some reason has seemingly resurfaced recently. The advice is to always paste into a text editor first to ensure what you think you have copied is actually what you have copied. However, I have seen comments about how you should disable JavaScript unless you need it in order to prevent this from occurring.

As awkward as this “disabling JavaScript” advice is on the modern web (and it does require some technical knowledge to enable just what you need) I agree, and in fact disable JavaScript by default. However, for this particular issue, this doesn’t matter. You can achieve essentially the same thing without any JavaScript.

The stuff below isn’t new. In fact, in the linked article is a link to a reddit thread where someone outlines this exact problem. But I feel that it can’t hurt to reiterate. And explore!

So, for the obligatory warning: Don’t paste anything on this page into a Powershell window. Don’t paste it into anything but a text editor. The examples below shouldn’t be harmful but… look, just don’t risk it, okay?

Oh, and disable JavaScript if you want.

Malicious String – copy and paste the below example into a text editor (NOT a Powershell window)

echo ‘hello,
copy c:\inetpub\www\config.php c:\inetpub\www\config.php.txt -whatif
echo ‘hello world!’

Let’s explore how we got here and what we can do about it.


Light-up Spinning Top in the Dark

Something about these toys appeals to me. The Kid got a few so I snapped some pictures, expecting a blurry mess. And that’s what I got, but in a good way! I love how the projected red light looks in the longer exposure photos.

Tales from Tech Support 02: The Server Room is Nuts

I’ve said previously that things come in threes. This particular month in 2020 gave us three quite severe issues in the server room at work.

One – as the tide comes rolling in

We had some heavy rain in early October over a weekend. I spent the majority of that time in front of the fireplace until work on Monday morning.

Before I even got through the office I was alerted to a flood in our server room. I rushed down there to find an absolute mess. We are unfortunately strapped for space and also use the server room to store our spare equipment and some peripherals and consumables. We lost quite a lot of stuff due to water damage however most of it was old so doesn’t hold much value. There were some switches that got soaked, and also my own personal Draytek I was going to use as a secondary VPN (ours wasn’t great at the time) during lockdown in case of emergencies.

You can see in the following image a “tide line” around the walls of the room – we had about an inch of water in there that slowly soaked away. A phenomenal amount of water given the size of the room and the fact that there are sizeable gaps under the two doors that allow water to escape to neighbouring rooms

Somehow our servers didn’t get too wet. Humidity was at 90%+ for quite a while though, and we have experienced several hard drive failures since which were likely related.

After three days of drying, ripping up carpet and sorting through our stuff we could finally get back to the normal slog. However we learned that the fitted Aircon unit in the room doesn’t have a cut off for drying the air. It’s either on or off, and only when manually set. We can’t set a target humidity. In a server room you typically want to hover at about 50% – too high and the moisture in the air corrodes internals, too low and static electricity can more easily discharge in the dry air. Before ripping out the carpet and other detritus we’d hover at about 50-70% without any flood water in the room, but since then we’ve gone as low as 30%.

We need proper climate control and monitoring. And for the leak to be fixed… It has been an issue for a while which involves the design of the roof – water does drain away but if there’s too much too quickly, or the drainage is blocked as was the case this time, the water overflows and somehow finds it’s way to the ground through the second path of least resistance… Which just so happens to pass right through the server room about two feet in front of the cabinets.

Two – splashback

About two weeks after the first incident we had more heavy rain. More water in the server room. Luckily not as much water and because the room was empty and carpetless it dried out within a day. Unfortunately it came in through a slightly different part of the ceiling about half a foot closer to the server rack.

I’d love to get up on to the roof to try and figure out where this water is getting in. I’m told the fix is “new roof” but wonder if making a path for the water to escape by which doesn’t pass through one of the most expensive rooms on the campus is feasible. Not a fix, certainly, but a workaround until we can move the servers (which we should be moving before the end of this year.)

Three – this is nuts

Finally (at least I hope) is this, which happened about a week after flood #2:


We saw him on the camera we set up after the first flood. We raced down there and eventually managed to coerce it out from its temporary home directly under the server rack before it could eat through anything. There have since been more squirrels find their way into the building but none have yet braved the server room. For fear of drowing, I suspect.

Although management doesn’t particularly care about incident management and response reports, I find the whole process fascinating. So I wrote up an incident report for the squirrel invasion and it was quite entertaining to type out to say the least. So many puns.

Error b8bb2b3e on HP Office Jet Pro 8710

TL;DR: Try disabling “SNMP Status” for the port on the Windows print server in Print Management. No guarantee this will work everywhere but it appears to have worked for me. Give it a go, let me know!

Turn the SNMP Status Enabled box off

Printer says… what, exactly?

Feel free to skip the rest of this post. It’s just the sequence of events that took me to the supposed conclusion/solution.

I arrived at a customer site to find a stack of issues, but one in particular caused some confusion to my smooth-brained self. A HP Office Jet Pro 8710 printer, which worked up until last Wednesday, had a black screen with an error on it stating:

There is a problem with the printer. Turn the printer off, then on.

I of course tried a reboot. The printer switched on, booted up and appeared to be fine. But after 5 to 10 seconds it would make a clicking noise, the screen would flash blue, then go black with the same error. I hate printers.

It looked like there was some white text on the blue screen so I recorded it with the phone in slow motion and picked up an error code: b8bb2b3e

Googling this took me to one relevant result, a post on the HP forum with no replies. Great. I hate printers (I may say this several times) and I hate an error code with no official documentation anywhere on the internet. So, what is one to do in such a situation?

Well, poke about, push buttons, and hope you figure out a pattern, obviously!

My immediate thought was something PrintNightmare related, however as the post on the HP forum was made in April I moved that away from the forefront of my mind for now and started looking elsewhere. As luck would have it, I noticed that the error occurred just as the Wireless light finished flashing (because yes, this printer is connected to a domain network wirelessly. Literally the definition of evil.)

I plugged in a network cable that I pinched from a nearby desktop and the printer stopped crashing. Great, progress! This building had a new wireless network installed a couple of months ago so I began poking at that but nothing had changed in the last couple of weeks. Instead, I moved across to the Print server to change the ports over to the new IP address the device has from the wired network assuming it was wireless related and… pop! Blue screen with b8bb2b3e again. My head flipped back around to PrintNightmare patch issues or something up with the server. I didn’t really have a direction of travel from this point as Event Viewer had nothing of interest in it as far as I could see, but I decided to send the printer a Test Print just before it connected. I’ve seen before issues with printers where it’ll process an existing queue of work and then crash out or error, indicating that the core technology (network, server, printer) is functioning but some feature is causing an issue, and that’s exactly what I saw here. The device connected to the wired network, sent out the test print page, then immediately crashed out again. Historically I’ve fixed this (rare) occurrence by removing and re-adding the printer to the print server but I decided to poke around some more and try to nail down which setting was causing this (if, indeed, any at all.)

Luckily it didn’t take too many attempts to switch off SNMP Status Enabled, reboot the printer, and not see any crashes. The printer is still working a few hours later (back on the wireless… grr. We’ll run some cable into this particular office soon) and I have since checked Windows Updates installation date – the printer stopped working right after updates were installed on the server. The server was up to date prior to this month’s (July 2021) patch release so it does look like something in the most recent set of updates caused this. And yes, I have ensured the server is not vulnerable to PrintNightmare by checking for those registry keys, so it’s not that.

If I unveil the exact cause I will update this post.

Kaseya Says Yes

I just read the truesec analysis of the Kaseya VSA 0-day that hit the news earlier in the month. I love reading articles like this, but this one in particular I had to highlight.

The authentication… “bypass”… utilised as a first step: D’oh! How did something like that even get into production? The linked article has more details but essentially, if all authentication checks fail (when querying this particular file, not generally) instead of saying “Nope, you are not authenticated!” they instead say “Oh, you don’t supply a password that we can verify? Ok, let’s give you authenticated status anyway👍”.

Logic failures like this generally don’t happen in the ideal world because they’re blindingly obvious, so allow me to speculate for the rest of this paragraph. I can only assume that a developer temporarily set this up to diagnose a bug or test a feature and simply forgot to flip it back to “fail by default”. This is why peer review is important, though the rush to get things out to production works against this. It’s too easy to miss this kind of thing in the modern world. It shouldn’t be, but it is. There should be no blame here on any individual – I suspect a process/procedure needs to be looked at, or a team needs to be better resourced.

Visitor Information Disclosure in wp-statistics

Just noticed this and when Googling it has been picked up already, so this isn’t new, but the wp-statistics module (v13.0.8 for sure but likely other versions too) seems to be logging information into the “wp-statistics.log” file in the root directory of the site it is installed on. You can therefore access it and in some cases read the IP addresses of visitors to a site if they have the addon enabled by visiting domain.tld/wp-statistics.log.

You can block external access to it in the .htaccess file via:

<Files "wp-statistics.log">  
  Require all denied

I’ve logged an issue on their github page, hopefully they fix this soon 2021-07-22: a fix will be pushed out this weekend according to the latest update on the issue.

A quick google dork will show up a fair number of affected sites, including some… potentially embarrassing ones.

GLPI – Ripe for the Injecting

I’ll move on from GLPI eventually and start working on some interesting technical stuff, but today is not that day.

We ditched GLPI after we got hit by an accidental SQLi from HaveIBeenPwned – in short, version 9.4.5 is vulnerable to an SQL Injection flaw. You can exploit it by sending it an email (say, to helpdesk@company.tld) and once the email gets automatically turned into a ticket and assigned, the SQL will be executed. This affected us because the obscenely simple execution string was included in the header of the haveibeenpwned email notification.

I’ve just been poking around GLPI again (we have kept it around for non-end-user stuff, isolated and kept out of reach) and noticed that there was a “telemetry” scheduled task in the list of Automatic Actions which got me curious.

GLPI have decided to publish some of their telemetry data, which is nice of them. But it shows that there’s still a significant number of users running 9.4.5 and older.

Of the installs that report telemetry in the last year (and only those installs on 9.2 and above do this), 14,313 are on a version at or below 9.4.5, whilst 26,985 are on 9.4.6 and above. Over 34% of GLPI installs are potentially* vulnerable to this painfully simple exploit but over 12% of installs absolutely are still vulnerable as they’re on 9.4.5 exactly.

*Potentially, but I suspect only 9.4.5 is vulnerable – they fixed it by accident in 9.4.6 here which looks like a response to an issue that appeared in 9.4.5.

We learned a lesson with the GLPI issue – keep your software up to date. Though to be fair to us, it was up to date according to their website at the time. There was a newer version available (9.4.6) but that wasn’t advertised anywhere.

I hope these out of date installs get updated. We know there’s a lot of malicious activity out there, but at the same time… accidents can happen.


I love how ice looks when it forms on something smooth and flat like glass. If I didn’t have to scrape it all off in a hurry to get to work I’d stare at it for at least two minutes. What? It’s freezing out there…