azcomputerguru/claudetools
1
0
Fork 0
Code Issues 59 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
295126ee6c4abe2588f94de0e022eabdbb1c925d
claudetools/clients/cascades-tucson/session-logs/2026-04-17-howard-cascades-onboarding-and-folder-redirection.md
Howard Enos 68153cf9b6 sync: auto-sync from ACG-TECH03L at 2026-04-17 23:51:18 
Author: Howard Enos
Machine: ACG-TECH03L
Timestamp: 2026-04-17 23:51:18
2026-04-17 23:51:20 -07:00

14 KiB
Raw Blame History

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:

$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.

Reference in New Issue View Git Blame Copy Permalink