Files

Mike Swanson 384f5967e9 sync: auto-sync from GURU-BEAST-ROG at 2026-07-10 18:44:07

Author: Mike Swanson
Machine: GURU-BEAST-ROG
Timestamp: 2026-07-10 18:44:07

2026-07-10 18:44:56 -07:00

6.0 KiB

Raw Blame History

Session Log — Goldstein: ASUS-2024 -> DALLAS RDP completion + Sheldon local account

User

Executed by: ClaudeTools Discord Bot (GURU-BEAST-ROG)
Requested by: Mike Swanson (@azcomputerguru, via Discord) - admin
Role: automation (acting on the requester's behalf)

Session Summary

Follow-up to Howard's #32490 work (DALLAS Home->Pro upgrade + RDP enablement, 2026-07-07). Mike reported via Discord (thread 1525291727911653530) that Sheldon Goldstein's staff couldn't RDP from ASUS-2024 to DALLAS because DALLAS was signed in with a Microsoft account — MSA + Windows Hello PIN blocks RDP password logon under NLA.

Verified connectivity first via GuruRMM: ASUS-2024 (Goldstein/Dallas site, traveling laptop, currently in Phoenix on 192.168.0.200 Wi-Fi) reached DALLAS 192.168.1.226:3389 with TcpTestSucceeded=True over the OpenVPN Connect tunnel Mike and Howard set up earlier the same day. Network path confirmed good; the blocker was purely MSA authentication.

With Mike's go-ahead, dispatched two RMM commands: (1) on DALLAS, set HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PasswordLess\Device\DevicePasswordLessBuildVersion=0 to allow Microsoft-account password sign-in (re-verified fDenyTSConnections=0, TermService running); (2) on ASUS-2024, created C:\Users\Public\Desktop\RDP DALLAS.rdp (full address 192.168.1.226, username hint, prompt for credentials, NLA-compatible).

Mike then superseded the MSA-password route: he used Profwiz to migrate Michelle's Microsoft-account profile on DALLAS to a local account Sheldon and created a matching Sheldon local account on GS-BACKUP so its SMB shares authenticate with the same credentials. Password set to never expire on both machines. Bot vaulted the credential and updated the Goldstein wiki article (endpoints, access, patterns, history).

Key Decisions

Verified connectivity before touching auth — a single Test-NetConnection from ASUS-2024 proved the new OpenVPN tunnel carried 3389 fine, isolating the problem to MSA/NLA authentication.
Local-account migration (Profwiz) chosen over the MSA-password dance — Mike's call; avoids the fragile "type the MSA password once to cache it" prerequisite and any future Hello/passwordless regressions. The registry fix remains in place but is superseded (harmless).
Matching Sheldon account on GS-BACKUP — same username/password means Windows SMB auth to the Tucson share box works without stored-credential juggling.
Password never expires on both — deliberate for an unattended RDP target; noted in vault entry.

Problems Encountered

DALLAS agent hostname is Dallas (not DALLAS) in GuruRMM — exact-match jq filter missed it on first resolve; found via client-scoped listing.
None otherwise; both RMM dispatches exited 0 (stderr contained only benign CLIXML progress noise).

Configuration Changes

DALLAS: DevicePasswordLessBuildVersion=0 (HKLM ...\PasswordLess\Device) via RMM cmd 136e69fd. By Mike (manual): profile migrated MSA -> local Sheldon via Profwiz; password never expires.
GS-BACKUP: local account Sheldon created (matches DALLAS, for SMB shares); password never expires. (By Mike, manual.)
ASUS-2024: C:\Users\Public\Desktop\RDP DALLAS.rdp created via RMM cmd cb533e62.
Repo: wiki/clients/goldstein.md updated (endpoints table, Access, Patterns, History, sources/last_compiled).

Credentials & Secrets

Vault: clients/goldstein/windows-sheldon-local.sops.yaml — local Windows account Sheldon, password Gerdrude788!, valid on DALLAS and GS-BACKUP, never expires. Documented use: RDP from ASUS-2024 (over OpenVPN) to DALLAS; SMB share auth on GS-BACKUP. Created + verified this session.
Referenced (not modified): clients/goldstein/openvpn-remote-access.sops.yaml.

Infrastructure & Servers

DALLAS — 192.168.1.226; agent 36c7bbc8-504f-4b4a-8995-3b3e5cdc0f02 (hostname Dallas in RMM); RDP host 3389/NLA; primary logon now DALLAS\Sheldon.
ASUS-2024 — agent f50b17c1-a711-4e80-89c2-03cb630f5622; traveling laptop, seen in Phoenix (192.168.0.200 Wi-Fi); OpenVPN Connect DCO adapter to Goldstein network; reaches DALLAS 3389.
GS-Backup (Tucson) — agent 4f52ef22-89ae-4124-a2b4-d339aaf42f53; hosts SMB shares; new local Sheldon account.
DalRes10 (Tucson) offline at time of session.

Commands & Outputs

Recon (ASUS-2024, cmd cdbeeddd): IPv4 list + Test-NetConnection 192.168.1.226 -Port 3389 -> TcpTestSucceeded=True (via OpenVPN, from Phoenix).
DALLAS (cmd 136e69fd): DevicePasswordLessBuildVersion=0, fDenyTSConnections=0 TermService=Running.
ASUS-2024 (cmd cb533e62): Created C:\Users\Public\Desktop\RDP DALLAS.rdp (129 bytes).
All dispatched via ps-encoded.sh (quote-safe); alerts posted to #dev-alerts.

Pending / Incomplete Tasks

User click-test: Sheldon/staff to RDP from ASUS-2024 as DALLAS\Sheldon and confirm the migrated profile looks right (desktop, files, Outlook). Not yet human-verified.
Syncro: Mike did not request a ticket; #32490 already invoiced/closed. Open question whether today's work (VPN + this) gets billed separately — Mike/Winter to decide.
Prior open items stand: DALLAS Windows updates + reboot pending; no backup agent on DALLAS.

Reference Information

Discord thread: 1525291727911653530 (#botmagic, Mike).
RMM command IDs: cdbeeddd (recon), 136e69fd (registry), cb533e62 (shortcut).
Vault: clients/goldstein/windows-sheldon-local.sops.yaml.
Prior logs: clients/goldstein/session-logs/2026-07/2026-07-07-howard-dallas-rdp-pro-upgrade.md, 2026-07-06-howard-dallas-rmm-onboard.md.
Wiki: wiki/clients/goldstein.md.

Update: 18:20 AZ — Warranty hour on #32490

Per Mike (same Discord thread): added 1.0 hr Labor- Warranty work (product 1049360, $0.00, line item 43227261) to ticket #32490 and posted a customer-visible (not emailed) follow-up comment (423248339) describing the MSA->local-account fix and VPN-verified RDP. Ticket remains Invoiced; no invoice change. Bot alert posted to #bot-alerts.

6.0 KiB Raw Blame History