claudetools/clients/cascades-tucson/docs/migration/phase4-synology.md

Step 6: Synology Transition (~2 hours, remote)

Pre-requisite before any of the 6.x steps below: a permission inventory of the live Synology must be captured and translated into AD group memberships, and CS-SERVER's NTFS + SMB permissions on the synced shares must match before users' drives get remapped. That work lives in §6.0.

---

6.0 — Permission inventory + CS-SERVER ACL application (pre-cutover)

Why: Synology Drive Client has been live-syncing \\cascadesds\* → D:\Shares\Main on CS-SERVER since 2026-03-07 (per phase2-server-prep.md §4c). Sync copies the files but not the permissions — CS-SERVER's shares inherit whatever the script in phase2-file-shares.ps1 applies, which currently assumes AD security group memberships that are correct for the target state. Those group memberships are empty or incomplete today.

Before users' mapped drives switch from Synology to CS-SERVER, the ACLs on CS-SERVER must replicate current Synology access rights. Do this in three steps.

6.0.1 — Discovery (non-destructive, no maintenance window needed)

SSH into admin@192.168.0.120 (credentials at clients/cascades-tucson/synology-cascadesds.sops.yaml). Run:

sudo synogroup --list
sudo synouser --list
sudo cat /etc/synoinfo.conf | grep -iE 'share|mode'
for share in homes Management SalesDept Server chat Public Culinary IT Receptionist directoryshare; do
    echo "=== $share ==="
    sudo synoacltool -get /volume1/$share
    sudo synoshare --get "$share" 2>/dev/null || true
done

Paste the output into a new file docs/migration/synology-permission-inventory.md with one section per share. Capture:

• Owner, group, mode (bitmask)
• Per-user ACL entries (read / write / delete / changeperm)
• Per-group ACL entries
• SMB-share-level permission overrides
• Inheritance flags

6.0.2 — Map Synology accounts to AD

Produce a translation table in the inventory doc:

Synology identity	AD identity	Notes
admin	Domain Admins	keep
meredith.kuhn (Synology local)	Meredith.Kuhn (AD)	same human
Synology group Management	AD SG-Management-RW	direct 1:1
Synology group Marketing	AD SG-Sales-RW	renamed
...	...	...

Any Synology account with no AD equivalent either (a) corresponds to a departed employee and gets dropped, or (b) is a new account we need to create in AD first (feeds back into the user rollout waves).

6.0.3 — Apply to CS-SERVER + HIPAA additions

Update scripts/phase2-file-shares.ps1 inputs to reflect the mapping, then run on CS-SERVER. After shares + NTFS are applied, add HIPAA-review-required settings per docs/security/hipaa-review-2026-04-22.md:

# Enable SMB3 encryption on every PHI-containing share (addresses 164.312(a)(2)(iv), (e)(2)(ii))
foreach ($share in 'homes','Management','SalesDept','Server','chat','Culinary','IT','Receptionist','directoryshare') {
    Set-SmbShare -Name $share -EncryptData $true -Force
}

# Enable Object Access auditing on the PHI file-share root (addresses 164.312(b))
auditpol /set /subcategory:"File System" /success:enable /failure:enable
# NTFS SACL — audit reads+writes on D:\Shares and subtree
$acl = Get-Acl D:\Shares
$auditRule = New-Object System.Security.AccessControl.FileSystemAuditRule(
    'Everyone','ReadData,WriteData,Delete,ChangePermissions','ContainerInherit,ObjectInherit','None','Success,Failure')
$acl.AddAuditRule($auditRule)
Set-Acl D:\Shares $acl

Verify with:

Get-SmbShare | Select-Object Name, EncryptData
Get-Acl D:\Shares -Audit | Format-List
auditpol /get /subcategory:"File System"

6.0.4 — Validation before any user is cut over

Pick one pilot user (Sharon Edwards on DESKTOP-DLTAGOI — already our folder-redirection pilot). Map her CS-SERVER drives manually, open representative files from each share she currently uses on Synology, verify open/save/delete works. Do not touch the GPO drive maps or run §6.1 below until the pilot validates cleanly.

Rollback at this stage: no user impact — just don't push the GPO change, and the Synology shares remain authoritative.

---

6.1 — Verify drive mappings

On each machine via ScreenConnect:

net use

Confirm mapped drives (S:, department drives) point to \\CS-SERVER\... and files are accessible.

Do not proceed until all users have working drive mappings.

---

6.2 — Remove Synology Drive Client

On each machine via ScreenConnect:

1. Right-click Synology Drive Client in system tray → Quit
2. Settings → Apps → Synology Drive Client → Uninstall
3. Verify user can access files via mapped drives (not Synology)

Or via PowerShell:

# Find and uninstall Synology Drive Client
$synology = Get-WmiObject Win32_Product | Where-Object { $_.Name -like "*Synology Drive*" }
if ($synology) {
    $synology.Uninstall()
    Write-Host "Synology Drive Client uninstalled"
} else {
    Write-Host "Synology Drive Client not found"
}

---

6.3 — Disable Synology Drive Server sync

1. Log into Synology DSM at https://192.168.0.120:5001
2. Open Synology Drive Admin Console
3. Disable all sync tasks
4. Optionally disable Synology Drive Server package (don't uninstall yet)

---

6.4 — Repurpose Synology as backup-only

1. Verify Active Backup for Business is backing up CS-SERVER nightly (set up in Step 1)
2. Configure offsite backup:
   • Install Hyper Backup from Package Center
   • Create task → Backblaze B2 or Wasabi (~$3/mo for offsite copy)
   • Schedule: daily after ABB completes (e.g., 5:00 AM)
   • Retention: 30 daily + 12 monthly

---

6.5 — Archive SynologyDrive folder

Run scripts/phase4-archive-synology.ps1 on CS-SERVER:

Rename-Item "D:\Shares\SynologyDrive" "D:\Shares\_SynologyDrive_ARCHIVE_DeleteAfter30Days"

Do NOT delete immediately — keep 30 days as safety net. Set a calendar reminder to delete after 30 days.

---

Rollback

• Rename archive folder back: Rename-Item "D:\Shares\_SynologyDrive_ARCHIVE_DeleteAfter30Days" "D:\Shares\SynologyDrive"
• Re-enable Synology Drive Server sync
• Reinstall Synology Drive Client on workstations