# Wolkin Law — Printer re-diagnosis (error 67) + client-slug consolidation

## User
- **User:** Mike Swanson (mike)
- **Machine:** GURU-5070
- **Role:** admin

## Session Summary

Julie reported "no printers" on RSW-Laptop. Via GuruRMM, confirmed Spooler + ZeroTier running, then established that the only real printer is `\\front\Sharp` (Point-and-Print off FRONT; physical Sharp MX-B557F at office LAN 192.168.1.158). Exhaustively verified the path: ZeroTier up, name resolves (front→10.147.19.199), TCP 445/139 open, **MTU 2800 carries full DF packets** (MTU ruled out), FRONT healthy (spooler running, `Sharp` shared, profile Private, SMB-In allowed), laptop ZT adapter bindings (`ms_msclient`/`ms_server`) all present, both ends' ZT profile Private. Yet `net use \\front\IPC$` (and by IP) fails with **System error 67** and `net view` with **RPC 1702** — and error 67 persists **even with valid `FRONT\julie` credentials**, ruling out auth/firewall/MTU/bindings/profile. Rebooted both machines mid-session (user request); did not change it.

Mike flagged this as a failure of the session-logs/wiki systems — we "spent two days" on this user/laptop. Investigation showed the work WAS captured but the client was **fragmented across four slugs** (`wolkin`, `wolkin-law`, `rswolkin`, `robert-wolkin`), so neither recall nor I found it, and I re-derived a diagnosis that the 2026-06-07 log already had. That log showed the **same error 67 / RPC 1702** and that Mike cleared it by connecting `\\front\Sharp` **manually/interactively** (scripted `Add-Printer` failed there too). It also flagged "migrate front\julie creds to vault" and "consolidate the slugs" as pending — never actioned.

Per Mike's "Do all", executed the full remediation: (1) restore-printer test with the recovered credential — confirmed error 67 is NOT auth, so the scripted path can't fix it (needs ScreenConnect/interactive, same as before); (2) vaulted `front\julie` + the M365 user passwords; (3) consolidated the four slugs into canonical `wolkin` (moved logs/baselines, merged + corrected the wiki, stubbed the duplicates), corrected a cross-client agent-id error, and wrote a memory so this fragmentation failure doesn't recur.

## Key Decisions

- Canonical slug = `wolkin`. Moved all `rswolkin`/`wolkin-law` logs+baselines into `clients/wolkin/`; left README pointer stubs; merged 3 wiki articles into `wiki/clients/wolkin.md` with `aliases:` for recall; stubbed `wolkin-law.md` + `robert-wolkin.md`.
- Did NOT keep chasing the error-67 SMB quirk scripted — it's a documented wall requiring an interactive fix; logged it loudly in the wiki Patterns instead of burning more cycles.
- Vault secrets only under `credentials:` via the new `vault` skill helper; infra facts stay in the wiki (plaintext, searchable).
- Recommend rotating `front\julie` since its password transited the RMM command log during the authenticated-mount test.

## Problems Encountered

- **Error 67 / RPC 1702 SMB wall (RSW-Laptop → FRONT over ZeroTier):** all underlying layers verified healthy; persists with valid creds. Same as 2026-06-07. Resolution: interactive/ScreenConnect connection (pending); root cause of the redirector quirk still unidentified.
- **Client-slug fragmentation:** one client under 4 slugs → 2-day build looked lost. Consolidated. Memory written (`feedback_client_slug_fragmentation.md`).
- **Cross-client data error:** retired `wolkin-law.md` listed FRONT's RMM agent id as `04765560-…` = actually Rednour's FrontDeskReception. Corrected (FRONT = `877d311a-…`).
- **Plaintext creds in wiki:** `wolkin-law.md` held robert/julie passwords in clear — moved to vault, scrubbed by stubbing the file.
- **`Get-NetAdapterBinding -Name "ZeroTier One [..]"` returns empty** — the `[ ]` in the adapter name are PowerShell wildcards; query by `-InterfaceDescription "ZeroTier Virtual Port"` or pipe the adapter object. (This made me twice misread the bindings as missing.)

## Configuration Changes

- **Vault (new):** `clients/wolkin/front-julie.sops.yaml` (front\julie local acct); `clients/wolkin/m365-users.sops.yaml` (robert@/julie@ rswolkin.com).
- **Repo moves:** `clients/rswolkin/*` and `clients/wolkin-law/session-logs/*` → `clients/wolkin/` (session-logs, onboarding-baselines, remote-printing-tailscale-plan.md). README stubs left in `clients/rswolkin/`, `clients/wolkin-law/`.
- **Wiki:** rewrote/enriched `wiki/clients/wolkin.md` (canonical — added GuruRMM agent IDs + Site ID, tenant, error-67 Patterns entry, vault pointers, consolidation banner, 2026-06-11 history). Stubbed `wiki/clients/wolkin-law.md` + `wiki/clients/robert-wolkin.md` → `[[wolkin]]`.
- **Memory:** `feedback_client_slug_fragmentation.md` + MEMORY.md index line.
- No repo code changes; RMM dispatches were read-only diagnostics + the two reboots.

## Credentials & Secrets

- `front\julie` (local on FRONT + RSW-Laptop) = `Jaylen0607!` → vault `clients/wolkin/front-julie.sops.yaml`. **Recommend rotation** (transited RMM command log during diagnosis).
- M365: robert@rswolkin.com = `Alissa16$!`; julie@rswolkin.com = `Jaylen0607!` → vault `clients/wolkin/m365-users.sops.yaml`.
- `front\Localadmin` exists on both machines (Mike's suggested admin) but its password was never recorded anywhere — still unknown/unvaulted.

## Infrastructure & Servers

- ZeroTier mesh `17d709436c834c9b` (10.147.19.0/24): front 10.147.19.199, RSW-Laptop 10.147.19.54. Laptop hosts entry `10.147.19.199 FRONT`.
- FRONT: LAN 192.168.1.153/24, ZeroTier 10.147.19.199. Sharp MX-B557F printer @ 192.168.1.158:9100, shared `\\front\Sharp`. RMM agent `877d311a-4b24-462c-97b1-d2a0f7730a71`. Local admins: Administrator, Localadmin, Owner.
- RSW-Laptop: ZeroTier 10.147.19.54, Wi-Fi 192.168.0.106. Logged-on user `rsw-laptop\julie`. RMM agent `043fd673-35a2-4d3d-8f91-ed73ce70cc1e`.
- DESKTOP-V1JT1SE (Bob's personal, out of scope): RMM `30f6af79-ab19-4ed3-9ebc-71b2bffc2d27`.
- M365 tenant rswolkin.com (`ceb6dbe7-82c8-4d8f-9c6b-49aa26208e9b` — from prior article, unverified). RMM client `Wolkin, Robert` / site `Main` / Site ID `2bb05f85-9fc8-4a7e-a5e5-ffe0c46431ac`.

## Commands & Outputs

- `net use \\10.147.19.199\IPC$ /user:FRONT\julie Jaylen0607!` → System error 67 (auth ruled out).
- DF ping sweep laptop→front: payload 2772 (pkt 2800) OK → MTU not the issue.
- `Get-NetAdapterBinding -InterfaceDescription "ZeroTier Virtual Port"` → ms_msclient/ms_server/ms_tcpip all True (bindings fine; `-Name` with brackets returns empty).
- Reboots: RSW-Laptop cmd `5505cdc8`, front cmd `53ac28e1` (both /r /t 15 /f).

## Pending / Incomplete Tasks

- **[CRITICAL] Restore Julie's printer** — reconnect `\\front\Sharp` interactively via ScreenConnect as Julie (scripted hits error 67). This is the actual unresolved issue.
- **Rotate `front\julie`** password (exposed in RMM command log); re-vault.
- Identify/vault `front\Localadmin` password (never recorded).
- Root-cause the error-67 SMB-over-ZeroTier redirector quirk (currently worked around manually each time).
- Verify the M365 tenant ID; capture Syncro customer ID + billing model (still `verify`).

## Reference Information

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