Disaster recovery was one of my responsibilities at the major national retailer, and we had some disasters, and that’s how the truth about inventories comes out. During one recovery effort, we were hunting for a machine. It existed, systems were talking to it, work depended on it, and we couldn’t find it. Not in the server room, not in the racks, not anywhere a server was supposed to be.
An IT storage room full of retired desktops, monitors and phones. Rooms like this are where machines quietly drop off the inventory. Copyright © Richard Lowe.
We found it under a user’s desk in accounting.
The user was no help on how it got there, and why would she be?
Her account was simple: one of your guys came over six months ago and stuck it here. Somebody in IT, identity lost to history, had needed a home for a machine. There was no place in the server room. He solved the problem the way tired people solve problems. Wherever it fits. And under that desk sat a critical server, running homegrown software probably ten years out of date, humming along in the dark.
I still think about that machine. If it had died instead of just going missing, I’d have been the one explaining to the business why we couldn’t restore a system nobody knew we had. Recovery was my job, and my plan had a hole in it the shape of somebody’s desk.
What the desk server was
Count the failures stacked on that one machine.
It wasn’t in the disaster recovery plan, so the recovery I was responsible for would have silently omitted a system the business depended on. It wasn’t in the transformation plan either: our modernization program, which touched literally everything else, had never touched it, because the plan was built from an inventory and the inventory didn’t contain it. It wasn’t patched, not monitored, not backed up on any schedule anyone could name, and physically accessible to anyone who could reach a desk in accounting.
None of this was anyone’s decision, and I find that harder to deal with than carelessness, because carelessness has a name attached and you can correct it. No one chose to run a critical system on decade-old software under a desk. The situation assembled itself from small expediencies and then persisted because nothing forced anyone to look. Unknown systems don’t age on a maintenance schedule the way known systems do. They age like the contents of a wall you sealed up years ago.
How does a system escape the inventory?
The desk server’s biography is worth reconstructing, because it’s the biography of every shadow system. It began legitimately: a real business need, real software written for it, a real machine deployed. It escaped at the moment of placement, when “no room in the server room” met “just put it here for now,” and for now did what it always does. It survived because it worked; systems that fail get found, and this one hummed along for years because it never demanded attention.
And turnover orphaned it, when whoever placed it left or forgot, taking the last copy of its existence out the door in their head.
Need, expediency, reliability, turnover. No villain appears anywhere in that sequence, so policy alone never prevents it. There’s no decision point at which anyone chose wrongly enough to stop. The only reliable counter requires no memory and assigns no blame. Periodic discovery, enumerating what’s on the network, then confronting the official list with it.
| Stage | What happened with the desk server |
|---|---|
| Need | A real business need, real software written for it, a real machine deployed |
| Expediency | No room in the server room, so it went under a desk “for now” |
| Reliability | It worked for years and never demanded attention, so nobody looked |
| Turnover | Whoever placed it left or forgot, taking the last record of it with them |
| The counter | Periodic network discovery reconciled against the official asset list |
We found a critical server under a desk in accounting, running decade-old software, missing from every plan. Survey before you transform.Share on X
Why survey your systems before a transformation?
Unknown systems don’t age on a maintenance schedule the way known systems do.
The lesson I took, and the one I hand to every executive planning a transformation: really survey your systems. Know where every machine is, what it runs and what depends on it before you draw the plan. Trust the inventory the walls and desks contain over the one the spreadsheet claims, and verify it by scanning the network and physically walking the spaces. Our desk server would have shown up on a network scan years earlier if anyone had reconciled the scan results against the official list.
A transformation plan built on an incomplete inventory is a plan for the company the spreadsheet describes, and the gap between those two companies is where the post-transformation surprises live: the critical process that breaks because it depended on a machine nobody migrated, the security incident on a system nobody was patching, the recovery that fails because the plan never knew what it was recovering.
My take
Survey every system before you draw a transformation plan. Scan the network, walk the desks, and reconcile what you find against the official list. Our critical server sat under a desk in accounting, unpatched and missing from every plan, because someone in IT had nowhere else to put it years earlier. Nobody did anything villainous. Shadow systems assemble themselves out of small conveniences. Periodic discovery finds them, and policy alone won’t.
The question that finds desk servers
Every organization above a certain age has at least one of these, and executives are reliably certain theirs doesn’t. The test costs one meeting. Ask your IT leadership: when did we last reconcile a full network discovery scan against our official asset inventory, and how many devices were on the network that weren’t on the list? If the answer is a number, you have a team that hunts desk servers. If the answer is confidence without a number, you have desk servers.
And if you’re an executive writing about transformation, put your desk server in the book. Every practitioner reading it has found one of their own, and admitting where yours was buys credibility with that audience faster than anything else you can write. The executive who insists the company never had one either hasn’t looked or is hiding it, and I don’t want either of those people telling readers how to run a transformation.
For more from this series, see The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
Frequently Asked Questions
- CIS Control 1: Inventory and Control of Enterprise Assets, Center for Internet Security
