# Session Log — Goldstein: DALLAS RDP enablement (Home->Pro upgrade)

## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech

## Session Summary

Enabled Remote Desktop into the DALLAS laptop (Michelle Goldstein's Lenovo, `Dallas\miche`) from the
Tucson office, under Syncro ticket #32490. Root cause of the "can't RDP in" complaint: **DALLAS ran
Windows 11 Home, which has no Remote Desktop host.** The Tucson<->Dallas UniFi site-to-site VPN was fine
(ping + TCP both confirmed from the Tucson side). Fix required upgrading DALLAS to Windows Pro.

Followed `reference_windows_edition_upgrade_rmm`. The job spanned two days because DALLAS is a Modern
Standby (S0 Low Power Idle) laptop: during the first attempt (evening 2026-07-06) it went offline (slept
for the day, lid closed) before the edition upgrade could run — the `changepk` and reboot commands only
queued, never executed. Verified the machine had actually been up 25 days (never rebooted); all the
"offline" stretches were sleep, not reboots. Cleaned up the stale queued commands.

Resumed the morning of 2026-07-07 once DALLAS was back online. Pinned it awake first
(`powercfg` AC never-sleep + lid-does-nothing) so it would hold a session, then ran the upgrade:
`changepk` flipped EditionID to Professional (the command times out under SYSTEM but the flip still
takes — verified EditionID directly), a `Restart-Computer -Force` finalized it to Windows 11 Pro, and
the vault Pro-for-Workstations MAK installed + activated (auto-upgraded the edition to PfW, permanently
activated). Enabled and secured RDP (fDenyTSConnections=0, NLA on, TermService Automatic+Running,
Remote Desktop firewall group enabled, listening on 3389). Verified end-to-end: from DalRes10 (Tucson)
`Test-NetConnection 192.168.1.226 -Port 3389` = TcpTestSucceeded True over the VPN. Deployed an
"RDP DALLAS" shortcut to the Public Desktop of both Tucson machines (DalRes10, GS-Backup).

Billed 1.0 hr remote ($150, break-fix) on #32490, posted a public + emailed resolution note (mentioning
the yesterday-offline / resumed-this-morning timing), created invoice 1650967814 ($150.00), marked the
ticket Invoiced.

## Key Decisions

- **Upgraded Home->Pro rather than a workaround.** Windows Home has no RDP host; RDP Wrapper was rejected
  (AV-flagged, unsupported, poor fit for a law firm). Pro upgrade is the supported fix (user chose it).
- **Enrolled/kept AC no-sleep in place permanently.** An RDP target laptop must stay awake to be reachable;
  if DALLAS sleeps, Tucson can't RDP in. AC-only (safe); battery still sleeps normally.
- **Verified EditionID directly instead of trusting `changepk`'s exit code.** `changepk` timed out under
  SYSTEM but had already flipped EditionID=Professional.
- **Followed the reference procedure after an initial hand-rolled attempt** — the first pass deviated
  (assumed changepk auto-reboots, proceeded with an active user). Corrected; logged to errorlog.

## Problems Encountered

- **Two-day span due to Modern Standby.** DALLAS slept before the first attempt finished; commands queued
  but never ran. Resolved by pinning AC no-sleep on resume and re-running cleanly.
- **`changepk` times out under SYSTEM** but still flips the edition — verified EditionID rather than
  treating the timeout as failure. Captured in the reference memory (Gotcha 4).
- **`ps-encoded.sh` failed `iconv: command not found` on HOWARD-HOME** — fell back to inline `jq --arg`
  dispatch (safe for quote-free payloads). Logged as friction.
- **Syncro comment POST returned control-char JSON that broke jq** — the comment had actually posted;
  confirmed via GET (did not retry), per the skill rule.

## Configuration Changes

- **DALLAS:** Windows 11 Home -> Pro -> **Pro for Workstations** (MAK activated, permanent). RDP enabled
  (fDenyTSConnections=0, RDP-Tcp UserAuthentication=1), TermService Automatic+Running, Remote Desktop
  firewall group enabled. Power: AC standby/hibernate/monitor timeout 0, lid-close action = do nothing (AC).
- **DalRes10 + GS-Backup (Tucson):** `C:\Users\Public\Desktop\RDP DALLAS.rdp` created (full address
  192.168.1.226, username hint DALLAS\miche, prompt for credentials).
- **Syncro #32490:** public resolution comment (422514654, emailed), line item 43163051 ($150 remote),
  invoice 1650967814, status Invoiced.
- **Memory:** `reference_windows_edition_upgrade_rmm` updated (Gotchas 4 + 5).

## Credentials & Secrets

- Windows Pro-for-Workstations MAK used from vault `infrastructure/windows-pro-mak.sops.yaml`
  (`credentials.product_key`). One MAK activation count consumed by DALLAS = $99 to customer (billed via
  the 1h remote labor on #32490). No new credentials created.

## Infrastructure & Servers

- **DALLAS** — 192.168.1.226 (Intel Wi-Fi 7 BE201), public 99.127.21.4; Win 11 Pro for Workstations
  (build 26200); workgroup; RDP host on 3389; SC session 29c62473-a5cb-4e94-a190-c91f05031809; GuruRMM
  agent 36c7bbc8-504f-4b4a-8995-3b3e5cdc0f02 (Goldstein/Dallas site SILVER-PEAK-3739).
- **DalRes10 (Tucson)** — 10.10.1.149 (Ethernet) / 10.1.10.170 (Wi-Fi), gw 10.1.10.1; RMM agent
  81cde315-013b-4acd-80d7-5ec2b9b5f084. Reaches DALLAS 3389 over the S2S VPN.
- **GS-Backup (Tucson)** — RMM agent 4f52ef22-89ae-4124-a2b4-d339aaf42f53.
- Tucson<->Dallas UniFi site-to-site VPN: routes 192.168.1.0/24 from the Tucson LAN; verified working.

## Commands & Outputs

- Edition flip: `changepk.exe /ProductKey VK7JG-NPHTM-C97JM-9MPGT-3V66T` -> timed out but `EditionID=Professional`.
- Finalize: `Restart-Computer -Force` -> `Caption=Microsoft Windows 11 Pro`, uptime reset.
- Activate: `slmgr /ipk <MAK>` -> "Installed ... successfully"; `slmgr /ato` -> "ProfessionalWorkstation ...
  Product activated successfully."
- RDP enable verify: `fDeny=0 NLA=1 TermService=Running Listen3389=True RDPfwEnabled=3`.
- From DalRes10: `Test-NetConnection 192.168.1.226 -Port 3389` -> `TcpTestSucceeded=True`.

## Pending / Incomplete Tasks

- **Windows updates + reboot** noted at onboarding (2026-07-06 diag) still pending — approve on next window.
- **No backup agent** on DALLAS — confirm whether the laptop needs cloud/local backup.
- RDP is single-session: a Tucson user connecting as `Dallas\miche` logs Michelle out locally — expected;
  communicated in the customer note.

## Reference Information

- Syncro ticket #32490: https://computerguru.syncromsp.com/tickets/113249206 ; invoice 1650967814 ($150.00).
- Reference procedure: `.claude/memory/reference_windows_edition_upgrade_rmm.md`.
- Prior log: clients/goldstein/session-logs/2026-07/2026-07-06-howard-dallas-rmm-onboard.md

## Update: session close (2026-07-07)

Session closed with work complete and billed. Added a private (internal, not emailed) follow-up note to
#32490 (comment 422520962). **Open item handed off:** final user click-test of the "RDP DALLAS" shortcut
by Tucson staff to confirm interactive logon is still pending — the technical path is verified
(TCP 3389 reachable from DalRes10 over the VPN) but no human has driven a full RDP logon yet. When tested,
confirm objectively via DALLAS Security log Event 4624 LogonType 10 (RemoteInteractive). Note: an incoming
RDP session signs Michelle out of her local Dallas session (single-session workstation OS).
