The First Real Reboot, and the RDP Rabbit Hole

I killed the power to the box for the first real reboot, a full shutdown and cold boot, and didn’t touch a key again: no PIN entered, no console login, nobody at the keyboard. That was the test that mattered: whether the setup held with nobody there to help it along.

BIOS tuned, disks cleaned, SSH hardened, Tailscale meshed, a GPU power-limit task wired to boot: all of it configured on a machine that had never been cold-booted with nobody at the keyboard. If this box is going to be a headless server I drive from a MacBook across the room, or from another country, this is the moment that tells me whether any of that setup holds.

Then I opened a terminal on the Mac and started poking.

What held

The GPU came back at 240W. nvidia-smi -pl 240 lifts the RTX 3060 from its 170W default to its own ceiling, but on Windows that setting evaporates on reboot. It isn’t persistent, so I’d wired an ONSTART scheduled task running as SYSTEM to re-apply it. Post-reboot, before I’d done anything:

$ nvidia-smi --query-gpu=power.limit --format=csv,noheader
240.00 W

Task fired, limit re-applied. Confirmed persistent — the scheduled task re-applied the limit, not something that survived the reboot on its own. Hardware-Accelerated GPU Scheduling checked out too: HwSchMode=2, still on.

The clean PATH loaded as well. Part of the earlier cleanup had been trimming a bloated system PATH: nine dead entries (old JDKs, IntelliJ, a Flutter install from 2021, a couple of stray ;;) plus five case-duplicate System entries, down to twenty real ones. A fresh login rebuilds PATH from the registry, so a reboot is exactly where sloppy environment edits would have shown up.

The proof I cared about most was the locked-screen control: rebooted, stopped at the lock screen, no one logged in, and yet a plain ssh box whoami still answered. query session confirmed it:

$ ssh box "query session"
 SESSIONNAME  STATE
 console      Connected
 ...

Connected, not Active: the machine is sitting at the PIN prompt with no user session running, and I still have a full shell on it — key-only, same as the SSH setup from earlier in this build. That’s why OpenSSH runs as a Windows service instead of a per-user thing: the service starts before anyone logs in, so it answers SSH at the lock screen with no PIN, no keyboard, no monitor.

Three for three.

What it broke

tailscale status from the Mac: the box was Not Connected. Everything else had come back login-free, but Windows Tailscale runs as the logged-in user by default, not as the system — it only connects after someone logs in, so no login meant no tunnel.

At home it didn’t matter; my LAN SSH alias still reached the box directly on the home network. But the entire point of Tailscale was reaching it from anywhere, and “anywhere” is exactly when there’s no one home to log in and wake it up.

The fix mirrors the sshd lesson:

tailscale up --unattended

--unattended sets ForceDaemon=true, so Tailscale runs as a daemon that comes up at boot and stays up through logout and login-less reboots — confirmed on the next reboot.

Always-on wasn’t one switch — it was a property tracked per service: sshd-as-a-service was already boot-level, Tailscale-as-an-app was login-level, and the two looked identical until the moment one mattered.

Then RDP, and the credential rabbit hole

SSH gives me the CLI and the scripts. Some things want a full desktop, so next was RDP.

Turning RDP on is a checkbox. Doing it safely is the work. Windows enables a firewall group called “Remote Desktop” that lets in the whole LAN by default. I closed that off: RDP now answers only over the tailnet, with NLA required.

Then I tried to log in and fell straight down a hole.

Attempt one: connect as email@…, the Microsoft account. “The credentials did not work.” Fine, maybe wrong format.

Attempt two: net user shows the account is passwordless, PIN-only, Windows Hello. My working theory: Windows blocks blank-password network logon by default, and a PIN isn’t a password, so a network logon had nothing to authenticate with.

Attempt three: just set a password, with net user <account> *:

System error 8646 has occurred.
The system is not authoritative for the specified account...

Error 8646, because it’s a Microsoft account — not the blank-password block I’d assumed. The password is held on Microsoft’s servers, not the local SAM database, and net user has no authority to touch it.

The resolution was to stop fighting the identity and make a new one: a dedicated local account with a real password, added to the Remote Desktop Users group, never the day-to-day identity. RDP rides its own dedicated credential, kept apart from the primary Microsoft identity.

The guardrail, for the second time

When it came time to mint the account and set a plaintext password, the assistant’s own safety layer refused. It wouldn’t create the account or write the password. I ran them by hand — the same wall the SSH work hit when a hook refused to write ~/.ssh/config because it protects credential paths.

Second occurrence, same principle: the tooling will not mint or store credentials for me, and every time it’s right. An agent with this much access to my machines is exactly the one that must never silently create a login or drop a password into a file. I do that step by hand, on purpose.

The payoff: a full Windows desktop from the Mac and from the iPhone using Microsoft’s Windows App, over the tailnet, from anywhere.

Next up: getting the whole box filesystem into Finder, and why I picked the lighter tool over the one that technically does everything.