azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from HOWARD-HOME at 2026-06-10 13:15:14

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-10 13:15:14
This commit is contained in:
Howard Enos
2026-06-10 13:15:24 -07:00
parent a0f62b4d40
commit bd5e977b6e
6 changed files with 200 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.claude/memory/MEMORY.md
View File

@@ -83,7 +83,7 @@
- [Dashboard beta-first deploy](feedback_dashboard_beta_first.md) — Dashboard auto-builds to rmm-beta.azcomputerguru.com on push; prod (rmm.azcomputerguru.com) is explicit promote-only via promote-dashboard.sh --confirm. Never hand-rsync prod. One artifact, nginx sub_filter BETA banner. Stood up 2026-06-02.
### Cascades
- [Cascades operational rules](feedback_cascades.md) — Two active rules: (1) folder redirection (fdeploy) needs subfolders PRE-CREATED before first logon or it caches a failure forever; recovery via fix-shell-redirect.ps1. (2) ALWAYS ask which security group(s) a new user goes into — never auto-derive from OU.
- [Cascades operational rules](feedback_cascades.md) — Active rules: (1) folder redirection (fdeploy) needs subfolders PRE-CREATED before first logon or it caches a failure forever; recovery via fix-shell-redirect.ps1. (2) ALWAYS ask which security group(s) a new user goes into — never auto-derive from OU. (3) Do NOT lock down the legacy Main\Company Web Docs\Accounting (Everyone:Full) folder — still in active use.
- [Cascades FR GPO fix](reference_cascades_fr_gpo_fix.md) — Native Folder Redirection was DOA on every machine: redirect targets were in a misnamed `fdeploy1.ini` (Windows reads `fdeploy.ini`) → empty target path → silent no-op → per-user registry workaround every time. Fixed 2026-06-08 (correct fdeploy.ini + version bump). Also: CS-SERVER live RMM agent is `c39f1de7...` (old `6766e973` stale).
## Machine

12
.claude/memory/cyndyoffice-physical-hp-lockups.md
View File

@@ -36,6 +36,18 @@ Startup fixes, next step = full hardware diagnostic (extended mem + drive/PSU)
plus backup + clean Windows reinstall; ~1-2 days machine downtime. PSU is the
prime remaining hardware suspect.
BILLED 2026-06-10: 1.0h onsite, $175, invoice #67810 (client emailed summary +
contingency). Universal Minerals is BREAK-FIX - no prepaid block, NOT an RMM/
monitoring client (prepay_hours 0.0). The GuruRMM agent was installed ONLY to
diagnose and was REMOVED same-day 2026-06-10 (agent's own `uninstall` via a
detached one-time scheduled task + sc delete of GuruRMMAgent/GuruRMMWatchdog +
deleted C:\Program Files\GuruRMM and C:\ProgramData\GuruRMM; server-side record
DELETE /api/agents/<id> -> 204). So freeze monitoring is now manual/customer-
reported, not via RMM. Client wiki seeded at wiki/clients/universal-minerals.md
([[universal-minerals]] slug). To remove a GuruRMM Windows agent generally: it
has built-in verbs (install/uninstall/start/stop/status) - run `uninstall`
DETACHED (scheduled task) so it survives killing its own service.
**Why:** future "look at CyndyOffice" requests will assume VM tuning; it's a
physical box needing a memtest/PSU/BIOS path.
**How to apply:** treat as physical hardware; resolve UUID live every time.

8
.claude/memory/feedback_cascades.md
View File

@@ -1,6 +1,6 @@
---
name: Cascades-specific operational rules (folder redirect, security groups)
description: Two active rules for Cascades work — (1) folder redirection (fdeploy) needs subfolders pre-created before first logon or it caches a failure forever; recovery via fix-shell-redirect.ps1; (2) always ASK which security group(s) a new user goes into — never auto-derive from OU. Root-cause / incident detail in project_cascades_history.md.
description: Active rules for Cascades work — (1) folder redirection (fdeploy) needs subfolders pre-created before first logon or it caches a failure forever; recovery via fix-shell-redirect.ps1; (2) always ASK which security group(s) a new user goes into — never auto-derive from OU; (3) do NOT lock down the legacy Main\Company Web Docs\Accounting (Everyone:Full) folder — still in active use. Root-cause / incident detail in project_cascades_history.md.
type: feedback
---
@@ -39,3 +39,9 @@ When creating or being asked to create any Cascades user account (AD or M365), a
OU placement is mechanical (controls Entra Connect sync scope); group membership is an access-control decision and must be made consciously.
**Caregivers example:** account goes in `OU=Caregivers` (sync scope) AND must be deliberately added to `SG-Caregivers` (CA policy coverage) — two separate, intentional steps; neither auto-derived from the other.
---
## 3. Do NOT lock down the legacy `Main\Company Web Docs\Accounting` folder
The accounting folder under the Synology-Drive-synced tree (`D:\Shares\Main\Company Web Docs\Accounting`, `Everyone:FullControl`) stays as-is — Howard confirmed 2026-06-10 the team is **still actively using it**. Do not scope/tighten its ACL or "clean it up" as a HIPAA hardening step, even though the wide-open Everyone:Full looks like an obvious target. The 2026-06-09 scan-to-folder build deliberately created a *separate* clean share (`\\CS-SERVER\AcctDept` → `D:\Shares\Accounting`) rather than reusing this folder; that is the lockdown story, and the legacy folder is intentionally left untouched.