The Server I Shipped to Afghanistan

It’s 2012. I’m sitting in Virginia Beach getting a call from Kandahar Airfield at 2am. One of our guys needs a blueprint — the underground conduit layout for a section of base they’re pouring concrete on in a few hours. The file is sitting on a server in Virginia. The VSAT connection between here and there is running at something south of 1Mbps on a good night, and tonight is not a good night.

The download stalls out. They can’t work. They wait.

This is the third time this week.

A defense contractor I supported was doing serious infrastructure work at KAF — laying fiber-optic cable, running conduit through concrete manholes, designing the underground network that would eventually connect buildings across an active military installation. The blueprints for that work were massive AutoCAD files. Detailed drawings of every junction, every road crossing, every maintenance hole. The kind of files you can’t work from memory and can’t reconstruct on site.

They needed those files. They needed them reliably. And “reliably” was not a word anyone was using to describe VSAT in 2012.

The problem with satellite internet in a war zone

VSAT works by bouncing your signal off a satellite in geostationary orbit 22,000 miles above the equator. That distance introduces latency you can’t engineer around — typically 600 to 800 milliseconds round trip, on a good day, before you factor in weather, interference, or the fact that you’re sharing bandwidth with everyone else on the base. Speeds at the time were somewhere around 512Kbps to 1Mbps. File syncs that should have taken minutes were scheduled overnight and still took hours.

We were also running voice over that same connection. A five-minute call without a dropout was a small victory.

The files these guys needed weren’t small. A single AutoCAD drawing of a conduit junction could run 50MB or more. On a 512Kbps connection, that’s over ten minutes of perfect, uninterrupted transfer. At 2am in Kandahar, perfect and uninterrupted was not the baseline.

The solution wasn’t faster internet. There was no faster internet. The solution was getting the files closer to the people who needed them.

Building it stateside

The plan was straightforward: a physical file server at KAF, running Windows Server, with BranchCache enabled so the most-accessed files would be cached locally. Overnight sync jobs would pull updates over the VSAT when bandwidth was least contested. During working hours, the guys would be pulling files off a local server ten feet away instead of one 7,000 miles away.

Security was non-negotiable. These weren’t just construction files — they were detailed maps of a U.S. military installation. Underground conduit layouts. Building positions. Road infrastructure. In the wrong hands, that’s a targeting document.

The server ran BitLocker encryption at the drive level. Beyond that, the files themselves were encrypted using a DoD-specified system layered on top. Every access policy we could lock down, we locked down. The assumption was that the physical security of the equipment could not be guaranteed — this was a forward operating base in an active war zone — so the data had to be able to survive the worst case. If that server was ever taken, the data on it needed to be unreadable.

Power was its own problem. KAF ran on generator power, but military generators serve military priorities. Base power could be cut at any time — not because something broke, but because something more important needed it. We couldn’t build a mission-critical file server and then tie its uptime to a power source that might be deliberately redirected at 0300.

So I specced and shipped a UPS with the rack — enough runtime to survive a transfer or a short outage cleanly. And the client ran their own separate generator. Not as a backup to base power. As the primary. Base power was the backup.

That decision probably saved us three or four outages that would have otherwise corrupted an active sync job or left someone staring at a dead screen mid-drawing.

I built the whole thing in Virginia Beach.

Dell server. Cisco router, switch, and Meraki wireless. I cabled everything myself, port by port, color-coded and labeled. Every cable had a tag. Every port was documented. I wrote a step-by-step installation guide detailed enough that someone who had never touched a server rack could follow it and get it right.

Because that’s exactly who was going to be installing it.

The guys at KAF were construction and engineering professionals. Exceptional at what they did. Not IT people. I needed the setup process to be idiot-proof — not because they were idiots, but because I wasn’t going to be there, I couldn’t be there, and if something went wrong during installation I needed them to be able to troubleshoot it from a printed document at 3am without calling me.

When it was done I boxed everything, drove it to Fort Bragg, and shipped it on a military flight. Getting through the gate took longer than getting the equipment on the plane.

What happened when it landed

They racked it. They followed the documentation. It came up clean.

The 2am calls about file access stopped.

We still had occasional issues — BranchCache has its own quirks around version conflicts when multiple people are editing the same drawing, and low-latency syncs across high-latency connections require some patience in the configuration. But the core problem — people unable to do their jobs because a file was physically too far away — was solved.

What it taught me

Two things.

First: the right solution to a connectivity problem is not always a connectivity solution. Sometimes it’s logistics. Sometimes it’s physics. Sometimes you ship a server to Afghanistan.

Second: documentation is infrastructure. The reason that deployment worked isn’t because I built a good server. It’s because I anticipated every step of the installation process, wrote it down clearly, and handed it to people who had never done it before. The server was the hardware. The documentation was the system.

I still build that way. Every deployment I do — whether it’s a server room in Raleigh or a network buildout for a client I’ll never visit in person — gets documented like someone else is going to have to fix it at 2am without me.

Because eventually, someone will.