Running every computer in an auto shop from one console

On 12 August we committed version 1.0.0 of a desktop fleet manager for Zych's Certified Auto, an independent shop that has been fixing cars since 1976. By the end of the month it was on 2.5.0, and it now runs every computer in the building: front office, service desk, shop floor, Windows and Ubuntu side by side. This is what it actually does, and the three bugs we'd rather write down than quietly forget.

The reason to build it at all is that the shop's computers were the shop's problem. Somebody noticed a machine was wrong, somebody walked over to it, somebody fixed it by hand and remembered, or didn't, to do the same on the other thirty. That is not a technology failure, it's arithmetic: hand-maintenance costs the same per machine every time, so it stops scaling at roughly the point a business gets busy enough to care.

What the fleet does

Enrolment nobody sits through. A machine is imaged, given an enrolment code, and left alone. It comes back with its accounts, its applications, its policies and the shop's wallpaper already applied. The value isn't the automation itself, it's that adding a computer stops being an event you schedule.

Policies that don't drift. Screen lock, USB storage, AutoPlay, the firewall, Remote Desktop, SmartScreen and automatic updates are decided once in the console. If somebody changes one at the keyboard, the machine puts it back within five minutes. Configuration you set once and never enforce is a preference, not a policy.

Updates the fleet negotiates. Every machine reports its build on each 30-second check-in and compares it to the fleet's. A release that needs a restart goes through a deferral flow, because taking a computer away from somebody mid-job is how you teach a shop to distrust IT. A release that doesn't need one installs silently.

Endpoint protection that reports the truth. Malware protection installs unattended from a licence key typed once in settings. Each machine reports whether the service is genuinely running, not merely installed. Those are different states and only one of them protects anybody. The key never comes back to the dashboard and never lands in the command log.

Health the machines report themselves. Disk, memory, battery and restarts, plus three rows that audit the fleet's own work: the accounts it asked for against the ones that exist, the applications assigned against the ones installed, and whether the background actually went on. A fleet manager that only reports what it intended to do is marking its own homework.

The three bugs

We'd rather publish these than the sanitised version.

Every Windows computer enrolled as "enrolment". The provisioning script has a Step helper for logging progress, and inside it a parameter shadowed the function's own -Name argument. So each machine dutifully took the name of the step it was running when it registered. Thirty-odd machines, one word, no duplicates flagged, because as far as the system was concerned that really was their name.

A byte-order mark took down the installer. The provisioner is fetched and executed in one line, and the file was written with a UTF-8 BOM. PowerShell's irm | iex chokes on the invisible first character. It cost an afternoon, because the file looks correct in every editor you'd open it in. The bug is a character you cannot see, in a file that renders perfectly.

A working computer that looked dead. The Windows agent ran its config work inline in the heartbeat loop, so a slow MSI download blocked the check-in and the dashboard showed the machine offline for five minutes while it sat there working perfectly. The Linux agent had already solved this by backgrounding the slow half behind a lock directory, and the fix simply never got ported. PowerShell has no &, so the port needs a job or a runspace rather than a copied line, which is exactly the kind of small friction that turns into a bug six weeks later.

The common thread is that all three were invisible from the dashboard. The fleet said it was fine, and it was wrong in a way it had no way to notice. That's why 2.5.0 is the release where the machines started checking the fleet's own work rather than just their own.

What it means for managed IT

Endpoint management is the part of managed IT everybody claims and few will show you. So we're showing you: the platform is in production, at a real business, on machines that have to earn money all day, and it is linked from the front page with the client's name on it.

What we won't claim is that it generalises yet. Zych's is one estate we designed the thing around; pointing it at a network somebody else built is genuinely different work, and the build status still marks that row in build rather than operational for exactly that reason. It moved from "a documented runbook a human walks" to "a platform, on one estate", which is progress, and is not the same as done.

If you want the wider argument for why any of this beats calling someone when a machine breaks, what managed IT actually means for a small business covers it. If you'd rather just see where we stand, that's the managed IT page: beta, three founding spots, and a build status we keep honest.