azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-09 20:26:12
This commit is contained in:
Howard Enos
2026-07-09 20:26:40 -07:00
parent 2fba62b7df
commit bf95a10685
3 changed files with 79 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
wiki/clients/cascades-tucson.md
View File

@@ -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**.