Remote Desktop Server

Problem

Archive work means moving large files — converting them, and copying between the organisation's NFS filestores. Staff working from home were doing this over the VPN, so every transfer had extra packet size to transfer with the IPSec protocol that left the network, came back in, and crossed several switches and routers on the way. File conversions and downloads that are routine in the office were taking long enough to interfere with the working day.

The instinct in this situation is to ask for more bandwidth. That would not have helped: the problem was the path, not the pipe.

Approach

Rather than move the data to the people, move the people to the data. I proposed a Windows Server remote desktop sitting inside the network, so a user at home works as though they are on site and transfers happen local to the filestore, with scratch space on the same physical host.

Specified and rolled out with university ITS, who built it with me. I have since taken sole ownership — accounts, software updates and capacity planning.

Sizing was done from evidence rather than guesswork: watching real user workloads in Task Manager to see what CPU and GPU the work actually needed, then phasing people onto the server in stages to confirm it held under growing load. It did, at every stage.

Around fifteen staff use it.

Outcome

Transfers that previously crossed the VPN now stay inside the network.

The interesting failure came after rollout. Under concurrent use the server slowed badly, and the obvious suspect — CPU — was not the cause. The scratch drive was saturating on disk I/O; several users writing large files to one volume had made the disk the ceiling. Adding a second physical drive and splitting users across the two removed the contention.