---
name: feedback_cascades_folder_redirect
description: Cascades folder redirection — fdeploy failure/retry behavior, correct new-user procedure, recovery script location
metadata:
  type: feedback
---

Folder redirection (fdeploy) caches failures and never retries if subfolders don't exist at first logon. "No changes detected" = stuck forever without manual intervention.

**Root cause:** fdeploy1.ini had Flags=1211 which includes Grant Exclusive Rights (bit 0x400). The Homes share grants Domain Users=Change which excludes WRITE_DAC. fdeploy fails to set NTFS on new subfolders → logs 502 → caches the failure. Changed to Flags=187 in `{512B43A4-F049-4CE5-BFAC-860AD13E92BE}\User\Documents & Settings\fdeploy1.ini` on CS-SERVER.

**Prevention — mandatory order for every new user:**
1. Create AD user
2. Run `New-HomeFolder -Username "<sam>"` on CS-SERVER — now creates root + Desktop/Documents/Downloads/Music/Pictures subfolders with correct ACL
3. Add user to SG-FolderRedirect
4. THEN first domain logon

**Recovery (fdeploy already cached a failure):**
- Run `clients/cascades-tucson/scripts/fix-shell-redirect.ps1` via GuruRMM on the client while user is logged in
- Sets both GUID-based and legacy-name registry keys (Personal, My Music, My Pictures) in HKU\<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 matter:** Downloads has no legacy name key → only GUID needed. Documents/Music/Pictures have both `{GUID}` AND `Personal`/`My Music`/`My Pictures`. Windows reads the legacy key for the actual shell folder — GUID alone is insufficient.

**How to apply:** Any time a new Cascades user gets folder redirection set up.
