sync: auto-sync from HOWARD-HOME at 2026-07-09 20:26:12

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-09 20:26:12

clients/cascades-tucson/session-logs/2026-07/2026-07-09-howard-charity-menle-caregiver-rename.md

@@ -140,3 +140,51 @@ alis: error: unrecognized arguments: --json        # --json is a global flag: al
 - Prior art / why rename-not-recreate: `clients/cascades-tucson/reports/2026-07-01-caretaker-roster-update.md` (the `t.lassey-assiakoley` duplicate), and `clients/cascades-tucson/scripts/create-caregiver-accounts.ps1:11` (`b.sika -- Charity Sika (legal first name Bariffa drives the initial)`).
 - Forced-change / `50126` phone-login rule and `PSO-Caregivers` rationale: `wiki/clients/cascades-tucson.md`, sections "Caregiver phone login -- forced-change-at-next-logon gotcha" and "Caregiver password expiry".
 - New wiki section written this session: "Caregiver name changes -- rename, never re-create (Charity Menle, 2026-07-09)".
+
+---
+
+## Update: 19:45 UTC -- Android shared-phone enrollment (new phone) + token replace
+
+(Timestamps in UTC. `now-phoenix.sh` returned `20:23 PT` against a real UTC time of `19:43` -- not a valid UTC-7 offset, so local time was not trusted for this entry. Same class of bug as the `GURU-BEAST-ROG` TZ friction entry in `errorlog.md` from the same day.)
+
+### What happened
+
+Howard needed to enroll additional Samsung shared caregiver phones. The vaulted Intune Android enrollment token was **stale** (`MVDVVDMPSHYJAGDAJOCN`, old profile `CSC - Android Shared Phones`, expired 2026-06-22). The live profile turned out to be `CSC - Android Shared Phones (Entra SDM)` (`9a0fcc6d-0a88-466e-aa53-44401bb74fca`), whose QR was pulled live from Graph and vaulted as `clients/cascades-tucson/intune-android-enrollment-token.sops.yaml`.
+
+That token (`KJCFJUWKRCOGATEHBTGYJZXM`) was then **rejected by Google at redemption** -- the phone displayed "checking code" then an error telling the user to contact IT -- even though Graph reported it valid through 2027-05-08 and the Managed Google Play binding was `boundAndValidated` with a successful app sync that morning. Howard fixed it in the Intune portal with **Replace Token** (not Revoke, which would leave the profile with no usable token). The replacement token carries an expiry of **2091-07-10** (~65 years) and enrolled a phone immediately.
+
+Enrollment then succeeded: `CSC-R9TX70L693H` (serial `R9TX70L693H`), enrolled 18:33:52Z, `androidEnterpriseDedicatedDevice` / `googleCloudDevicePolicyController`, company-owned, encrypted, one Intune record and one Entra object (no duplicates). It joined the dynamic group `Cascades - Shared Phones` within ~3 minutes and both config profiles reported applied by 18:41.
+
+The phone never became usable. Apps (Managed Home Screen, Alis) installed and uninstalled repeatedly -- six-plus cycles observed by Howard on the handset. Intune-side configuration was exhaustively verified as correct and was **not** the cause. The device stopped checking in at **18:51:26Z** and never resumed across a 52-minute poll. **Howard swapped the handset out; he reports this phone had known prior issues.** Root cause was never established from the tenant side, and Graph exposes no app-install state for these devices.
+
+### What was verified correct (so it can be ruled out next time)
+
+- `kioskModeApps` (9) and `kioskModeWallpaperUrl` are set on `CSC - Android Shared Phones Restrictions` (`070a76c2-a8c3-4f7f-9ba7-1f4ac5084184`), and `kioskModeUseManagedHomeScreenApp: multiAppMode`.
+- All 10 Android apps are assigned `required` to the shared-phone group. **No `uninstall` intent anywhere; no duplicate packageIds.**
+- `playStoreMode: notConfigured`; `proxySettings: none` on the CSCNet Wi-Fi profile.
+- Group membership stable; `enrollmentProfileName` present on the Entra device object.
+- Eleven identical phones (same models) run this exact config and check in daily.
+
+### Two Graph fields that are NOT evidence (both burned me this session)
+
+- **`freeStorageSpaceInBytes` / `totalStorageSpaceInBytes` are not collected for Android Enterprise dedicated devices.** Every one of the 26 phones reports `free = 0` and an implausible `total` (4.54 / 5.38 GB). I read `0` as "out of storage" and told Howard the phone was full and was the wrong model. **Both claims were false** -- he was looking at 15 GB used of 64 GB, and `SM-S146VL` is 9 of the 26 phones including working ones. Never treat a zero here as a measurement.
+- **`detectedApps` is empty on ALL these devices**, including phones that sync daily. It is not an app-inventory source for COSU. Do not use it to conclude an app did or did not install.
+
+The only trustworthy device-side signal available from Graph is **`lastSyncDateTime`** plus `deviceConfigurationStates`.
+
+### Fleet observation (not acted on, Howard's answer recorded)
+
+Of 26 Android device records, 15 last synced within a day of enrollment (May 11-18) and never again; 11 sync daily. Howard confirmed: **14 of the phones are simply powered off.** Not a fault. Two records (`CSC-R92W60LRA8Z`, `CSC-R9TW20DGYKF`) are duplicate objects from re-enrollment; 22 unique physical phones + the new one. `samsungSM-F731U` in the Android list is John Trozzi's personal Galaxy Z Flip 5, `trustType: Workplace` BYOD -- correctly outside the profile and group, not a shared phone.
+
+### Configuration changes
+
+- **Intune (via portal, by Howard):** enrollment token on profile `9a0fcc6d` replaced. Nothing else changed. Profile name, dynamic group rule, and the enrolled phones were deliberately left untouched.
+- **Vault:** `clients/cascades-tucson/intune-android-enrollment-token.sops.yaml` created, then updated with the post-Replace token + `token_expires: 2091-07-10` + a `token_replaced` note. Verified encrypted (8 `ENC[]` fields; token absent from plaintext; all 37 Cascades entries scanned clean).
+- **No brightness change was applied.** `show_brightness_slider` / `show_adaptive_brightness_toggle` exist in the Managed Home Screen schema and both default `False`, which is why caregivers cannot adjust brightness. Applying them requires editing the group-targeted app config `CSC - MHS layout` (`27683709-7b78-4b52-9c53-bb4401955bbf`) -- **Intune has no per-device app config**, and a second app config for the same app on one device is a conflict. Left unapplied at Howard's direction.
+
+### Pending
+
+- **Brightness**: add `show_brightness_slider=true` (+ optionally `show_adaptive_brightness_toggle`, `show_volume_setting`) to the existing `payloadJson` on app config `27683709`, keeping `screen_orientation` / `set_grid_size` / `lock_home_screen`. Snapshot `payloadJson` first for rollback. Fleet-wide by necessity.
+- **Bad handset `CSC-R9TX70L693H`** swapped out. Its stale Intune record + Entra object should be cleaned up so it doesn't join the duplicate pile.
+- Stray **`Microsoft Launcher`** (`com.microsoft.launcher`, consumer launcher) sits in the tenant app list unassigned. Harmless now; if ever assigned it would fight Managed Home Screen. Worth deleting.
+- Enrollment of the replacement phone(s) not yet observed.

errorlog.md

@@ -19,6 +19,12 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure ·
 
 <!-- Append entries below this line -->
 
+2026-07-10 | Howard-Home | bash/env | [friction] [friction] now-phoenix.sh returned '20:23 PT' when real UTC was 19:43 (not a valid UTC-7 offset); did not trust it for a session-log timestamp - used UTC [ctx: ref=errorlog GURU-BEAST-ROG TZ entry same day]
+
+2026-07-10 | Howard-Home | remediation-tool/intune | [correction] used detectedApps==0 as evidence Managed Home Screen had not installed; detectedApps is empty on ALL COSU devices incl. daily-syncing ones - only lastSyncDateTime + deviceConfigurationStates are trustworthy [ctx: client=cascades-tucson]
+
+2026-07-10 | Howard-Home | remediation-tool/intune | [correction] read Graph freeStorageSpaceInBytes=0 + totalStorage=4.54GB as fact and told user the phone was out of storage and the wrong model; both fields are NOT collected for Android Enterprise dedicated devices (all 26 phones report 0) - verify a metric against a known-good device BEFORE reporting it as a finding [ctx: client=cascades-tucson device=CSC-R9TX70L693H]
+
 2026-07-10 | Howard-Home | unifi-wifi/gw-sitemanager.sh | [friction] net <console> raw <path> truncates JSON at [:5000] chars, so /stat/sta output is unparseable for sites with >~10 clients; had to re-query api.ui.com directly with the vaulted key [ctx: script=gw-sitemanager.sh line=264 workaround=direct-curl]
 
 2026-07-10 | Howard-Home | unifi-wifi/gw-sitemanager | Site Manager API call failed (HTTP 404) [ctx: path=/v1/connector/consoles/1C6A1B1BC2470000000008B8D1B50000000009302B160000000067A67E3A:1341833834/proxy/network/stat/sta]

wiki/clients/cascades-tucson.md

@@ -167,6 +167,31 @@ The caregiver phone-SSO onboarding was executed 2026-06-30. To silently SSO into
 - **Fix applied 2026-07-02 (Howard):** swept **all 35 `SG-Caregivers`** on CS-SERVER with `Set-ADUser <sam> -ChangePasswordAtLogon $false` (RMM cmd `45660cd8`). Every one was stuck (`cleared=35 already_ok=0`). This clears the must-change flag and un-expires the password **without changing it** -- the vaulted temp passwords (`clients/cascades-tucson/caregiver-temp-passwords-2026-06-30` + `-2026-07-01`) are now valid for phone sign-in; PHS syncs the state to Entra in ~2 min. Diagnosis first surfaced on Agnes McFerren (`a.mcferren`, temp `Meadow8541@`).
 - **RULE for future caregiver onboarding:** phone-only/shared-device caregivers must be created with **`-ChangePasswordAtLogon $false`** (accept the risk of a static temp password, or have them complete the one-time change on a domain desktop **before** touching the phone). Never leave forced-change set on a caregiver who will sign in on a shared phone -- it always fails as `50126`. Diagnose via the `remediation-tool` sign-in logs (`$filter` on the signIns endpoint hangs on this tenant -- pull a small unfiltered page `?$top=50` and grep client-side) + `pwdLastSet`/`PasswordExpired` on CS-SERVER.
 
+### Caregiver shared phones -- Intune enrollment + Managed Home Screen (verified 2026-07-09)
+The 25 Samsung shared caregiver phones (`SM-A146U` x16, `SM-S146VL` x9, `SM-A146U1` x1) are Android Enterprise **corporate-owned dedicated devices** (`googleCloudDevicePolicyController`), enrolled by QR against ONE profile and configured entirely through group-targeted policy.
+
+- **Enrollment profile:** `CSC - Android Shared Phones (Entra SDM)` = `9a0fcc6d-0a88-466e-aa53-44401bb74fca`, `corporateOwnedDedicatedDevice`. It **replaced** an older default-token profile named `CSC - Android Shared Phones`.
+- **Settings ride the profile NAME, not the token.** Dynamic group `Cascades - Shared Phones` (`ea96f4b7-3000-45da-ab1f-ddb28f509526`) has rule `(device.enrollmentProfileName -startsWith "CSC - Android Shared Phones")`, so both names match. **NEVER create a new enrollment profile** to add phones -- a differently-named profile falls outside the rule and new phones enroll into a policy vacuum, looking fine while inheriting nothing. Reuse the existing profile's QR.
+- **Policy targeting that group:** device configs `CSC - Android Shared Phones Restrictions` (`070a76c2` -- holds `kioskModeWallpaperUrl` + the 9 `kioskModeApps` incl. the Alis/HelpAny/LinkRx web apps, `kioskModeUseManagedHomeScreenApp: multiAppMode`) and `CSC - CSCNet Wi-Fi` (`b572ba54`, no proxy); app configs `CSC - MHS layout` (`27683709`), `... Shared Device Mode (Teams)`, `... (Authenticator)`. Ten apps assigned `required`; none `uninstall`.
+- **Wallpaper + links render only once Managed Home Screen (`com.microsoft.launcher.enterprise`) installs** from Managed Google Play and takes over as launcher. Until then a new phone shows the stock Samsung home screen. The wallpaper is fetched by the phone from the public `https://cascadestucson.com/...` URL -- if links appear but the background does not, check that egress, not the profile.
+- **Brightness/volume are NOT caregiver-adjustable today.** MHS schema keys `show_brightness_slider`, `show_adaptive_brightness_toggle`, `show_volume_setting` all default **False**; `show_managed_setting` defaults True, so the Managed Settings icon is present but empty. To enable, add the keys to `payloadJson` on app config `27683709` (keep `screen_orientation` / `set_grid_size` / `lock_home_screen`). **Intune has no per-device app config** -- it targets the group, so this is necessarily fleet-wide; a second app config for the same app on one device is a conflict, not a scoping trick.
+- **Managed Google Play binding is owned by `MDMS@cascadestucson.com`** (`boundAndValidated`). That account -- not the token -- is the single point of failure for ALL Android management: if it is deleted/disabled/unlicensed, every phone loses management. Vault: `clients/cascades-tucson/mdm-service-account.sops.yaml`.
+- **Stale-device cleanup is OFF** (`deviceInactivityBeforeRetirementInDays: null`), so a phone that stops checking in is never auto-retired. Enrolled phones do not "fall off" on their own, and an enrollment token is a one-time entry ticket -- revoking or replacing it **never** affects already-enrolled devices and never requires a reset.
+
+#### Enrollment token -- Replace, don't Revoke (incident 2026-07-09)
+The token vaulted in `mdm-service-account.sops.yaml` (`android_enrollment.token`) went **stale**, and its successor was then **rejected by Google at redemption** ("checking code" -> error, contact your IT admin) *despite Graph reporting a 2027 expiry* and a healthy Play binding. `tokenExpirationDateTime` reflects what Intune requested, not what Google still honors -- **treat it as a claim, not a fact.** Fix: Intune portal -> the existing profile -> Token -> **Replace token** (Revoke alone leaves the profile with NO usable token). The replacement issued a **2091** expiry (~65 years, effectively never) and enrolled a phone immediately -- so a long validity is NOT what caused the rejection, and an effectively-never-expiring token IS available. Current token, profile id, and the exact re-pull command: `clients/cascades-tucson/intune-android-enrollment-token.sops.yaml`.
+Re-pulling the QR needs the **`tenant-admin`** remediation-tool tier (`DeviceManagementConfiguration.Read.All`); `investigator` 403s:
+`GET /beta/deviceManagement/androidDeviceOwnerEnrollmentProfiles/<id>?$select=qrCodeImage` -> base64 PNG (256x256; upscale nearest-neighbour if it will not scan). `qrCodeContent` is base64-wrapped JSON, not raw JSON.
+
+#### Graph fields that are NOT evidence on these devices (cost real time 2026-07-09)
+- **`freeStorageSpaceInBytes` / `totalStorageSpaceInBytes` are not collected** for Android Enterprise dedicated devices. ALL 26 phones report `free = 0` and an implausible total (4.54 / 5.38 GB). A `0` here means "not reported", NOT "out of space". Reading it as a measurement produced a confidently wrong "the phone is full and it's the wrong model" diagnosis -- the handset actually had ~15 GB used of 64 GB, and `SM-S146VL` is 9 of the fleet's own phones, including ones that work.
+- **`detectedApps` is empty on every one of these phones**, including phones that sync daily. It is not an app-inventory source here; never conclude an app did or did not install from it.
+- The only trustworthy device-side signals are **`lastSyncDateTime`** and **`deviceConfigurationStates`**.
+- **Compliance tracks check-in, not health**: a phone that has not synced evaluates `noncompliant`. As of 2026-07-09, **14 phones are simply powered off** (Howard confirmed) -- their `noncompliant` status is not a fault. Two records (`CSC-R92W60LRA8Z`, `CSC-R9TW20DGYKF`) are duplicate objects from re-enrollment; 22 unique physical phones. `samsungSM-F731U` in the Android list is **John Trozzi's personal Galaxy Z Flip 5** (`trustType: Workplace`, BYOD) -- correctly outside the profile/group, not a shared phone.
+
+#### Unresolved
+`CSC-R9TX70L693H` (enrolled 2026-07-09 18:33Z) enrolled cleanly -- single device object, both profiles applied, joined the group -- but cycled install/uninstall of Managed Home Screen + Alis 6+ times and stopped checking in at 18:51Z. Every Intune-side control was verified correct (assignments/intents, no duplicate packages, `playStoreMode: notConfigured`, no Wi-Fi proxy, stable group membership) and 11 identical phones run the same config. **Handset swapped out as bad (known prior issues).** Root cause never established; Graph exposes no app-install state for COSU devices, so the failure reason is visible only in the work Play Store on the device itself. Its stale Intune/Entra records should be deleted. Also stray: **`Microsoft Launcher`** (`com.microsoft.launcher`, the consumer launcher) sits unassigned in the tenant app list -- harmless now, but it would fight Managed Home Screen if ever assigned.
+
 ### Caregiver name changes -- rename, never re-create (Charity Menle, 2026-07-09)
 A caregiver who legally changes her name gets the **existing AD object renamed**, not a new account. Creating a second account duplicates the identity, burns a second Business Premium seat, and leaves two AD objects competing for one ALIS staff record (the failure mode behind the `t.lassey-assiakoley` duplicate on 7/1).
 - **Case:** `b.sika` (Charity Sika, legal first name Bariffa -- the `b.` initial) -> **`c.menle` / `Charity Menle`**. Howard updated ALIS staffId 309045 first (`Email = c.menle@cascadestucson.com`); AD was then renamed to match, because ALIS SSO joins on **ALIS `Email` == Entra UPN**.