---
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`. Empirically it returns **System error 67 ("network name cannot be found")**
and **RPC 1702 ("binding handle invalid")** for shares/printers that work fine in the user's real
interactive logon — even when you pass explicit valid credentials. Treat its SMB results as
**"can't tell," not "broken"**; verify in the real session (ScreenConnect).

**Root cause is NOT a naive impersonation/double-hop defect (corrected 2026-06-11).** The agent's
`run_command_in_session` (`agent/src/watchdog/wts.rs`) uses the textbook-correct pattern —
`WTSQueryUserToken` → `DuplicateTokenEx(TokenPrimary)` → `CreateProcessAsUserW` — and `whoami`
confirms commands genuinely run AS the user in their session. And error 67 persists even with
**explicit** `/user:.. <pw>` creds, which rules out a missing-network-credential/SSO gap. So the
mechanism runs as the user correctly; the SMB failure is a subtler, still-unresolved behavior of
the spawned-process context. Leading suspects: **UAC split token** (WTSQueryUserToken may return the
filtered token while printer/SMB state lives on the linked token — the `EnableLinkedConnections`
family of bug), or a missing **window station / `lpDesktop` / loaded user profile** changing
redirector/MUP behavior. Tracked as a GuruRMM engineering item (RMM_THOUGHTS). Until pinned, the
practical rule above stands.

**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]].
