5.5 KiB
name, description, type
| name | description | type |
|---|---|---|
| Cascades-specific operational rules (folder redirect, security groups) | 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; (4) NEVER apply a change to Cascades production infra (pfSense, UniFi controller, switches, DHCP) without discussing it and getting an explicit per-change go — investigate read-only / dry-run only until then. Root-cause / incident detail in project_cascades_history.md. | feedback |
Current-state context: project_cascades. Root cause / incident detail: project_cascades_history.
1. Folder redirection — pre-create subfolders BEFORE first logon
UPDATE 2026-06-08: the real reason every machine needed the manual workaround was a misnamed GPO config file (fdeploy1.ini instead of fdeploy.ini) — native FR was DOA tenant-wide. Now fixed; native FR redirects all 5 folders on first logon. Full detail: reference_cascades_fr_gpo_fix. Still pre-create the home folder before first logon (below). The fix-shell-redirect.ps1 workaround should no longer be needed for new users — if it ever is again, check that the GPO still has a valid fdeploy.ini first.
fdeploy caches failures and never retries if subfolders don't exist at first logon. "No changes detected" = stuck forever without manual intervention.
Mandatory order for every new user:
- Create AD user.
- Run
New-HomeFolder -Username "<sam>"on CS-SERVER — creates root + Desktop / Documents / Downloads / Music / Pictures subfolders with correct ACL. - Add user to
SG-FolderRedirect. - THEN first domain logon.
Recovery (fdeploy already cached a failure):
- Run
clients/cascades-tucson/scripts/fix-shell-redirect.ps1via GuruRMM on the client while the user is logged in. - Script sets both GUID-based and legacy-name registry keys (
Personal,My Music,My Pictures) inHKU\<SID>. - Folders must already exist on server — script doesn't create them.
- User logs off and on to pick up changes.
Why both GUID and legacy keys: Downloads has no legacy-name key (GUID alone suffices); Documents / Music / Pictures have both, and Windows reads the legacy key for the actual shell folder — GUID alone is insufficient.
2. ASK which security group(s) a new user goes into — never auto-derive
When creating or being asked to create any Cascades user account (AD or M365), always ask the user which security group(s) the new account should be a member of. Include it explicitly in the creation preview/confirmation alongside name, UPN, and OU — do not assume from OU, department, or job title.
Why: Howard explicitly declined an OU=Caregivers → SG-Caregivers auto-mirror script (2026-05-14). Security-group membership controls access and CA-policy coverage; he wants that to stay a deliberate, reviewed decision per user, never automated.
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.
4. NEVER change Cascades production infra without discussing it first
Do not apply ANY change to the Cascades production network — pfSense (firewall rules, DHCP, ping-check, service restarts, reboots), the UniFi controller (radio power/channel/min-RSSI/disable, WLAN/PPSK settings), switches, or DHCP scopes — until it has been discussed and explicitly approved, per change. Investigate read-only / dry-run only (e.g. apply-radio without --apply, pfsense-ssh.sh audit/read-only run) and present proposals; wait for an explicit go before any write.
Why: Howard set this explicitly 2026-06-17 during the Poly-phone-drop investigation — it's a live HIPAA assisted-living network (~780 clients, residents' medical/IoT devices) where a bad change has real patient-care and compliance impact, and changes need coordination (another session was concurrently doing radio work; Mike should be looped in on pfSense changes).
How to apply: dry-run/read-only by default; stage changes as reviewable proposals; one explicit approval per change, not a blanket one. Pair with the per-change confirmation already required for hard-to-reverse/outward-facing actions. Coordinate via the coord API when another session may touch the same gear. Note the per-room /28 segmentation is intentional HIPAA L2 isolation — do not "clean it up." See project_cascades.