Files

Howard Enos 0daf06263f sync: auto-sync from HOWARD-HOME at 2026-07-07 07:13:10

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-07 07:13:10

2026-07-07 07:13:39 -07:00

7.1 KiB

Raw Blame History

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).

7.1 KiB Raw Blame History