claudetools/clients/cascades-tucson/session-logs/2026-06-05-session.md

Cascades of Tucson — Session Log 2026-06-05

User

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

Session Summary

Two Cascades tasks handled via the GuruRMM agent fleet and the M365 remediation tool suite.

First, a request to "enable the localadmin account as a local administrator" on NURSESTATION-PC because it was not appearing on the login screen. Recon via RMM showed the account was already enabled and already a member of the local Administrators group (it had even logged in earlier the same day). The actual cause was a SpecialAccounts\UserList registry suppression entry (localadmin = 0) under the Winlogon key, which deliberately hides the account from the sign-in screen. Removed that entry; account will now appear in the user picker after the next sign-out/reboot. The enable/admin steps in the fix script were idempotent no-ops since both conditions were already true.

Second, vault hygiene plus an MFA change on the MSP break-glass Global Admin sysadmin@cascadestucson.com. Confirmed the vault entry (clients/cascades-tucson/m365-sysadmin.sops.yaml) had not been updated since 2026-04-24 and that the live account's lastPasswordChangeDateTime was 2026-06-04 — i.e. Mike rotated the password on 2026-06-04 and never vaulted it. Howard supplied Mike's current password; updated the vault entry's password field and rotation-history notes in place via sops set (no plaintext on disk), committed, and pushed (required a rebase — remote had advanced).

Third, added a code-delivery path for Howard on the same GA account. Reading the account's phone methods showed mobile (SMS, Mike's) and alternateMobile (voice-only) slots both occupied, and the tenant Authentication Methods policy had Voice call disabled — which is why sign-in only ever offered text or authenticator (both Mike's). To avoid a tenant-wide change, created a security group containing only sysadmin@, enabled the Voice method scoped to that group, and set the account's alternateMobile to Howard's number. A voice-call MFA option now appears at sign-in for that account only. All writes against the GA succeeded (no Privileged Auth Admin 403 materialized).

Key Decisions

• Diagnosed the NURSESTATION-PC login-screen issue as a registry hide (SpecialAccounts\UserList) rather than an account-state problem, because recon proved the account was already enabled + admin. Fixed the actual cause instead of the stated symptom.
• Did NOT reset the live sysadmin@ password. Earlier in the session a reset to the vaulted value was prepared, but Howard clarified Mike's 2026-06-04 change was intentional; the correct action was to vault Mike's current password, not revert the account.
• Scoped the Voice MFA method to a dedicated single-member security group rather than enabling it for all_users, keeping blast radius to the one account (Howard asked specifically whether it could be limited to that account).
• Left alternateMobile set to Howard's number (520-585-1310) after Howard confirmed sign-in worked, rather than reverting to the prior 520-331-5551.
• Used sops set for the vault field edits (password + notes) to avoid ever writing the decrypted file to disk.

Problems Encountered

• RMM registry-recon command returned interrupted ("Agent restarted during execution") once on NURSESTATION-PC; re-ran and it completed.
• First fix-script dispatch returned an empty command_id (transient, around the agent restart). Re-dispatched and it succeeded.
• Group member-add returned 404 immediately after group creation (Entra replication lag); succeeded on retry after a short delay.
• Phone-method update first attempted with PUT (405 — "PUT is not supported in v1.0, use PATCH"); reissued as PATCH and it succeeded (204).
• Vault git push was rejected (remote ahead); resolved with git pull --rebase then push.
• bash readonly-variable error using UID for the user object id; renamed to OID.

Configuration Changes

• NURSESTATION-PC (Cascades, RMM agent): removed registry value localadmin (was 0) under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList. localadmin remains enabled and in Administrators (unchanged).
• Vault clients/cascades-tucson/m365-sysadmin.sops.yaml: updated credentials.password to Mike's current value; rewrote notes with a rotation-history block. Committed + pushed to the vault repo.
• M365 tenant cascadestucson.com:
  • Created security group "MFA - Voice Call Scoped (sysadmin)" (mfa-voicecall-scoped), id 304f941e-3594-4705-b8e6-ee676297df11, single member sysadmin@.
  • Authentication Methods policy: Voice method state set disabled → enabled, includeTargets scoped to group 304f941e-… (was all_users).
  • sysadmin@ alternateMobile phone method (b6332ec1-7057-4abe-9331-3d72feddfe41) changed from +1 520-331-5551 to +1 520-585-1310.

Credentials & Secrets

• sysadmin@cascadestucson.com (Global Admin "Computer Guru Support", object id 471b13dc-3cf8-416b-a132-f5f3bc8d1cc8): password rotated by Mike 2026-06-04, now vaulted at clients/cascades-tucson/m365-sysadmin.sops.yaml (credentials.password). Value not reproduced here; retrieve via vault.sh get-field.
• No new credentials created. Vault key auto-discovered by sops at %APPDATA%\sops\age\keys.txt.

Infrastructure & Servers

• GuruRMM API: http://172.16.3.30:3001. NURSESTATION-PC agent id f5a89784-834f-47b1-82e2-7e3e9dd337ff (Windows, online), client "Cascades of Tucson".
• M365 tenant cascadestucson.com = tenant id 207fa277-e9d8-4eb7-ada1-1064d2221498.
• Remediation app tiers used: user-manager (64fac46b-8b44-41ad-93ee-7da03927576c) for user/group/phone-method writes; tenant-admin (709e6eed-0711-4875-9c44-2d3518c47063) for the auth-methods policy PATCH.
• Account phone methods after change — mobile/SMS: +1 520-289-1912 (ready); alternateMobile/voice: +1 520-585-1310.

Commands & Outputs

• RMM hidden-account discovery: Get-Item HKLM:\...\Winlogon\SpecialAccounts\UserList → localadmin = 0 (the hide flag).
• RMM fix output: "Removed UserList hide entry for localadmin (was 0)" / "UserList hide entry now: ABSENT (will show on login screen)".
• Graph read of GA roles: GET /users/{id}/memberOf/microsoft.graph.directoryRole → "Global Administrator [62e90394-69f5-4237-9190-012177145e10]".
• Voice policy before: {state: disabled, includeTargets:[all_users]}; after PATCH: {state: enabled, includeTargets:[group 304f941e-…]}.
• Vault edit: sops set <file> '["credentials"]["password"]' '"<value>"' then verified round-trip and grep -c 'ENC[' = 4 (still encrypted).

Pending / Incomplete Tasks

• NURSESTATION-PC: localadmin will appear in the login picker only after the next sign-out/reboot. If a user is currently signed in, have them sign out to confirm.
• The previous alternateMobile number +1 520-331-5551 was overwritten — confirm with Mike that number did not need to remain on the account.
• Consider whether sysadmin@ (shared break-glass GA) should move to per-admin Authenticator/FIDO2 rather than shared SMS/voice long-term (raised but not actioned).
• Voice MFA is now an available method for the single-member scoped group; if more admins should get voice MFA, add them to group 304f941e-….

Reference Information

• Vault entry: clients/cascades-tucson/m365-sysadmin.sops.yaml.
• GA account object id: 471b13dc-3cf8-416b-a132-f5f3bc8d1cc8; alternateMobile method id b6332ec1-7057-4abe-9331-3d72feddfe41.
• Scoped Voice group: 304f941e-3594-4705-b8e6-ee676297df11 ("MFA - Voice Call Scoped (sysadmin)").
• Graph: /policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Voice.
• Remediation skill: .claude/skills/remediation-tool/; RMM skill: .claude/commands/rmm / /rmm.

---

Update: 11:16 MST — Caregiver restricted-access test setup (pilot.test + NURSESTATION + Intune)

Session Summary

Built the controlled test rig to validate the caregiver/medtech restricted-access design before promoting it to all caregivers, and began on-machine testing on NURSESTATION-PC. Goal: a test account with the exact caregiver rule set to prove "onsite + correct device = ALIS via SSO; offsite or wrong device = blocked" works on a desktop, then move real users in.

Created a user test group SG-Caregivers-DeviceTest and made it carry the FULL caregiver rule set (added it to the off-network block + sign-in-frequency policies, set the allow-list policy to enabled+scoped to it, and excluded it from the compliance block). Created cloud test account pilot.test@cascadestucson.com (Business Premium, in the test group); had to purge the old soft-deleted pilot.test from the recycle bin first to free the UPN. Created a STATIC device group Cascades - Caregiver Devices for Intune policy targeting (NURSESTATION only, added by hand, not dynamic — so it won't sweep in the laptops).

Howard un-joined NURSESTATION-PC from the domain and Entra-joined it (now Win11 25H2). Tagged its Entra device object CSCCaregiverDevice, added it to the device group, and deleted its stale 2020 Workplace device record. NURSESTATION is Entra-joined but NOT Intune-enrolled (MDM auto-enroll never fired; MDM user scope not set).

Test attempts: pilot.test authenticated fine but ALIS was blocked by Conditional Access (AADSTS53003) — the CSC - Caregivers: allow-listed devices only policy. Diagnosis: the device claim flowed correctly (deviceId e16c4af5, Azure AD joined, trusted IP 184.191.143.62) and the device IS tagged — so the block is device-tag propagation lag into CA's filter cache (15-60 min). Also resolved two first-sign-in prompts: Windows Hello (local registry workaround + Intune disable-Hello profile) and an "Authenticator" registration nudge (excluded the test group from the Authentication Methods registration campaign; confirmed risk-based MFA is inert because the tenant has no Identity Protection P2 license).

Key Decisions

• Test group SG-Caregivers-DeviceTest carries the full rule set (not just the allow-list) so a member gets the exact caregiver experience; pilot.test couldn't be added to the synced SG-Caregivers (Graph 400 on cloud member into on-prem-synced group), so the test group is the vehicle.
• Device group Cascades - Caregiver Devices is STATIC (manual membership) per Howard — add machines one at a time as verified, no auto-sweep.
• Intune enrollment is OPTIONAL for the core test (allow-list runs off the device tag; Hello/Authenticator handled locally). Enrollment only needed for managed polish (Shared PC Mode, managed lock).
• Scoped MDM auto-enroll to devices@ (group SG-Intune-Enrollment) rather than All, per the "only caregiver devices" requirement.

Problems Encountered

• Adding the cloud test account to SG-Caregivers failed (HTTP 400 — group is on-prem synced). Worked around by putting the full rule set on the cloud test group instead.
• Intune Shared PC Mode (windows10SharedPCConfiguration) POST rejected twice (BadRequest "Invalid OData type") via Graph — deferred to the Intune portal (Shared multi-user device template).
• WHfB-disable as a deviceEnrollmentConfiguration returned 403 (intune-manager app lacks enrollment-config write) — used a device-scoped OMA-URI (PassportForWork/.../UsePassportForWork=false) instead, which succeeded.
• ALIS blocked (53003) on test sign-ins -> device-tag propagation lag into CA (not MFA, not managed-state). Deleted stale 2020 NURSESTATION Workplace record to remove device-resolution ambiguity.
• "Set up Authenticator" nag -> registration campaign excluded SG-Caregivers but not the test group; excluded the test group. Risk-based MFA confirmed non-functional (no P2 license).
• UID is a read-only bash variable (caused an earlier 404); use a different var name for GUIDs.

Configuration Changes (Entra/Intune — live, no repo files)

• New group SG-Caregivers-DeviceTest (db5849ec-242d-4b05-9d1b-940a830e7a60, users) — added to off-network block (e35614e1) + sign-in-freq (7d491c7a) include; allow-list (1b7fd025) enabled + scoped to it (renamed "...(TEST GROUP)"); excluded from compliance-block (ede985e2).
• New group Cascades - Caregiver Devices (02c6f698-f9f5-452f-8996-4ea43d976d0a, static devices) — member: NURSESTATION-PC.
• New group SG-Intune-Enrollment (13d94f6e-a255-4e4d-b275-5c73f2bc421c, users) — member: devices@ (scoped MDM auto-enroll).
• New user pilot.test@cascadestucson.com (d26e0e5a-2f99-4ea9-8d4e-40dc02016d05), Business Premium, usageLocation US, in SG-Caregivers-DeviceTest. (Old soft-deleted pilot.test purged from recycle bin.)
• NURSESTATION-PC Entra device (dd941398-7202-4280-8614-87e40b9a0442, deviceId e16c4af5-cb0e-49e1-90be-674a216f5e9c) tagged extensionAttribute1=CSCCaregiverDevice; stale 2020 Workplace record (cb70bcab-efb8-4a60-859b-f35ab041f808) deleted.
• Intune device configs (assigned to Cascades - Caregiver Devices): CSC - Caregiver Idle Lock 5min (id 7ef2d5da-6b50-477c-accd-7dda3a34ba25, OMA-URI MaxInactivityTimeDeviceLock=5); CSC - Caregiver Devices - Disable Windows Hello (OMA-URI PassportForWork UsePassportForWork=false). Shared PC Mode NOT created (portal pending).
• Registration campaign (/policies/authenticationMethodsPolicy) excludeTargets += db5849ec (test group), alongside existing 8b8d9222 (SG-Caregivers).
• NURSESTATION local registry (on-device, by Howard): HKLM\SOFTWARE\Policies\Microsoft\PassportForWork\Enabled=0 to disable WHfB until Intune-managed.

Credentials

• pilot.test@cascadestucson.com / CareTest2026! — TEST account, DELETE after testing. No force-change. Not vaulted (ephemeral).

Pending / Incomplete Tasks

• Retry ALIS as pilot.test once device tag propagates (53003 should clear) — proves the core desktop test.
• Howard: set ALIS staff Email = pilot.test@cascadestucson.com so ALIS resolves it after CA passes.
• Portal: MDM user scope = Some -> SG-Intune-Enrollment; reboot NURSESTATION to auto-enroll into Intune.
• After enrollment: Intune profiles (disable-Hello, idle-lock) apply automatically; build Shared PC Mode in portal (assign to Cascades - Caregiver Devices); drop the local WHfB reg workaround.
• After validation: promote rule set to SG-Caregivers (all 38 + Feller/Nyanzunda) — point allow-list at SG-Caregivers, disable compliance-block, then clean up test artifacts (pilot.test, test group).
• Optional: hard-block Windows desktop logon offsite (disable cached logon) — not needed since caregiver devices stay onsite.

Reference

• Allow-list policy 1b7fd025-1aad-47c8-9274-c32c3e0b163c; off-network block e35614e1-...; compliance-block ede985e2-...; sign-in-freq 7d491c7a-....
• ALIS app d5108493-cba8-4f08-90b6-1bb0bc09eb2a; admin-consent grant reTK4etbykSC1ENMm9g1rTplOyzgVClCofKDVRrn-ds.
• devices@ aaca80c6-861b-4294-8068-1033c68d7667. Threat model confirmed with Howard: remote credential abuse (hacker / bad employee from home) — fully blocked by the off-network + device allow-list CA (stolen caregiver creds unusable off-site/off-device).

---

Update: 12:17 MST — Core test PROVEN; enrollment blocked on Intune license provisioning

Result

The caregiver restricted-access model is proven end-to-end on a desktop. pilot.test signed into NURSESTATION-PC, and ALIS opened via Microsoft SSO, with the lockdown holding (off-network blocked, only allow-listed device passes). That was the goal.

How ALIS finally passed

First attempts threw CA AADSTS53003 (allow-list block) even though NURSESTATION was tagged CSCCaregiverDevice, on a trusted IP (184.191.143.62), with the device claim flowing correctly (deviceId e16c4af5, Azure AD joined, valid PRT). Root cause: device extensionAttribute changes take a long time (>70 min here) to propagate into CA's device-filter cache. Fix: added NURSESTATION's intrinsic deviceId directly to the allow-list rule (policy changes propagate in minutes; deviceId isn't subject to the attribute cache) — ALIS then worked immediately. Takeaway: for the small caregiver device set, matching by deviceId in the allow-list is the reliable, lag-free lever; the extensionAttribute1 tag is fine but slow to take effect.

Open blocker: Intune enrollment (license provisioning)

NURSESTATION is Entra-joined but won't Intune-enroll. Walked it down with dsregcmd /status: device healthy, AzureAdPrt YES, but MdmUrl blank. Confirmed MDM user scope = Some -> SG-Intune-Enrollment (correct) and devices@ is a member (correct). Actual root cause: the Intune service plan on the enrolling account is not provisioned — INTUNE_A: PendingInput on both newly-licensed accounts (devices@ AND pilot.test), while established users (Megan) are fine. A device cannot enroll through an account whose Intune plan isn't active. Re-kicked the Business Premium license on devices@ (remove + re-add; first re-add 409'd and was retried to 200 — confirmed SPB back on the account). INTUNE_A still PendingInput immediately after — provisioning takes time. Re-check in 20-30 min.

Windows Hello prompt (still showing)

The "set up Windows Hello" prompt persisted on pilot.test despite the local reg key (PassportForWork\Enabled=0) and reboots — I was wrong that a reboot would fix it. Fact: tenant WHfB enrollment policy = notConfigured, so Windows applies its default (WHfB ON) on Entra-joined devices, and the generic reg key doesn't reliably override it. The clean, scoped fix is the Intune disable-Hello profile (already built, assigned to Cascades - Caregiver Devices) — which applies once the device is Intune-enrolled. The prompt is dismissible, so it didn't block the test. Tenant WHfB left untouched so office users keep PIN + Authenticator (their offsite 2FA preserved).

Config changes (live)

• Allow-list policy 1b7fd025 rule now: (device.displayName -startsWith "CSC-") -or (device.extensionAttribute1 -eq "CSCCaregiverDevice") -or (device.deviceId -eq "e16c4af5-cb0e-49e1-90be-674a216f5e9c") (mode exclude).
• devices@ Business Premium license removed + re-added (kick Intune provisioning). SPB confirmed re-present.

Pending (updated)

• Re-check devices@ INTUNE_A -> Success (re-check ~20-30 min after 12:17 MST). Once Success: reboot NURSESTATION -> auto-enrolls -> disable-Hello + idle-lock apply.
• If still PendingInput after a while: tenant new-license Intune activation issue (both new accounts affected) — may need more time / MS support; does NOT block the working caregiver access.
• After enrollment: drop the local WHfB reg hack; build Shared PC Mode in portal (assign to Cascades - Caregiver Devices).
• Howard: confirm pilot.test ALIS staff Email = pilot.test@cascadestucson.com (ALIS resolved it this session, so likely set).
• Promote rule set to SG-Caregivers (all 38 + Feller/Nyanzunda); for devices, prefer deviceId matching in the allow-list (reliable) — collect the 6 caregiver-device deviceIds. Then disable compliance-block + clean up test artifacts (pilot.test, test group).
• LESSON: check Intune license provisioning (INTUNE_A = Success) before troubleshooting enrollment; CA device-filter extensionAttribute changes lag (use deviceId for immediacy).

Update: 14:05 MST — Decision: pivot to hybrid/domain-join (GPO) for device policies; wiki architecture overview added

Because per-user Intune (INTUNE_A) is stuck PendingInput tenant-wide (MS case open), decided to deliver the caregiver device settings via Group Policy instead of Intune — i.e., Hybrid Entra Join / domain join the caregiver machines and push Hello-off + idle-lock + profile handling via GPO (which is already set up on CS-SERVER). The caregiver access model (CA off-network + device allow-list + ALIS SSO) is unchanged and works regardless of join type — it only needs the device to have an Entra object (hybrid join provides it; deviceId/extensionAttribute allow-list still applies).

Added a canonical Entra Access Architecture overview to wiki/clients/cascades-tucson.md (two-bucket design, CA policies, devices, ALIS SSO, Intune blocker + hybrid pivot).

Key caveat for the hybrid path

Entra Connect syncs USERS (PHS + Seamless SSO) — that's set up. Hybrid Azure AD device Join is a SEPARATE Entra Connect config (Device options / SCP) and is likely NOT enabled (NURSESTATION's old record was Workplace, not ServerAd). So step 1 of the hybrid path = enable Hybrid Entra Join in Entra Connect on CS-SERVER. NURSESTATION is currently Entra-joined (un-joined from domain earlier today), so going hybrid means re-domain-joining it (new Entra device object -> re-tag for allow-list).

Next phase (in progress — "next few hours")

• Enable Hybrid Entra Join in Entra Connect (CS-SERVER) — verify it's on; if not, configure Device options/SCP.
• Domain-join the caregiver machines (laptops + NURSESTATION + ASSISTNURSE-PC) -> they hybrid-register into Entra.
• Re-tag the new hybrid device objects (extensionAttribute1=CSCCaregiverDevice and/or add deviceIds to the allow-list rule).
• GPO for caregiver devices: disable Windows Hello (Use Windows Hello for Business=Disabled), idle screen-lock (machine inactivity limit), security baseline; folder handling so no local data.
• Users sign in with email/UPN (works on domain/hybrid devices since UPN suffix = cascadestucson.com). Each caregiver uses their OWN account (shared device, individual logins) — required for ALIS SSO email-match + audit.
• Resume per-user testing via SG-Caregivers-DeviceTest, then promote to SG-Caregivers.

Update: 16:14 MST — Hybrid join COMPLETE + ALIS SSO validated end-to-end; caregiver GPO build in progress

MILESTONE: NURSESTATION hybrid-joined, pilot.test ALIS SSO works on a desktop

The whole hybrid pivot is proven on one machine:

• Added OU=Caregiver Devices,OU=Staff PCs,OU=Workstations to the Entra Connect sync scope (Optional features left as-is: PHS + Password writeback on; Group writeback + Device writeback OFF — neither is needed for Hybrid Join). Ran Start-ADSyncSyncCycle (a full sync was already auto-running from the wizard "Configure"); all connector runs success.
• NURSESTATION computer object synced to Entra as trustType: ServerAd (= Hybrid Entra Join). New deviceId d3bf931f-f128-4261-8398-b46c34a4b342 (object id de199a15-3f5d-4da3-8b17-3faade7f7dad).
• On reboot, client-side join completed: dsregcmd /status → AzureAdJoined: YES, DomainJoined: YES (CASCADES), DeviceAuthStatus SUCCESS, TpmProtected YES.
• As pilot.test (non-elevated dsregcmd): AzureAdPrt: YES → PRT issued, silent SSO chain complete. ALIS opened via silent SSO — no second credential prompt. Full caregiver desktop experience validated.
• Ngc Prerequisite Check = PolicyEnabled: NO → WillNotProvision = Windows Hello will NOT auto-provision on hybrid-joined machines (PIN/Hello popup does not appear). This is the behavior we want for shared caregiver devices — no separate Hello-disable step needed on the hybrid path.

Allow-list CA rule updated to the NEW deviceId (the old one was stale)

Removing Entra + re-domain-joining created a brand-new device object. Old Entra-joined deviceId e16c4af5-cb0e-49e1-90be-674a216f5e9c no longer exists in Entra (confirmed empty lookup).

• Policy CSC - Caregivers: allow-listed devices only (TEST GROUP) (1b7fd025-1aad-47c8-9274-c32c3e0b163c, deviceFilter mode=exclude = allow-list) rule now: (device.displayName -startsWith "CSC-") -or (device.extensionAttribute1 -eq "CSCCaregiverDevice") -or (device.deviceId -eq "d3bf931f-f128-4261-8398-b46c34a4b342")
• Also tagged the device extensionAttribute1 = CSCCaregiverDevice (durable; survives future deviceId changes). NURSESTATION now allow-listed by deviceId (lag-free) AND tag.
• Reminder (Graph): PATCH returns 204 then read-back lags a few seconds (replication) — re-read to confirm.

Reception-policy false alarm (resolved, no change made)

CSC - Reception Workstation Policy showed as "inherited" by OU=Caregiver Devices (it's linked at parent OU=Staff PCs), but its security filtering is GpoApply: SG-Reception-PCs only, and that group contains only RECEPTIONIST-PC. So it never applies to NURSESTATION. Nothing unlinked. (Get-GPInheritance lists in-scope links before security filtering.)

NEW WORK: proper GPO for all caregivers/medtechs (shortcuts + printers) — IN PROGRESS

Decision (per Howard): do NOT place shortcuts/printers manually — build a real, scalable GPO driven by the SG/OU structure ("how a medical company should work"), and mirror it in a test scope (pilot.test only) so the 38 real caregivers are untouched until validated.

Discovery:

• CS-SERVER is the print server (15 shared queues \\CS-SERVER\<share>).
• SG-Caregivers = real on-prem Global Security group, 38 members, OU=Groups — same group synced to Entra for the CA policies (one group drives GPO + CA).
• All 38 caregivers live in OU=Caregivers,OU=Departments (42 users total there; others: c.lassey, p.sandoval-beck [likely medtechs to add], n.castro [TERMINATED], pilot.test).
• pilot.test DN = CN=Pilot Test,OU=Caregivers,OU=Departments (correct OU), no on-prem groups.
• Existing printer GPOs: CSC - Life Enrichment Printers (WORKING, linked to OU=Life Enrichment) and CSC - Printer Deployment which is BROKEN — it has a full User Printers.xml (all departments, ILT by OU/group) but gPCUserExtensionNames is EMPTY and versionNumber=0, so the CSE is unregistered and it never applies even if linked. (It also has a bug: the NursesPrinter entry path is \CS-SERVER\NursesPrinter — single backslash. Worth fixing/retiring this GPO separately.)

Proven GPP schema cloned from this domain (for the new GPO):

• Working gPCUserExtensionNames for Printers = [{00000000-0000-0000-0000-000000000000}{A8C42CEA-CDB8-4388-97F4-5831F933DA84}][{BC75B1ED-5833-4858-9BB8-CBF0B166DF9D}{A8C42CEA-CDB8-4388-97F4-5831F933DA84}] (tool-ext GUID this domain uses = {A8C42CEA-CDB8-4388-97F4-5831F933DA84}).
• To ADD Shortcuts CSE, append [{C418DD9D-0D14-4efb-8FBF-CFE535C8FAC7}{A8C42CEA-CDB8-4388-97F4-5831F933DA84}] (CSE GUIDs stay sorted: 00000000 < BC75 < C418). Must also bump versionNumber.
• Printers.xml: <Printers clsid="{1F577D12-...}"> → <SharedPrinter clsid="{9A5E9697-9095-436d-A0EE-4D128FDFBCE5}" name="\\CS-SERVER\<share>" ...><Properties action="U|C" path="\\CS-SERVER\<share>" default="0|1" skipLocal="1" ...><Filters>...</Filters></Properties></SharedPrinter>. Filters go INSIDE <Properties>. FilterGroup ... userContext="1" = check USER's group; userContext="0" = check COMPUTER's group (this is how device-location default targeting works).

GROUPS CREATED this session (in OU=Groups):

• SG-Caregivers-Test — GPO security-filter for the pilot. Member: pilot.test only. (Go-live = swap filter to SG-Caregivers.)
• SG-PC-MainTower — caregiver DEVICE location = main tower / assisted living. Member: NURSESTATION-PC. Drives default-printer = Nurses via ILT (computer context).
• SG-PC-MemoryCare — caregiver DEVICE location = memory care. Empty (ready). Drives default-printer = MC MedTech.

Design — GPO CSC - Caregiver Workstation (User config GPP), NOT YET CREATED:

• Shortcuts (Desktop): ALIS https://cascadestucson.alisonline.com/Login, LinkRx https://pharmcare.linkrxnow.com/Login.aspx, Safe Living https://app.safe-living.com/login. (Existing ALIS/LinkRx today are per-profile .url files placed manually — this GPO replaces that.)
• Printers (Howard-approved set, all \\CS-SERVER\): NursesPrinter, HealthServices, MCMedTech, MCReception, MCDirector, CopyRoom — deployed to all (no filter). Plus conditional default via two extra default="1" entries with ILT: NursesPrinter when computer ∈ SG-PC-MainTower; MCMedTech when computer ∈ SG-PC-MemoryCare (userContext="0").
• Link at OU=Caregivers,OU=Departments; security filter = SG-Caregivers-Test (remove Authenticated Users Apply) so only pilot.test applies it; 38 real caregivers see it in scope but filtered out = zero impact.
• Set gPCUserExtensionNames (printers+shortcuts CSEs), bump version, set Computer-side disabled.

Next steps (resume here)

• Create GPO CSC - Caregiver Workstation; write User\Preferences\Printers\Printers.xml + User\Preferences\Shortcuts\Shortcuts.xml; set gPCUserExtensionNames + bump versionNumber.
• Link at OU=Caregivers,OU=Departments; set security filtering to SG-Caregivers-Test only.
• Test on NURSESTATION as pilot.test: gpupdate /force → logoff/logon → verify 3 desktop shortcuts + 6 printers mapped + Nurses default.
• When validated: swap GPO filter SG-Caregivers-Test → SG-Caregivers; for CA, promote allow-list policy from test group to SG-Caregivers; move real caregiver machines into OU=Caregiver Devices + correct SG-PC-* location group one at a time; ALIS email-match the 38 + medtechs.
• CSC - Printer Deployment (domain-wide, empty CSE/version 0) is intentionally not enabled and is NOT to be used domain-wide (per Howard). Leave it alone — do not link, enable, or "fix" it. Our entire scope is the single caregiver/medtech GPO. It's useful only as a read-only reference for printer shares/ILT examples.
• Microsoft case for INTUNE_A PendingInput (independent — does NOT block caregiver access; the hybrid+GPO path replaces the Intune dependency).

Update: 17:30 MST — Caregiver Workstation GPO built + validated; Device Lockdown GPO designed (deploy PENDING)

DONE & VALIDATED: CSC - Caregiver Workstation GPO (shortcuts + printers)

GPO {3B5CD9A6-A278-4676-A9FD-9396D21A8261} — User-config Group Policy Preferences. Built via RMM on CS-SERVER, hand-authored GPP XML cloned from the domain's working schema. Scripts saved: clients/cascades-tucson/scripts/build-caregiver-gpo.ps1 + link-caregiver-gpo.ps1.

• Shortcuts (Desktop): ALIS (https://cascadestucson.alisonline.com/Login), LinkRx (https://pharmcare.linkrxnow.com/Login.aspx), Helpany (https://app.safe-living.com/login — named "Helpany," the brand caregivers know, not "Safe Living").
• Printers (all \\CS-SERVER\): NursesPrinter, HealthServices, MCMedTech, MCReception, MCDirector, CopyRoom — deployed to all; default by device location via item-level targeting on computer group (SG-PC-MainTower→Nurses, SG-PC-MemoryCare→MCMedTech, userContext="0").
• Registry: HKCU ...\CurrentVersion\Windows\LegacyDefaultPrinterMode=1 (stops Windows "manage my default printer" so the Nurses default sticks).
• CSEs registered (Registry+Printers+Shortcuts), versionNumber user-v2 = 131072 (AD == GPT.ini). Computer side disabled.
• Linked at OU=Caregivers,OU=Departments. Security filter: Authenticated Users = Read (MS16-072 — computer must read user GPO), SG-Caregivers-Test = Apply (pilot.test only). 38 real caregivers in scope but filtered out = zero impact.
• TEST RESULT (Howard, on NURSESTATION as pilot.test): everything showed up as expected — 3 shortcuts + 6 printers + Nurses default. Then added LegacyDefaultPrinterMode (re-ran build, user-v2) — applies on next policy refresh.

Timeout / auto-logout decision (Howard)

• Screen LOCK: 3 minutes idle. Auto SIGN-OUT: 15 minutes total idle. Warning: 90 seconds before sign-out.
• ALIS app timeout: default 20 min → lower to 15 min to match the Windows sign-out (no PHI-exposure gap). Change is made in the ALIS/Medtelligent admin console by Howard — Claude has no ALIS-admin access. PENDING.

DESIGNED, NOT YET DEPLOYED: CSC - Caregiver Device Lockdown GPO (computer side)

Scripts written + committed but the GPO does NOT exist yet (every deploy dispatch failed before reaching CS-SERVER — clean slate, just needs to run). Scripts: clients/cascades-tucson/scripts/caregiver-lockdown.ps1 (the computer startup script) + deploy-device-lockdown-gpo.ps1 (creates GPO, writes startup script + psscripts.ini to SYSVOL, registers Scripts CSE {42B5FAAE-...}, links to OU=Caregiver Devices).

• Startup script (runs as SYSTEM each boot, idempotent): sets InactivityTimeoutSecs=180 (lock 3 min); powercfg display-off 10 / never sleep/hibernate (AC+DC); drops C:\ProgramData\Cascades\idle-logoff.ps1; registers scheduled task CSC Caregiver Idle Logoff (logon trigger, principal = BUILTIN\Users / InteractiveToken → runs in each caregiver's session) that monitors idle via GetLastInputInfo, shows a 90s msg.exe warning at 810s, and shutdown /l at 900s.
• Scope note: lock + auto-logoff are device-level — they affect ANY user on a device in OU=Caregiver Devices (currently only NURSESTATION), not just pilot.test. Intended for caregiver devices; confirm no nurse mid-shift before applying.

BLOCKER (why lockdown deploy didn't run) — workstation-side, needs follow-up

Dispatching to GuruRMM from HOWARD-HOME broke mid-session:

1. curl "Permission denied" executing the binary — BOTH /mingw64/bin/curl and /c/Windows/System32/curl.exe. AV/EDR appears to be blocking curl.exe after repeated large POSTs (earlier curl dispatches this session worked fine). dangerouslyDisableSandbox did NOT help → it's AV, not the tool sandbox.
2. Routed around curl via PowerShell Invoke-RestMethod (token + payload staged to C:\Users\Howard\AppData\Local\Temp\rmm_payload.json/rmm_token.txt) → RMM API returned 500 Internal Server Error on the ~13 KB payload POST.

• Retry options: run deploy-device-lockdown-gpo.ps1 directly on CS-SERVER (console/RDP) instead of via RMM; or dispatch from a different workstation; or investigate the curl block (AV exclusion for curl.exe) and the RMM 500 (payload size? try a smaller dispatch / chunk the base64).

Resume / TODO

• Deploy CSC - Caregiver Device Lockdown (run the deploy script on/against CS-SERVER); reboot NURSESTATION; verify lock@3min, 90s warning + sign-out@15min, never-sleep.
• Howard: lower ALIS app timeout 20→15 in ALIS admin.
• Investigate curl "Permission denied" on HOWARD-HOME (AV exclusion) + the RMM API 500 on large payloads.
• Go-live (unchanged): swap CSC - Caregiver Workstation filter SG-Caregivers-Test→SG-Caregivers; CA allow-list test group→SG-Caregivers; move machines into OU=Caregiver Devices + SG-PC-* one at a time; ALIS email-match the 38 + medtechs.

Update: 18:05 MST — Lockdown GPO DEPLOYED + ticket updated; block resolved

• CSC - Caregiver Device Lockdown DEPLOYED — {E6174988-2721-4D96-ADF5-F5BB44E92769}, computer-only (UserSettingsDisabled), startup script + psscripts.ini in SYSVOL, Scripts CSE registered (versionNumber 2, AD == GPT.ini), linked at OU=Caregiver Devices. (Startup scripts run at BOOT — NURSESTATION must reboot to run it: sets InactivityTimeoutSecs=180, powercfg never-sleep, registers the CSC Caregiver Idle Logoff scheduled task.)
• Block resolved: the earlier curl "Permission denied" / RMM-dispatch failure was a workstation-side AV/process block that Howard fixed; re-dispatched via curl and it deployed first try. (The prior RMM 500 was during the blocked window; not reproduced.)
• Syncro ticket #110680053 (Syncro #32303, "Domain setup-entra sync", Cascades) updated with the 6/4–6/5 work summary as an internal/hidden note (do_not_email), comment id 417580711. Framed around the caregiver/medtech laptop+desktop setup, the Win Pro + Win11 25H2 upgrades, the Microsoft Intune-provisioning dead-end and the pivot to Hybrid Entra Join + GPO, the test/security groups, validated on the pilot, switching users Monday.
• Remaining to fully finish the test: reboot NURSESTATION → verify lock@3min + 90s warning + sign-out@15min + never-sleep; Howard lowers ALIS app timeout 20→15; then Monday cutover (one user/machine at a time).