# 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: ```bash 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`: ```powershell # 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: ```powershell 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: ```powershell 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: ```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: ```powershell 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