# Cascades of Tucson — Onboarding + Folder Redirection GPO Work

## Session

- **Date:** 2026-04-17 (work into early 2026-04-18 UTC)
- **User:** Howard Enos (howard)
- **Machine:** ACG-TECH03L (Howard's laptop) + ScreenConnect into DESKTOP-DLTAGOI (Sharon Edwards, Life Enrichment) + CS-SERVER (DC)
- **Client:** Cascades of Tucson (Syncro ID 20149445)
- **Ticket(s):** Syncro #132 (Life Enrichment GPO)

---

## What we shipped

### 1. Vault entries (encrypted, pushed to Gitea)

Added to `D:\vault\clients\cascades-tucson\`:

- `synology-cascadesds.sops.yaml` — DSM @ `http://192.168.0.120:5000/` — `admin / r3tr0gradE99#`
- `cs-server.sops.yaml` — CS-SERVER login — `sysadmin / r3tr0gradE99#` (IP TBD — update next on-site visit)
- `gururmm-site-main.sops.yaml` — GuruRMM site enrollment key for the CascadesTucson site. **Returned once by the API at site creation, will not be re-issued.** Used when installing the agent on Cascades endpoints.

### 2. GuruRMM client + site

| Object | Name | Code | GUID |
|---|---|---|---|
| Client | Cascades of Tucson | CASC | `42e1b0e3-f8b7-4fc5-86bd-06bdbb073b7f` |
| Site | CascadesTucson | GOLD-MOON-4620 | `c157c399-82d3-4581-979a-b9fad70f4fef` |

Created via `/api/clients` and `/api/sites` on `https://rmm-api.azcomputerguru.com`. Visible in the dashboard at https://rmm.azcomputerguru.com/clients.

**Note on site naming:** originally created as "Main," renamed to "CascadesTucson" in the dashboard. Vault file name is still `gururmm-site-main.sops.yaml` (filename not updated — content reflects new name).

### 3. Agents enrolled

Deployed via **ScreenConnect Commands** using a single PowerShell one-liner:

```powershell
$u='https://rmm-api.azcomputerguru.com/downloads/gururmm-agent-windows-amd64-latest.exe';
$d='C:\Windows\Temp\gururmm-agent.exe';
Invoke-WebRequest $u -UseBasicParsing -OutFile $d;
& $d install --server-url 'wss://rmm-api.azcomputerguru.com/ws' --api-key 'grmm_3gGYreG0u_QCvt5v3lDVKwLhZDAzF4On'
```

ScreenConnect Commands runs as SYSTEM, so the service install goes through without UAC. Installer drops binary to `C:\Program Files\GuruRMM\`, config to `C:\ProgramData\GuruRMM\agent.toml`, registers the Windows service, starts it. Heartbeat within ~60 seconds.

Agents now live under CascadesTucson site:

| Hostname | Role | Agent ID |
|---|---|---|
| DESKTOP-DLTAGOI | Life Enrichment workstation (Sharon Edwards) | `0ed72c1c-40c7-4bd4-afed-e0bcb198936f` |
| CS-SERVER | Domain controller / file server | `6766e973-e703-47c1-be56-76950290f87c` |

### 4. GPO edit — `CSC - Folder Redirection (LE)`

Target GPO: `{889BE7BE-202E-4153-89AD-B5DB62A52D25}` — linked at `OU=Life Enrichment,OU=Departments,DC=cascades,DC=local`.

Final state after the fix session:
- Documents redirected to `\\CS-SERVER\homes\%USERNAME%\Documents` — GrantExclusive=false, MoveContents=true
- Downloads redirected to `\\CS-SERVER\homes\%USERNAME%\Downloads` — GrantExclusive=false, MoveContents=true
- GPO version bumped from `3` to `8` through the iterations (`ModificationTime` ≈ 22:37 local)
- Backups of both our GPO + the peer reference GPO at `C:\GPO-Backups\pre-fix-20260417-221701\` on CS-SERVER (Broken-GPO Backup ID: `9c6ff7c9-0942-4cfb-b4a5-936913a3da87`)

---

## Root-cause analysis (keep this for other machines)

Sharon's folder redirection failed for **two stacked reasons**. Both need to be checked on every ProfWiz-migrated user across the domain.

### Cause 1: GPO GUI-bug — "Grant user exclusive rights" + pre-existing target

- The original `CSC - Folder Redirection (LE)` GPO had `GrantExclusiveRights=true` on Documents
- The target folder `D:\Homes\Sharon.Edwards\Documents` already existed with INHERITED ACLs (not created by the CSE)
- CSE refused to take over: it needs to own the target to grant exclusive rights — but didn't own it — so it **silently aborted the redirection write and logged no success or failure event**
- Symptom: Event ID 1006 on client showing "has to be redirected" but no following Event ID 101 (success) or 502/602 (failure)
- Fix: uncheck "Grant the user exclusive rights" in the GPO

**For other departments' GPOs:** always leave "Grant exclusive rights" UNCHECKED unless you're building from scratch with no pre-existing user folders. In an MSP / multi-admin environment it causes more problems than it solves. Share + NTFS ACLs already cover HIPAA access control.

### Cause 2: ProfWiz migration poisoned NTUSER.DAT

The user's `HKU\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders` values were pointing at `C:\Windows\system32\config\systemprofile\Documents` (and Music, Pictures, Video, Favorites, Downloads). That's the LOCAL SYSTEM account's profile — not a Windows default.

**This happens when:** ProfWiz's NTUSER.DAT SID re-signing overlaps in time with a SYSTEM-context process touching the hive (e.g., `gpupdate /force` run via `PsExec -s` as a "finalizing step" in some migration scripts). SYSTEM's default `User Shell Folders` values leak into the migrated hive before it's re-signed with the domain SID.

Why it matters for folder redirection:
- CSE reads the **current value** of the shell folder as the source for `MoveContents=true`
- If current value is `C:\Windows\system32\config\systemprofile\Documents`, CSE (running in the user's context) tries to read SYSTEM's folder — access denied, hangs for minutes before giving up
- During that time the user profile service waits on CSE and the logon stalls at "Welcome" with spinning dots
- Eventually CSE gives up, Explorer starts with the registry in a weird partial state, and the user sees "this file has no associated app" when clicking Documents or Downloads in the sidebar

**Detection:** check `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders` when the user is logged in. If `Personal`, `My Music`, `My Pictures`, `My Video`, `Favorites`, or the Downloads GUID `{374DE290-123F-4565-9164-39C4925E467B}` point to anything under `C:\Windows\system32\config\systemprofile\`, the hive is poisoned.

**Remediation (per user):** run the hive-cleanup script (see below) via ScreenConnect Backstage PowerShell while the user is logged off. Sets poisoned values back to `%USERPROFILE%\<Folder>` defaults (`REG_EXPAND_SZ`).

---

## GPMC behavior we ran into (document this before moving to other departments)

On Windows Server 2019/2022, GPMC's Folder Redirection snap-in has a bug where **modifying + adding entries in the same save session writes AD attributes correctly but leaves `fdeploy1.ini` in a half-written state**. Specifically:
- `Get-GPOReport` (reads AD) shows the correct `GrantExclusiveRights`, destination, etc.
- But client CSEs read SYSVOL's `fdeploy1.ini`, which was missing the "redirect enabled" bit for newly-added entries
- Runtime flags in the CSE event log (e.g., `Redirection options = 0x1231`) remained identical to pre-edit state even though the AD side said different

**Workaround sequence that works:**
1. In the GP editor, right-click each folder → Properties → Setting dropdown → "Not configured" → OK. Save.
2. File → Exit the GP editor. Wait ~30 seconds.
3. Reopen the GPO (Edit again).
4. Add Documents: Basic → Create a folder per user under root → root `\\CS-SERVER\homes` → uncheck "Grant user exclusive rights" → leave "Move contents" checked → OK.
5. File → Exit. Wait ~15 seconds. Edit again.
6. Add the next folder (Downloads, etc.) — same settings → OK.
7. File → Exit.

The close-and-reopen between folder adds is the trick. Don't add multiple folders in one editor session — that triggers the half-write bug.

After the edit, verify via RMM on the DC:
- `fdeploy1.ini` at `C:\Windows\SYSVOL\sysvol\cascades.local\Policies\{GUID}\User\Documents & Settings\fdeploy1.ini` has BOTH entries with `FullPath=\\...\%USERNAME%\<Folder>` and `Flags=` in a sane range (≠ 1000; working values we've seen: 4, 1001, 1021)
- `Get-GPO` shows bumped `User.DSVersion` and matching `User.SysvolVersion`

---

## Explorer sidebar disconnect (Known Folders vs legacy names)

Discovered that setting `User Shell Folders\Personal` alone **is not enough** on Windows 10/11. Explorer's sidebar (the tree on the left) uses the modern Known Folder API — `SHGetKnownFolderPath(FOLDERID_Documents)` — which resolves via the **GUID-form value** `{FDD39AD0-238F-46AF-ADB4-6C85480369C7}`, not the legacy `Personal`.

On Sharon, after the CSE ran:
- `Personal` = `\\CS-SERVER\homes\Sharon.Edwards\Documents` ✓ (set by CSE)
- `{FDD39AD0-238F-46AF-ADB4-6C85480369C7}` = `%USERPROFILE%\Documents` ✗ (still local)

Because these disagreed, clicking Documents in the sidebar tried to open the local path, which had MoveContents-side-effect attributes set on it, and produced the "no associated app" error.

**Fix that worked (applied via Backstage while she was logged in):** set the modern GUID values to match:

```
HKU\<SID>\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
  Personal                                  = \\CS-SERVER\homes\Sharon.Edwards\Documents  (REG_EXPAND_SZ)
  {FDD39AD0-238F-46AF-ADB4-6C85480369C7}    = \\CS-SERVER\homes\Sharon.Edwards\Documents  (REG_EXPAND_SZ)
  {374DE290-123F-4565-9164-39C4925E467B}    = \\CS-SERVER\homes\Sharon.Edwards\Downloads  (REG_EXPAND_SZ)
```

And the mirrored `Shell Folders` key with `REG_SZ` resolved paths. Then kill her Explorer process — it respawns with correct paths.

**For the GPO route (the long-term fix):** recent folder redirection CSEs *should* set both the legacy and GUID forms. On this environment, the legacy-only update is happening. If it's consistent across Cascades we may need to add a logon-script fallback that enforces GUID-form parity, or file the underlying Windows bug.

---

## Per-user hive cleanup script (save — we'll run this on every ProfWiz-migrated machine)

Runs as SYSTEM (ScreenConnect Backstage). User must be logged OFF so NTUSER.DAT is unloaded. Script backs up NTUSER.DAT, loads the hive, resets poisoned values to `%USERPROFILE%\<Folder>` defaults, unloads.

See `clients/cascades-tucson/scripts/hive-cleanup-shellfolders.ps1` in the repo.

---

## Operational findings / glitches

- **GuruRMM agent command executor wedge:** On DLTAGOI, a PowerShell diagnostic command that touched `Get-WinEvent` during a hung logon caused the agent's command executor to lock up. Subsequent commands stayed "pending" indefinitely, even after cancel + machine reboot. Heartbeat continued fine (separate thread). Other agents (CS-SERVER) processed commands normally. Workaround: ran cleanup scripts via ScreenConnect Backstage instead. File this against GuruRMM as "stuck command executor after user-context PS hang needs agent-service restart / doesn't recover on reboot."
- **GPMC `fdeploy1.ini` half-write bug** — see above.
- **Redirection target folders from earlier manual attempts:** there was a stray `_frtest.txt` and empty `Documents` directory under `D:\Homes\Sharon.Edwards\` from prior manual tests. These triggered the "grant exclusive rights" failure.

---

## Open items / tomorrow's work

1. **Desktop cleanup on DLTAGOI** — the working Desktop redirection is via a **manual reg hack** (`User Shell Folders\Desktop` set directly to UNC), not the GPO. Need to:
   - Add Desktop to the GPO with same settings as Documents/Downloads
   - Remove the Desktop reg hack (let the GPO drive it)
   - Verify Desktop sidebar works the same way (likely also needs the `{B4BFCC3A-DB2C-424C-B029-7FE99A87C641}` GUID form set)
2. **Additional folders** — add Pictures, Music, Videos, Favorites to the GPO once Desktop is proven stable
3. **Second Life Enrichment machine** — apply the same end-to-end tomorrow. If it works cleanly, then:
4. **Other departments** — build matching GPOs (Nursing, Admin, Maintenance, etc.) linked to each OU, same target root `\\CS-SERVER\homes` pattern, same "uncheck exclusive rights" discipline
5. **OneDrive conflict strategy** — some Cascades machines have Documents/Desktop already redirected into OneDrive. Need a plan:
   - Detect OneDrive-backed Known Folder Move (KFM) state (registry: `HKCU\Software\Microsoft\OneDrive\...\ScopeIdToMountPointPathCache` etc.)
   - Migrate content from OneDrive back to local `C:\Users\<user>\Documents` (via `robocopy` preserving timestamps + ACLs)
   - Unlink OneDrive KFM (Settings → Backup → Stop backup — or the equivalent registry / powershell automation)
   - THEN let the GPO redirect to `\\CS-SERVER\homes`
   - Decision needed: do we keep OneDrive installed (for real OneDrive usage) or uninstall? HIPAA BAA status of the Cascades M365 tenant will inform this.
6. **HIPAA hardening** (after folder redirection is stable):
   - `Set-SmbShare -Name homes -EncryptData $true` on CS-SERVER
   - Enable file-access auditing on `D:\Homes`
   - Confirm BitLocker status on CS-SERVER's D: drive

---

## Quick reference — Cascades infrastructure (current-known)

| Resource | Address | Credential path in vault |
|---|---|---|
| pfSense firewall | 192.168.0.1 | `clients/cascades-tucson/pfsense-firewall.sops.yaml` |
| Synology NAS `cascadesds` | 192.168.0.120:5000 | `clients/cascades-tucson/synology-cascadesds.sops.yaml` |
| CS-SERVER (DC + file server) | reachable at 192.168.2.254 from DLTAGOI on Wi-Fi-2; `cascades.local` domain | `clients/cascades-tucson/cs-server.sops.yaml` |
| DLTAGOI (Sharon Edwards test machine) | 10.0.20.72 on Wi-Fi-2 | n/a (domain-joined) |
| GuruRMM site enrollment key | — | `clients/cascades-tucson/gururmm-site-main.sops.yaml` |
| `svc-audit-upload` service account | — | `clients/cascades-tucson/svc-audit-upload.sops.yaml` |

Syncro customer record: **20149445** — primary contact Meredith Kuhn (meredith.kuhn@cascadestucson.com, 520-886-3171). Full contact list + other creds (Wi-Fi, KPAX, M365 admin, UniFi MACs, GoDaddy) in the Syncro notes field for customer 20149445.