# Session Log — 2026-05-29

## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech

---

## Session Summary

This session focused on preparing Lois Lane's domain account and setting up her new workstation (Health-Services-Director) for domain migration as part of the ongoing Cascades of Tucson department-by-department migration (Syncro #110680053).

First, the AD account for Lois Lane was verified via GuruRMM remote PowerShell on CS-SERVER. The account existed (SAM=Lois.Lane, UPN=Lois.Lane@cascadestucson.com, OU=Care-Assisted Living, enabled) but had no home folder and was not in SG-FolderRedirect. The home folder D:\Homes\Lois.Lane was created with all five subfolders (Desktop/Documents/Downloads/Music/Pictures) and correct CASCADES\Lois.Lane ACL. Lois.Lane was added to SG-FolderRedirect. The domain password was set to Imbirowicz1$ and vaulted at clients/cascades-tucson/lois-lane.sops.yaml.

Howard used Fab's Auto Backup to restore Lois Lane's profile from the old machine (DESKTOP-KQSL232) to Health-Services-Director, then ran ProfWiz to domain-join the machine and migrate her local account (Lois Lane) to CASCADES\Lois.Lane. Lois accidentally logged in before the prep-profile-for-redirection.ps1 script could be run, which caused the GPO folder redirection CSE to fire under SYSTEM context and poison the User Shell Folders registry values with C:\Windows\system32\config\systemprofile\* paths. Desktop was redirected correctly to \\CS-SERVER\homes\lois.lane\Desktop; all other folders were poisoned.

The hive cleanup script (hive-cleanup-shellfolders.ps1) was run against the offline NTUSER.DAT, fixing Personal/My Music/My Pictures/My Video/Favorites/{FDD39AD0}/\{374DE290\} back to %USERPROFILE%\ defaults. However, after Lois logged in, the folders remained local rather than redirecting to the server. An attempt to move data and fix registry via SYSTEM context failed because SYSTEM on Health-Services-Director does not have NTFS access to \\CS-SERVER\homes\Lois.Lane\* — the machine account is not in the ACL. This caused a stray C:\CS-SERVER\ folder to be created locally and the quick access links were broken. Howard manually removed the broken links and moved the data to the correct server locations.

Finally, the shell folder registry values were corrected using user_session context (running as Lois Lane) with UNC paths constructed via [char]92 to work around a confirmed encoding issue: double backslashes in PowerShell scripts dispatched via RMM user_session context are consistently halved to single backslashes when using string literals. The [char]92 workaround produced correct \\CS-SERVER paths. Explorer was restarted and the shell folders now point correctly to the server. Lois needs to re-pin the sidebar shortcuts manually (right-click folder → Pin to Quick Access) since the broken ones were removed.

---

## Key Decisions

- Used [char]92 to build UNC paths in RMM user_session scripts rather than string literals — confirmed that "\\CS-SERVER" literals are halved to "\CS-SERVER" in user_session context, producing local paths instead of UNC. System context does not exhibit this behavior.
- Ran hive cleanup (offline NTUSER.DAT) after accidental first login poisoned shell folder paths — this was the correct recovery path per the established Cascades folder redirection runbook.
- Data movement from local to server must run as the domain user (user_session context), not as SYSTEM — SYSTEM on a domain-joined workstation authenticates as the machine account to the network, which has no NTFS rights on user home folders.
- The new machine name Health-Services-Director reflects Lois Lane's actual role; the old blocked machine DESKTOP-KQSL232 is now superseded for her migration entry.
- Domain join credential: sysadmin / r3tr0gradE99# (same as local Localadmin account on the new machine).

---

## Problems Encountered

- **Accidental first login before prep script**: Lois logged in as domain user before prep-profile-for-redirection.ps1 could run. GPO CSE fired under SYSTEM, poisoned shell folder paths. Fixed via hive-cleanup-shellfolders.ps1 on offline NTUSER.DAT.
- **SYSTEM context cannot access UNC home folders**: Move-Item and Test-Path against \\CS-SERVER\homes\Lois.Lane\* silently routed to a local C:\CS-SERVER\ path when run as SYSTEM. Files appeared to move but went to a stray local folder. Root cause: machine account not in home folder NTFS ACL. Fixed by using user_session context for all file operations touching the Homes share.
- **UNC path encoding in user_session scripts**: `$base = "\\CS-SERVER\..."` produced `\CS-SERVER` (single backslash) in user_session context. Workaround: `$bs = [char]92; $base = "${bs}${bs}CS-SERVER\homes\Lois.Lane"`. Saved as feedback memory feedback-rmm-unc-path-encoding.md.
- **RMM server offline at session start**: GuruRMM server had been rebuilt (Mike deployed 0.3.36 at 18:51 UTC). Re-authenticated after server came back up.
- **jq escaping failure on inline SCRIPT variable**: Multi-line PowerShell scripts with backslashes failed when passed through jq --arg. Resolved by writing scripts to temp files and using jq -Rs to encode.

---

## Configuration Changes

- `clients/cascades-tucson/session-logs/2026-05-29-session.md` — created (this file)
- `.claude/memory/feedback-rmm-unc-path-encoding.md` — created (RMM user_session UNC path encoding rule)
- `.claude/memory/MEMORY.md` — updated (added new feedback memory entry)
- `C:\Users\Howard\.claude\plans\wise-discovering-panda.md` — updated CURRENT SAVE POINT, added Lois Lane completed entry, updated next actions to include Health-Services-Director domain join

---

## Credentials & Secrets

- **Lois Lane domain account**
  - SAMAccountName: Lois.Lane
  - UPN: Lois.Lane@cascadestucson.com
  - Domain password: Imbirowicz1$
  - Local account on Health-Services-Director: Lois Lane (no password)
  - Vault: clients/cascades-tucson/lois-lane.sops.yaml
- **Health-Services-Director local admin**: Localadmin / r3tr0gradE99#
- **Domain join credential**: sysadmin / r3tr0gradE99#

---

## Infrastructure & Servers

- CS-SERVER: Dell R610, Windows Server 2019, DC for cascades.local, GuruRMM agent c39f1de7-d5b6-45ae-b132-e06977ab1713
- Health-Services-Director: new workstation for Lois Lane, GuruRMM agent 3d6a6fed-500b-41d4-a785-6032e3d5297f, Windows 11, domain-joined cascades.local, OU=Staff PCs,OU=Workstations
- Homes share: \\CS-SERVER\homes → D:\Homes on CS-SERVER
- Lois Lane home folder: D:\Homes\Lois.Lane (Desktop/Documents/Downloads/Music/Pictures created, CASCADES\Lois.Lane FullControl)

---

## Commands & Outputs

**Verify AD account (CS-SERVER):**
```
Name: Lois Lane | SAM: Lois.Lane | UPN: Lois.Lane@cascadestucson.com
OU: CN=Lois Lane,OU=Care-Assisted Living,OU=Departments,DC=cascades,DC=local
Enabled: True | HomeDirectory: (none) | MemberOf: (none)
```

**New-HomeFolder result:**
```
D:\Homes\Lois.Lane created with clean ACL
  Created: Desktop, Documents, Downloads, Music, Pictures
```

**Hive cleanup result:**
```
[FIXED] Personal, My Music, My Pictures, My Video, Favorites, {374DE290} — all poisoned -> %USERPROFILE%\*
[KEEP]  Desktop = \\CS-SERVER\homes\lois.lane\Desktop (already correct)
```

**Shell folder fix (user_session, [char]92 workaround):**
```
Documents : \\CS-SERVER\homes\Lois.Lane\Documents
Music     : \\CS-SERVER\homes\Lois.Lane\Music
Pictures  : \\CS-SERVER\homes\Lois.Lane\Pictures
Downloads : \\CS-SERVER\homes\Lois.Lane\Downloads
Explorer restarted.
```

---

## Pending / Incomplete Tasks

- Lois Lane needs to re-pin Quick Access sidebar links (Documents, Music, Pictures, Downloads) — removed when broken, now point correctly to server
- Verify folder redirection is fully working after next login (gpresult /r on Health-Services-Director, or have Lois confirm folders open correctly)
- Check for stray C:\CS-SERVER\ folder on Health-Services-Director — should be cleaned up
- Migration plan next actions: Ashley Jensen verification, RECEPTIONIST-PC verification, NURSESTATION-PC auto-lock GPO, Phase 3 remaining joins (CHEF-PC, SALES4-PC, MDIRECTOR-PC)
- M365 relicensing: 31 users still on suspended Business Standard → Business Premium (31 SPB seats free, time-sensitive)
- Vault nurses credential: clients/cascades-tucson/nurses-shared.sops.yaml

---

## Reference Information

- Syncro ticket: #110680053 (department migration)
- Migration plan: C:\Users\Howard\.claude\plans\wise-discovering-panda.md
- GuruRMM server: http://172.16.3.30:3001 (rebuilt to v0.3.36 / commit 9b34393 at 18:51 UTC today)
- Lois Lane domain SID: S-1-5-21-388235164-2207693853-3666415804-1113
- prep-profile-for-redirection.ps1: clients/cascades-tucson/scripts/prep-profile-for-redirection.ps1
- hive-cleanup-shellfolders.ps1: clients/cascades-tucson/scripts/hive-cleanup-shellfolders.ps1
- fix-live-shellfolders.ps1: clients/cascades-tucson/scripts/fix-live-shellfolders.ps1

---

## Update: 12:42 PT — Health-Services-Director power settings

## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech

Configured power settings on Health-Services-Director (Lois Lane's new machine) via GuruRMM remote PowerShell.

### Configuration Changes

- Hibernate: disabled (`powercfg /hibernate off`)
- Sleep timeout: never (AC + DC, `standby-timeout = 0`)
- Screen timeout: 15 minutes (AC + DC, `monitor-timeout = 15`)

### Verification output

```
Hibernate : 0x00000000 (disabled)
Sleep AC  : 0x00000000 (never)
Screen AC : 0x00000384 (900 seconds = 15 min)
```

### Status

Machine fully configured. Lois Lane domain-joined, folder redirection live, power settings done. Remaining: she needs to log in to M365 (OU=Care-Assisted Living not yet in Entra Connect sync scope — cloud-only password still active), and re-pin Quick Access sidebar shortcuts.

---

## Update: 15:59 PT — Karen Rossini ALIS login issue

## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech

### Session Summary

Howard reported that Karen Rossini (Health Services Manager, OU=Care-Assisted Living) was not supposed to be in SG-Caregivers. Investigated via GuruRMM remote PowerShell on CS-SERVER.

First confirmed Karen was NOT in SG-Caregivers (38 members, she was absent — no action needed). Pulled her full AD group memberships and found she has zero group memberships of any kind. Cross-referenced against the migration plan and Entra setup notes:

- `OU=Care-Assisted Living` is outside the Entra Connect sync scope (only `OU=Caregivers` syncs) — Karen has no M365/Entra cloud presence
- She has no AD group assignments because Wave 2 (office staff reorganization) has not reached her account yet
- Per the migration plan she should eventually be in: `SG-Office-PHI-External`, `SG-SSPR-Eligible`, and `SG-External-Signin-Allowed`

The actual problem was separate: Karen could not log into ALIS because ALIS had 2FA enabled on her direct (non-SSO) ALIS account and she had no way to complete it. Howard called ALIS support and they disabled 2FA on her account, restoring her login. Howard does not have ALIS admin permissions to edit her staff record directly — John will need to assist with updating her email field to `karen.rossini@cascadestucson.com` and verifying her ALIS role.

A coord todo was created (id: cc7686a2) assigned to howard for the John-assisted ALIS account update.

### Key Decisions

- Karen's zero group memberships are expected at this stage — Wave 2 work has not reached her yet, not an error
- No changes made to AD groups — she was never in SG-Caregivers
- ALIS native 2FA disabled by ALIS support as a workaround; SSO is the long-term fix once Wave 2 expands sync scope to `OU=Care-Assisted Living`

### Commands & Outputs

**SG-Caregivers membership check (CS-SERVER, cmd: e44fb6b3):**
```
[INFO] karen.rossini was not found in SG-Caregivers - no action taken
SG-Caregivers now has 38 members
```

**Karen Rossini group memberships (CS-SERVER, cmd: df9e860e):**
```
Display Name: Karen Rossini
Title:        (blank)
Department:   (blank)
Enabled:      True
DN:           CN=Karen Rossini,OU=Care-Assisted Living,OU=Departments,DC=cascades,DC=local
Group Memberships: (none)
```

### Pending / Incomplete Tasks

- John to assist Howard with editing Karen Rossini's ALIS staff record: update email to `karen.rossini@cascadestucson.com`, verify role/permissions — coord todo cc7686a2
- Wave 2: add Karen to `SG-Office-PHI-External`, `SG-SSPR-Eligible`, `SG-External-Signin-Allowed` when her OU is brought into Entra Connect scope
- Long-term: `OU=Care-Assisted Living` needs to be added to Entra Connect sync scope as part of Wave 2

### Reference Information

- Coord todo: cc7686a2 (Karen Rossini ALIS account follow-up, assigned howard)
- RMM commands: e44fb6b3 (SG-Caregivers check), df9e860e (group memberships)
- CS-SERVER agent: c39f1de7-d5b6-45ae-b132-e06977ab1713

---

## Update: 16:32 PT — MCReception ET-5800 printer share

## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech

### Session Summary

Added the Memory Care Reception Epson ET-5800 (EPSON833571) as a mapped network printer on CS-SERVER. The printer had been listed in the Cascades printer inventory since the Phase 2 audit as entry #12 (MemCare Reception), offline and pending a UniFi switch replacement. The switch had since been replaced, and the printer came up online at 10.0.20.78 on VLAN 20 (staff network).

Looked up the existing ET-5800 setup (FrontDesk share at 192.168.2.147) to confirm the driver was already staged on CS-SERVER via the earlier EPWizard workaround. Because the EPSON ET-5800 Series driver was already registered with the spooler, no EPWizard re-run was needed — only a new TCP/IP port and printer share were required.

Dispatched a PowerShell script to CS-SERVER via GuruRMM (agent ID c39f1de7). The script created port TCP_10.0.20.78, installed the printer, and shared it as MCReception. Command completed exit 0. Connectivity check noted ICMP did not respond from 10.0.20.78, which is expected behavior on Epson devices with ping blocked; TCP printing will work when a job is sent with the printer awake.

Updated all relevant documentation: printers.md (entry #12 now online with IP/MAC/share), active-directory.md (MCReception added to printer table and GPO count bumped to 14), and phase2-print-server.ps1 (MCReception added for future re-run completeness). Committed under ba05fe5.

Howard will manually add \CS-SERVER\MCReception to Alma Montt's machine. Alma Montt is a cloud-only M365 account with no AD account, so GPO printer deployment will not push to her automatically. The share is ready for GPO targeting of OU=Care-Memorycare when the Printer Deployment GPO goes live at Phase 3.

### Key Decisions

- **Reused existing ET-5800 driver** — did not re-run EPWizard; the EPSON ET-5800 Series driver was already registered on CS-SERVER from the FrontDesk setup. Saved time and avoided the wlanapi.dll stub failure on Server 2019.
- **Share name MCReception** — followed existing MC-prefix convention (MCDirector, MCMedTech) for consistency in the print server share list.
- **GPO ILT scope: OU=Care-Memorycare** — matches MCDirector scope (memory care nurses/supervisors). Not extended to OU=Caregivers since the user specified memory care unit staff only, not all caregivers.
- **Alma Montt: manual connection** — she has no AD account (cloud-only M365), so GPO cannot push to her. Share is ready; Howard adds it manually to her machine rather than creating an AD account just for printer deployment.

### Problems Encountered

- **ICMP no response from 10.0.20.78** — printer did not respond to Test-Connection ping. Not a blocking issue; Epson devices commonly block ICMP. The TCP/IP print port will work when a print job is sent with the device awake.
- **RMM shell variable persistence** — initial RMM workflow broke because Bash tool calls do not share shell state between invocations. Resolved by consolidating auth + agent lookup + dispatch into single Bash calls.

### Configuration Changes

- `clients/cascades-tucson/docs/printers.md` — entry #12 updated: IP 10.0.20.78, MAC dc:cd:2f:83:35:71, share \CS-SERVER\MCReception, status Online 2026-05-29. Removed "MemCare Reception Epson ET-5800 needs hardwiring" from Known Issues.
- `clients/cascades-tucson/docs/servers/active-directory.md` — MCReception added to printer share table (OU=Care-Memorycare ILT); CSC - Printer Deployment GPO count updated from 13 to 14.
- `clients/cascades-tucson/docs/migration/scripts/phase2-print-server.ps1` — MCReception printer block added to `$printers` array and connectivity check array.

### Credentials & Secrets

None created or changed.

### Infrastructure & Servers

- **CS-SERVER** — Windows Server 2019, IP 192.168.2.254, GuruRMM agent ID c39f1de7-d5b6-45ae-b132-e06977ab1713
- **New printer** — Epson ET-5800, hostname EPSON833571, MAC dc:cd:2f:83:35:71, IP 10.0.20.78 (VLAN 20 / 10.0.20.0/24), share \CS-SERVER\MCReception

### Commands & Outputs

GuruRMM dispatch (cmd ID ca8ec985-74a9-466c-b85b-2ecbca842c5b), exit 0:
```
=== MCReception ET-5800 Setup ===
[OK] Driver present: EPSON ET-5800 Series
[OK] Port created: TCP_10.0.20.78
[OK] Installed and shared as \CS-SERVER\MCReception
[WARN] 10.0.20.78 not responding to ping (may still print via TCP)
ShareName: MCReception  PortName: TCP_10.0.20.78  DriverName: EPSON ET-5800 Series  Shared: True
```

### Pending / Incomplete Tasks

- Howard to manually add \CS-SERVER\MCReception to Alma Montt's machine
- When Phase 3 GPO goes live: update CSC - Printer Deployment Printers.xml to add MCReception with ILT OU=Care-Memorycare
- Confirm printer prints successfully once added to Alma's machine (ICMP block makes remote connectivity verification impossible)

### Reference Information

- Commit: ba05fe58d64db03a9d631f4ef189140f0c0f4a3d — feat(cascades): add MCReception ET-5800 print share on CS-SERVER
- GuruRMM command ID: ca8ec985-74a9-466c-b85b-2ecbca842c5b
- Printer share: \CS-SERVER\MCReception
- Printer IP: 10.0.20.78 | MAC: dc:cd:2f:83:35:71 | Hostname: EPSON833571
- Printer inventory doc: clients/cascades-tucson/docs/printers.md
- AD/GPO doc: clients/cascades-tucson/docs/servers/active-directory.md
- Print server script: clients/cascades-tucson/docs/migration/scripts/phase2-print-server.ps1

---

## Update: 20:23 PT — Printer troubleshooting, billing, docs

## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech

### Session Summary

Continued Cascades of Tucson work following the MCReception printer share setup. Troubleshot why Alma Montt could not print to \CS-SERVER\MCReception — print jobs queued and then failed with "can't print." Ran a diagnostic on CS-SERVER via GuruRMM that confirmed TCP port 9100 was not responding on 10.0.20.78, and the ARP table had no entries for the 10.0.20.x subnet. A follow-up routing test confirmed CS-SERVER's interface is a /22 covering 192.168.0.x–192.168.3.x only; all four legacy-subnet printers responded on TCP 9100, both VLAN 20 printers failed. Root cause: pfSense intentionally blocks legacy LAN → VLAN 20 as part of the migration design (one-way rule — VLAN 20 can reach legacy, not the reverse). CS-SERVER cannot reach any device on 10.0.20.x.

Clarified network architecture with Howard: the one-way firewall rule is deliberate. The plan is to migrate all users to VLAN 20 first, then move printers afterward. CS-SERVER moving to VLAN 20 early was discussed and ruled out — machines still on the legacy LAN would lose DC access since legacy → VLAN 20 is blocked, and the single-DC risk on a Dell R610 makes the move high-risk without a second DC. Discussed that the MCReception share on CS-SERVER will remain and will work once the printer is moved to the legacy subnet post-migration.

Howard manually added the printer directly to Alma Montt's machine (DESKTOP-F94M8UT) at 10.0.20.78 — her machine is on VLAN 20 and can reach the printer directly. Confirmed Alma is not a receptionist but Memory Care Life Enrichment staff, based in room 515. Her machine is not enrolled in GuruRMM. The direct IP connection resolved her printing.

Corrected documentation errors: the session log and AD notes had incorrectly described Alma as cloud-only M365 with no AD account — Howard confirmed she is a domain user. Billing was completed for all Cascades work done today under ticket #32303 (internal ID 110680053): 3.5h onsite covering Lois Lane domain migration (2h), Karen Rossini ALIS login (0.5h), and Memory Care Reception printer cable run + setup (1h). Invoice generated at $0.00 (prepaid block deduction). Prepay balance: 22.75 → 19.25 hrs. Winter to add ethernet cable materials as a separate line item.

### Key Decisions

- **CS-SERVER not moved to VLAN 20** — ruled out because legacy LAN machines still need DC access and the one-way pfSense rule would cut them off. Also single-DC risk on aging hardware. CS-SERVER moves only after all workstations are on VLAN 20 and a second DC is available.
- **Direct IP printing for Alma** — bypasses CS-SERVER entirely since her machine is on VLAN 20. CS-SERVER share preserved for post-migration GPO deployment when printer moves to legacy subnet.
- **Alma corrected to domain user** — previous session notes were wrong (cloud-only M365 / no AD account). She is a domain user. GPO will push MCReception to her automatically when Printer Deployment GPO goes live at Phase 3 — if her machine is enrolled and domain-joined by then.
- **All today's work billed under #32303** — single invoice for the full day's onsite work rather than splitting across tickets, at Howard's direction.
- **DESKTOP-F94M8UT not enrolled in GuruRMM** — noted for follow-up. Cannot manage remotely until enrolled.

### Problems Encountered

- **TCP 9100 not responding on 10.0.20.78** — initially suspected deep sleep (disabled per Howard). Diagnostic confirmed CS-SERVER has no ARP entries for 10.0.20.x at all — routing issue, not printer sleep. Resolved by identifying the intentional pfSense one-way VLAN rule.
- **Subnet ping sweep timed out** — first diagnostic attempt included a full /24 ping sweep which exceeded the RMM command timeout (exit -1). Resolved by running targeted TCP checks only.
- **RMM agent not found for DESKTOP-F94M8UT** — exact hostname match failed; partial search returned no match either. Machine is simply not enrolled. Howard added printer to Alma's machine manually.
- **Syncro ticket lookup by number returned empty** — `GET /tickets?number=110680053` returned no results because 110680053 is the internal ticket ID, not the number (number is 32303). Resolved by searching by customer_id instead.

### Configuration Changes

- `clients/cascades-tucson/docs/printers.md` — Alma Montt corrected to domain user; note that DESKTOP-F94M8UT has direct IP connection to 10.0.20.78 (not via CS-SERVER share)
- `clients/cascades-tucson/session-logs/2026-05-29-session.md` — this update appended

### Credentials & Secrets

None created or changed.

### Infrastructure & Servers

- **CS-SERVER** — IP 192.168.2.254, interface 192.168.0.0/22, default GW 192.168.0.1 (pfSense). Cannot reach 10.0.20.0/24 — pfSense blocks legacy LAN → VLAN 20.
- **EPSON833571 (MCReception ET-5800)** — 10.0.20.78, VLAN 20. Reachable from VLAN 20 machines. Not reachable from CS-SERVER.
- **DESKTOP-F94M8UT** — Alma Montt's machine (Memory Care Life Enrichment, room 515). On VLAN 20. Not enrolled in GuruRMM. Printer added directly at 10.0.20.78.

### Commands & Outputs

**CS-SERVER routing test (GuruRMM cmd 245281b2), key results:**
```
CS-SERVER interface: 192.168.0.0/22 (covers .0.x .1.x .2.x .3.x)
Default gateway: 192.168.0.1

FrontDesk ET-5800    192.168.2.147:9100  [OK]
HealthServices C368  192.168.1.138:9100  [OK]
MCDirector Canon     192.168.3.52:9100   [OK]
MCMedTech Brother    192.168.2.53:9100   [OK]
MCReception ET-5800  10.0.20.78:9100     [FAIL]
BOD Brother          10.0.20.220:9100    [FAIL]
ARP table: no entries for 10.0.20.x
```

**Syncro billing (ticket 110680053 / #32303):**
```
Comment:     id=414749104 (customer-visible)
Line item:   id=42649727 — Labor - Onsite Business, 3.5h @ $175.00
Invoice:     id=1650469577, total=$0.00 (prepaid)
Prepay:      22.75 → 19.25 hrs remaining
Status:      Invoiced
```

### Pending / Incomplete Tasks

- **DESKTOP-F94M8UT** — enroll in GuruRMM (Cascades site) so Alma's machine can be managed remotely
- **Winter** — add ethernet cable (15 ft) as materials line item to ticket #32303
- **BOD Brother (10.0.20.220)** — also unreachable from CS-SERVER via same VLAN 20 issue; \CS-SERVER\BusinessOffice share is broken until printer moves to legacy subnet or pfSense rule added
- **MCReception GPO** — Printers.xml update for OU=Care-Memorycare still pending (was mid-task when user redirected); GPO is unlinked so not urgent until Phase 3
- **Alma Montt AD details** — confirm her AD SAMAccountName and OU placement for GPO targeting when Phase 3 goes live
- **pfSense rule** — if any VLAN 20 printer needs to be reachable from CS-SERVER before full migration, add rule: 192.168.0.0/22 → 10.0.20.0/24 TCP 9100

### Reference Information

- Syncro ticket: #32303, internal ID 110680053 — Domain setup-entra sync (Cascades migration)
- Syncro invoice: id=1650469577
- Syncro comment: id=414749104
- Cascades customer ID: 20149445
- Prepay balance: 19.25 hrs as of 2026-05-29
- EPSON833571 (MCReception): 10.0.20.78, MAC dc:cd:2f:83:35:71, share \CS-SERVER\MCReception
- Alma Montt machine: DESKTOP-F94M8UT (not in RMM, direct IP printer at 10.0.20.78)
- CS-SERVER agent: c39f1de7-d5b6-45ae-b132-e06977ab1713
- BOD Brother also broken on VLAN 20: 10.0.20.220 (\CS-SERVER\BusinessOffice)
