sync: auto-sync from Mikes-MacBook-Air.local at 2026-06-07 12:59:13

Author: Mike Swanson
Machine: Mikes-MacBook-Air.local
Timestamp: 2026-06-07 12:59:13

.claude/memory/MEMORY.md

@@ -48,6 +48,7 @@
 - [Vault git auth — GCM shadows store token](feedback_vault_gcm_shadow_auth.md) — vault sync "Failed to authenticate user" on git.azcomputerguru.com: GCM is first in the helper chain and shadows the valid store token. Fix (machine-local): store-only credential.helper reset + pin `azcomputerguru@` in the vault remote URL so store returns the durable PAT (not the volatile OAUTH_USER JWT). Applied GURU-5070 2026-06-07.
 - [Antigravity agy.exe is not a headless CLI](reference_antigravity_agy_not_headless.md) — the `agy` skill's real backend is `@google/gemini-cli`, not the Antigravity `agy.exe` (IDE agent, no stdout, hangs). Don't reinstall agy.exe expecting headless output. Mike has a paid Gemini account, so stay on gemini-cli past the June 18 free-tier sunset (prefer `GEMINI_API_KEY`).
 - [SQL instance role — verify by connections, not name](feedback_sql_instance_role_by_connection.md) — Standard installed under default `SQLEXPRESS` instance name is real. Prove role with `sys.dm_exec_sessions` + `Get-NetTCPConnection -OwningProcess` before recommending stop/uninstall.
+- [RMM password setting limitation](feedback_rmm_password_limitation.md) — `net user <user> <password>` via GuruRMM fails silently (exit 0 but password doesn't set). Tested PowerShell AND CMD - both fail. ScreenConnect CMD works (also as SYSTEM). GuruRMM agent bug in process spawning. Use ScreenConnect for password ops. HIGH priority to fix.
 - [Clear-RecycleBin fails silently as SYSTEM](feedback_clear_recyclebin_system_context.md) — RMM-dispatched cleanup scripts cannot use `Clear-RecycleBin -Force`; the cmdlet uses Shell COM and silently no-ops without an interactive desktop. Enumerate `C:\$Recycle.Bin\<SID>\*` directly.
 - [Graph CA policy reads are eventually consistent](feedback_graph_ca_policy_eventual_consistency.md) — After PATCHing a CA policy (204), wait ~5s before GET-verifying; immediate reads can be stale.
 - [Graph password reset needs a privileged role](feedback_graph_password_reset_requires_role.md) — PATCH passwordProfile on an existing user 403s without a directory role; User.ReadWrite.All alone only sets a password at CREATE.

.claude/memory/feedback_rmm_password_limitation.md

@@ -0,0 +1,72 @@
+# RMM Password Setting Limitation
+
+**Date:** 2026-06-07
+**Context:** Wolkin ZeroTier printer setup
+
+## Issue
+
+PowerShell commands to set local user passwords via GuruRMM (running as SYSTEM context) do not work properly, even though they return success codes.
+
+**Commands that FAIL when run as SYSTEM via RMM:**
+```powershell
+Set-LocalUser -Name "julie" -Password $securePassword
+net user julie Jaylen0607! /passwordreq:yes
+```
+
+Both commands complete with exit code 0 and show "The command completed successfully", but:
+- The password doesn't actually get set correctly
+- Authentication with the password fails
+- `net user julie` shows "Password required: No" (even after trying to set it to Yes)
+
+## Working Method
+
+Running the same `net user` command interactively as a local admin account (e.g., localadmin) DOES work correctly.
+
+## Root Cause
+
+**NOT a SYSTEM privilege issue** - ScreenConnect also runs as SYSTEM and password operations work there.
+
+**NOT a PowerShell vs CMD issue** - Tested both:
+- `command_type: "powershell"` - FAILED
+- `command_type: "shell"` (cmd.exe) - FAILED
+- ScreenConnect CMD - WORKED
+
+All three execute the identical command `net user localadmin r3tr0gradE99!`, all return exit code 0 and "The command completed successfully", but only ScreenConnect actually sets the password.
+
+**Confirmed GuruRMM agent bug** - Something about how the GuruRMM agent spawns the child process differs from ScreenConnect. Possible factors:
+- Process creation flags (CREATE_NO_WINDOW, DETACHED_PROCESS, etc.)
+- How stdin/stdout/stderr handles are created or inherited
+- Session/desktop isolation settings
+- Token or privilege differences in how the process is spawned
+- Windows API differences (CreateProcess vs CreateProcessAsUser vs other variants)
+
+**Investigation needed:** Compare GuruRMM agent's command execution code (server/src/agent/mod.rs or Windows agent spawn logic) with how ScreenConnect spawns processes.
+
+## Workaround
+
+For password operations on client machines:
+1. Use ScreenConnect or other interactive remote access
+2. Log in as a local admin (not SYSTEM)
+3. Use `net user <username> <password>` command
+4. Verify with `net user <username> | findstr "Password required"`
+
+## Related
+
+- GuruRMM commands run as SYSTEM by default
+- `context: "user_session"` runs as the logged-on user (if any), but still may not have admin rights
+- No `elevated: true` + `context: "admin"` option exists yet for "run as local admin" context
+
+## Future Enhancement
+
+Consider adding a RMM command context option to run as a specific local administrator account rather than SYSTEM, for operations that require local admin but not SYSTEM privileges.
+
+## Priority
+
+**HIGH** - This affects basic Windows administration tasks (user management, password resets). Current workaround (use ScreenConnect) is acceptable but GuruRMM should be capable of the same operations ScreenConnect can do.
+
+## Next Steps
+
+1. Review GuruRMM Windows agent code for how it spawns cmd.exe and powershell.exe processes
+2. Compare with ScreenConnect's known-working process creation method
+3. Test with different CreateProcess flags to identify which setting causes the password operation to fail
+4. Fix in GuruRMM agent and add test case to prevent regression