RustDesk Deployment

Why RustDesk

Remote access to club workstations was always a pain point. We had tried a few commercial solutions, but the per-seat licensing at 100+ locations made them expensive. And some of them didn't handle unattended access well, which was the whole point for us. Most of the time, nobody was sitting at the workstation when we needed to troubleshoot something.

RustDesk caught my attention because it's open source and supports self-hosted relay servers. You spin up your own server, point the clients at it, and all traffic goes through your infrastructure. No third-party relay, no per-seat fees, full control.

The deployment problem

Getting RustDesk installed on 100+ workstations wasn't the hard part. We could push the MSI through our RMM tool. The hard part was configuring each one to talk to our server. Every client needs a config file with the relay server hostname, the server's public key, and an unattended access password. You can do this manually through the RustDesk UI, but that's not happening at scale.

The config lives in a TOML file under the LocalService profile. The script creates the directory, writes the config with all the right options enabled, sets the password via the command line, and restarts the service. Once it's done, it spits out the RustDesk ID so you can log it for your inventory.

$d = 'C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\RustDesk\config'
New-Item -ItemType Directory -Force -Path $d

@"
[options]
id-server = "${ServerHost}:21116"
key = "$ServerKey"
verification-method = "use-permanent-password"
access-mode = "custom"
enable-keyboard = "Y"
enable-file-transfer = "Y"
enable-terminal = "Y"
"@ | Set-Content -Path (Join-Path $d 'RustDesk2.toml') -Force

& $exe --password $Password
Restart-Service -Name RustDesk -Force

Config decisions

We enabled pretty much everything: keyboard, clipboard, file transfer, terminal, remote printer, audio, session recording. The access mode is set to "custom" which means the permanent password controls who gets in, rather than requiring someone on the other end to approve each session. For unattended workstations at club locations, that's the only option that makes sense.

Session recording was one I debated on, but it turned out to be useful for training. When a junior tech remoted into a workstation to fix a printer issue, the session recording gave us something to review if the fix didn't stick.

Rolling it out

The script is parameterized so the server hostname, key, and password aren't hardcoded. That made it safe to push through our RMM without sensitive values sitting in a script on every workstation. The RMM tool passes the parameters at runtime.

Deployment went out in batches of about 30 locations at a time. After each batch, I'd verify a handful of connections to make sure the relay server was handling the load. The whole rollout took about two weeks, mostly because I was being cautious about overwhelming the relay server.

The end result was a fully self-hosted remote access setup across every location. No subscription fees, all traffic through our relay, and every workstation accessible with the same password. It's been running for over a year now without any major issues.