Series · The Quiet Machine · Part 12

Cold-Reboot Self-Recovery on an Unattended Windows Server

August 30, 2026 · 5 min read · The Quiet Machine · Part 12

Part 5 proved the box could survive a cold reboot: sshd answered at the lock screen, no PIN typed, nobody at the keyboard. That was real progress, and it was also half the machine. sshd, Tailscale, and the GPU power-limit task all run before anyone logs in, so they came back clean. Everything living inside WSL2, meaning dockerd and the containers riding on it, stayed dark. WSL doesn’t come alive until a desktop session exists, and after a Windows Update reboot with nobody around to see it, nothing was walking over to type a PIN into a locked screen.

Closing that gap meant making a real desktop login happen unattended, which meant fixing the account first.

The account had to become local

The primary account on the box was a Microsoft account, the same kind of account that stopped me cold in Part 5 when I tried to set an RDP password on it and hit error 8646: the password is held on Microsoft’s servers, and the local machine has no authority to read or set it. Auto-login runs into the identical wall from a different angle. Windows has to hold the account’s password locally and hand it to the logon process on every boot, and a Microsoft account gives it nothing to hold. So the fix was the same one Part 5 already found: convert the account to a local one, with a password the machine owns outright.

That’s a separate account from the dedicated RDP login created in Part 5. This one is the primary account, the one that owns the desktop session everything else in this post depends on.

Signing in without a human

With a local account in place, Windows has a documented mechanism for skipping the logon screen entirely on boot: set it once, and the desktop opens under that account with nobody there to type anything. It’s a stock Windows feature, not something bolted on, and it only fires on the physical console at boot — the RDP account from Part 5 still needs its own credentials every time.

BitLocker unlocks itself before any of that

None of the above matters if the disk is still sitting behind a PIN prompt. Both drives on the box are BitLocker-encrypted at rest, C: and D:, and both unlock automatically, no key touched by hand. C: binds to the TPM: on a clean boot the chip measures the boot chain, sees nothing has changed, and releases the volume key on its own, fTPM 2.0, no PIN. D: doesn’t get its own TPM binding at all. Its autounlock protector is keyed off C:’s unlock instead, so the moment C: opens, D: opens with it, no second prompt, no second secret to manage. The recovery keys for both drives live off the machine, in a password vault, for the day the TPM check itself fails.

The chain, in the order it fires

  1. Power returns. AC-Back, set in Part 1, brings the board up on its own.
  2. The TPM unlocks C:, and D: rides along on C:’s key. Both volumes are readable before Windows shows anything.
  3. SYSTEM-scope scheduled tasks fire with no session at all: the Ollama service, the GPU power-limit re-apply from Part 1, and the Tailscale-and-sshd watchdog from Part 4. This is the layer Part 5 already proved reachable at the lock screen.
  4. The desktop opens automatically under the primary account.
  5. Only now does a keep-alive task start dockerd inside the WSL2 Ubuntu distro.

Step 5 has to come last, and nothing about that ordering is optional. A WSL2 distro is scoped to a user session; SYSTEM can’t see it or start it the way it starts Ollama. So dockerd waits on a real logon existing, which is the whole reason auto-login had to happen instead of leaving the box at the lock screen the way Part 5 did. The task itself is a loop rather than a normal service, because WSL shuts an idle distro down on its own after a timeout:

wsl -d Ubuntu -u root -- systemctl start docker; tail -f /dev/null

tail -f /dev/null never exits, so the task stays running, which keeps the distro attached and off WSL’s idle-shutdown clock, which keeps dockerd up underneath it.

The tradeoff

Unattended recovery trades some local security for uptime, and that was a deliberate choice. A machine that unlocks its own disk and logs itself in on every boot has a weaker physical-access posture than one that stops and waits for a password: anyone standing in front of it during that window gets the same desktop I do. I chose that tradeoff on purpose, for a box that has to come back on its own after a power cut with nobody around to type anything in.

What it proved

The same verification pass that checked the auto-login setting also pulled Get-ScheduledTask for the Ollama, GPU, watchdog, and WSL tasks, and Get-Tpm for both volumes. Then came the real test: a full cold power cycle, same as Part 5, left alone afterward. It came back the way it’s supposed to, matching the chain above step for step, without anyone typing a single character.

The box now takes a reboot, planned or forced by a power cut, and just comes back on its own: the scheduled tasks and the containers already running, the disks still encrypted, nobody in the room. Keeping it alive is a solved problem now. What’s left is teaching the model that runs on it something no downloaded checkpoint already knows.