sync: auto-sync from GURU-5070 at 2026-06-11 08:02:42

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-11 08:02:42

.claude/memory/MEMORY.md

@@ -124,3 +124,4 @@
 - [Refresh session history first](feedback_refresh_session_history_first.md) — read prior incident logs before acting; do not re-remediate already-handled accounts
 - [Autonomy scope](feedback_autonomy_scope.md) — confirm only for client-affecting actions; internal docs/wiki/ClaudeTools = act autonomously
 - [Check for client-slug fragmentation](feedback_client_slug_fragmentation.md) — Before concluding a client has no records, grep broadly (company/owner/initials/hostname/"Last, First") across clients/, wiki/, session-logs/, vault — one client gets split across slug variants (Wolkin was 4: wolkin/wolkin-law/rswolkin/robert-wolkin). Consolidate to one canonical slug; action prior logs' Pending items.
+- [RMM user_session = false SMB failures](feedback_rmm_user_session_smb_false_negative.md) — GuruRMM net use/net view/Add-Printer to a remote \HOST fail with error 67 / RPC 1702 (even with valid creds) because user_session is a WTS-impersonated non-interactive token that can't do authenticated SMB. The share/printer may work fine interactively. Treat RMM SMB results as "can't tell"; verify via ScreenConnect.

.claude/memory/feedback_rmm_user_session_smb_false_negative.md

@@ -0,0 +1,35 @@
+---
+name: RMM user_session gives FALSE SMB/printer failures (error 67 / RPC 1702) — verify interactively
+description: GuruRMM commands (even context user_session) run under a WTS-impersonated, non-interactive token that CANNOT establish authenticated SMB to a remote host. net use / net view / Add-Printer to \\HOST fail with error 67 / RPC 1702 even when the share+printer work fine in the user's real interactive logon. Treat RMM SMB results as "can't tell," not "broken."
+type: feedback
+---
+
+When diagnosing remote file-share or network-printer reachability, do NOT trust results from
+GuruRMM `net use` / `net view` / `Add-Printer -ConnectionName \\HOST\...` — including in
+`context: user_session`. That context is a **WTS-impersonated, non-interactive token**, which
+cannot stand up an authenticated SMB session to a remote server. It returns **System error 67
+("network name cannot be found")** and **RPC 1702 ("binding handle invalid")** regardless of how
+healthy the path is — and even when you pass explicit valid credentials. It is not measuring what
+the logged-on user actually sees.
+
+**Why:** Mike, 2026-06-11 (Wolkin / RSW-Laptop printer). Julie reported "no printers." Over RMM I
+verified ZeroTier up, name resolution, TCP 445/139 open, MTU 2800 full DF packets, FRONT spooler
+running + `Sharp` shared + Private profile + SMB-In allowed, laptop adapter bindings present — yet
+every RMM `net use \\front\IPC$` (by name AND by IP, with valid `front\julie` creds) returned
+error 67, and I spent a long chain concluding it was a "stubborn SMB-over-ZeroTier wall needing a
+manual fix." Then Mike remoted in (real interactive session) and **the printer worked fine.** The
+error 67 was an artifact of the RMM impersonation context, not a fault. This also explained the
+2026-06-07 "wall" (same artifact; the earlier "manual fix" worked only because it was interactive).
+
+**How to apply:**
+- RMM is great for SYSTEM-scope facts (services, drivers, shares hosted locally, firewall, profiles,
+  IP/MTU/ping/TCP-port reachability). It is the WRONG instrument for "can the user reach
+  `\\REMOTEHOST\share` / a `\\HOST`-connected printer." For that, use the **real interactive
+  session** — ScreenConnect — or have the user confirm.
+- If RMM `net use`/`net view`/`Add-Printer` to a remote host returns 67/1702, read it as
+  **"cannot determine from this context,"** not "broken." Do not chase the plumbing — verify
+  interactively first.
+- A genuinely broken share/printer will also fail interactively; an artifact fails only via RMM.
+  So: reproduce in the real session before declaring a fault or burning cycles on root cause.
+- Related: [[feedback_rmm_password_limitation]] (RMM also can't set local passwords — another
+  impersonation/agent-context limitation; use ScreenConnect). Wolkin context: [[wolkin]].

clients/wolkin/session-logs/2026-06/2026-06-11-mike-printer-rediagnosis-and-slug-consolidation.md

@@ -70,3 +70,19 @@ Per Mike's "Do all", executed the full remediation: (1) restore-printer test wit
 - Canonical: `clients/wolkin/`, `wiki/clients/wolkin.md`. Vault: `clients/wolkin/`.
 - Syncro ticket #32369 (Remote Work Access Setup).
 - Memory: `feedback_client_slug_fragmentation.md`, `feedback_rmm_password_limitation.md`.
+
+## Update: 08:10 PT — DIAG MISMATCH RESOLVED (printer was working)
+
+Mike remoted into RSW-Laptop (real interactive session) and `\front\Sharp` **printed fine** —
+contradicting the entire RMM-based diagnosis. Root cause of the mismatch: **GuruRMM `user_session`
+is a WTS-impersonated, non-interactive token that cannot establish authenticated SMB to a remote
+host**, so `net use`/`net view`/`Add-Printer` to `\FRONT` return error 67 / RPC 1702 regardless of
+the (healthy) plumbing and even with valid creds. The RMM tests never reflected Julie's real
+session. This also reconciles 2026-06-07 (same artifact; the "manual fix" worked only because it
+was interactive — there is no SMB-over-ZeroTier wall).
+
+Corrections made: reframed the wiki Patterns entry from "[KNOWN WALL]" to "[MEASUREMENT ARTIFACT]";
+flipped Active Work printer item to WORKING; wrote memory `feedback_rmm_user_session_smb_false_negative.md`.
+The original "no printers" report was likely transient (pre-reboot / momentary ZeroTier hiccup).
+Net: nothing was actually broken; the real deliverables this session were the data-hygiene fixes
+(consolidation + vaulting) and capturing two reusable lessons. Still open: rotate `front\julie`.

wiki/clients/wolkin.md

@@ -88,7 +88,7 @@ backlinks: []
 ## Patterns & Known Issues
 - **macOS Syncro JSON parsing:** Syncro customer lookup from Mac failed due to JSON parsing issues (2026-06-07). Use Windows PC for Syncro API operations or manual web portal lookups.
 - **ZeroTier print RPC needs Private profile:** File-and-Printer-Sharing inbound rules (incl. Print Spooler RPC) apply to the Private profile only. The ZeroTier interface was Public on both FRONT and RSW-Laptop, which blocked print/RPC over ZT while file SMB still worked. Fix: set the ZT interface Private on both ends. (Confirmed still Private both ends 2026-06-11.)
-- **[KNOWN WALL] RSW-Laptop SMB to FRONT fails `net use`/`net view` with error 67 / RPC 1702 — scripted connection does NOT work; connect interactively.** First hit 2026-06-07, again 2026-06-11. Symptom: `net use \\FRONT\IPC$` (and by IP `\\10.147.19.199\IPC$`) → **System error 67 "network name cannot be found"**, `net view \\FRONT` → **1702 "binding handle invalid"** — even though everything underneath is healthy: ZeroTier up, name resolves, **TCP 445/139 open**, MTU 2800 carries full DF packets, FRONT spooler running + `Sharp` shared + profile Private + SMB-In allowed, laptop ZT adapter bindings (`ms_msclient`/`ms_server`) all present, and **error 67 persists even with valid `FRONT\julie` creds** (so it is NOT auth, NOT firewall, NOT MTU, NOT bindings, NOT profile). The scripted `Add-Printer -ConnectionName \\FRONT\Sharp` also throws error 67. **What works: a hands-on interactive connection via ScreenConnect as Julie** (how Mike cleared it 2026-06-07). Root cause of the redirector quirk over ZeroTier is still unidentified; do NOT burn hours re-deriving the plumbing — it is all verified clean. Diagnostic tip: `Get-NetAdapterBinding -Name "ZeroTier One [..]"` returns empty because the `[ ]` in the adapter name are treated as wildcards — query by `-InterfaceDescription "ZeroTier Virtual Port"` or pipe the adapter object.
+- **[MEASUREMENT ARTIFACT — not a real fault] SMB/printer tests via the GuruRMM agent give FALSE error 67 / RPC 1702; the real interactive session works.** The printer to `\\front\Sharp` **works** for Julie when she is logged in (confirmed 2026-06-11 by remoting in). But every SMB test run through the **GuruRMM agent's `user_session` context fails** — `net use \\FRONT\IPC$` (and by IP) → System error 67, `net view` → RPC 1702, `Add-Printer -ConnectionName` → 67 — **even with valid `FRONT\julie` creds.** Cause: RMM `user_session` is a **WTS-impersonated, non-interactive token**, which cannot establish an authenticated SMB session to a remote host (the network second-hop/credential context isn't there). It is NOT measuring what Julie's real logon sees. The underlying plumbing is genuinely fine (ZeroTier up, 445/139 open, MTU 2800 full DF, FRONT shared + Private + SMB-In, bindings present) — which is why it prints interactively. **Rule: do NOT use RMM `net use`/`net view`/`Add-Printer` to judge SMB/printer health to a remote host — its 67/1702 means "can't tell," not "broken." Verify via the real session (ScreenConnect).** The 2026-06-07 "wall" was this same artifact (Mike's "manual fix" worked only because it was interactive). See [[../../.claude/memory/feedback_rmm_user_session_smb_false_negative]]. Unrelated tip: `Get-NetAdapterBinding -Name "ZeroTier One [..]"` returns empty because `[ ]` are PowerShell wildcards — use `-InterfaceDescription "ZeroTier Virtual Port"`.
 - **Canonical data is local, not OneDrive:** the firm's repository is `C:\Shared Data\CLIENT FILES` on FRONT (local). OneDrive copies under `OneDrive\Documents` / `OneDrive\Shared Data` were stale predecessors from a defunct Resilio/ownCloud sync setup — consolidated and removed 2026-06-08. Win11 Home does not surface the Explorer "Previous Versions" tab; VSS restores are admin-side (mount the shadow volume).
 
 ## Active Work
@@ -99,7 +99,8 @@ backlinks: []
   - [x] Printer access via ZeroTier (Sharp `\\front\Sharp` over ZT; ZT set Private both ends; FRONT moved to TCP/IP 9100)
   - [x] ClientFiles share repointed to canonical `C:\Shared Data\CLIENT FILES` + data consolidated + VSS enabled (2026-06-08)
 - **Open follow-ups:**
-  - [ ] **RSW-Laptop printer broken again (2026-06-11):** Julie reports "no printers." `\\front\Sharp` is mapped but the SMB session to FRONT fails (error 67 — see Patterns). Plumbing verified clean; needs a **ScreenConnect/interactive reconnect** as Julie (scripted won't work). Consider rotating `front\julie` afterward (its password transited the RMM command log during diagnosis).
+  - [x] **RSW-Laptop printer — WORKING (2026-06-11).** Julie's "no printers" report did not reproduce in her real session; Mike remoted in and `\\front\Sharp` prints fine. The RMM-side error 67 was a measurement artifact (see Patterns), not a real fault. Original report was likely transient (pre-reboot / momentary ZT hiccup).
+  - [ ] **Rotate `front\julie`** — its password transited the RMM command log during diagnosis; rotate + re-vault `clients/wolkin/front-julie.sops.yaml`.
   - [x] **Migrate `front\julie` + M365 creds to vault** — DONE 2026-06-11 (`clients/wolkin/front-julie.sops.yaml`, `clients/wolkin/m365-users.sops.yaml`).
   - [x] **Consolidate the four Wolkin slugs** — DONE 2026-06-11 (canonical `wolkin`; wolkin-law/rswolkin/robert-wolkin stubbed).
   - [ ] Bob to file the 67 loose docs in `CLIENT FILES\Closed Files\_From OneDrive Documents`.