sync: auto-sync from HOWARD-HOME at 2026-07-09 11:00:18

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-09 11:00:18

clients/cascades-tucson/docs/cloud/caretaker-phones-only-list.md

@@ -25,7 +25,7 @@ Transportation drivers, who do not get ALIS/M365 caregiver access at all.
 | Ashli Atwood | a.atwood | D+P | TBD |
 | Alejandra Vallejo | a.vallejo | new hire 7/1 | TBD |
 | Barb Johnson | b.johnson | D+P | TBD |
-| Charity Sika | b.sika | D+P | TBD |
+| Charity Menle | c.menle | D+P | TBD |
 | Cole Johnson | c.johnson | D+P | TBD |
 | Celia Lassey | c.lassey | D+P | TBD |
 | Espe Esperance | e.esperance | D+P | TBD |

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

@@ -0,0 +1,142 @@
+# 2026-07-09 — Cascades of Tucson: Charity Sika -> Charity Menle caregiver rename (ALIS SSO)
+
+## User
+- **User:** Howard Enos (howard)
+- **Machine:** Howard-Home
+- **Role:** tech
+
+---
+
+## Session Summary
+
+The request arrived as "Charity Menle needs an email setup for Cascades Tucson and be put in the caregivers group," with a follow-up clarifying the goal was to make ALIS SSO work for her. Before provisioning anything, the name was checked against the authoritative sources. "Menle" appeared nowhere — not in the ALIS roster (612 staff records pulled via the read-only API), not in AD, and not in any Cascades doc, roster, or CSV in the repo. The only Charity on record was Charity Sika, whose AD account `b.sika` already existed, was enabled, Business Premium licensed, and already a member of `SG-Caregivers`. The `b.` initial derives from her legal first name Bariffa, documented at `clients/cascades-tucson/scripts/create-caregiver-accounts.ps1:11`.
+
+Rather than create an account, the identity conflict was raised with the user. He confirmed it was the same person, that she had legally changed her name, and that he had already updated the ALIS record himself. A re-read of ALIS staffId 309045 confirmed it: `Charity Menle`, `primaryEmail = c.menle@cascadestucson.com` (it had been `Bariffa Sika` with a null email earlier in the same session). Since ALIS SSO joins on **ALIS `Email` == Entra UPN**, and AD still carried `b.sika@cascadestucson.com`, the mismatch was the actual reason SSO would not resolve. The correct fix was a rename of the existing object, not a new account — a duplicate would have consumed a second Business Premium seat and left two AD objects competing for one ALIS staff record, the same failure that produced the `t.lassey-assiakoley` duplicate on the 7/1 reconcile.
+
+A read-only pass on `b.sika` showed a clean object: empty `mail`, empty `proxyAddresses`, `PasswordExpired = False`, `PSO-Caregivers` applying, and `SG-Caregivers` as the only group. No collision existed on `c.menle` or `c.menle@cascadestucson.com`. The plan was previewed to the user (including the fact that her Windows/M365 login username would change while her password would not), and he approved.
+
+The rename ran on CS-SERVER as a single PowerShell script via GuruRMM (`cmd:518f678e`, exit 0): `Set-ADUser` for `Surname`/`DisplayName`/`UserPrincipalName`/`EmailAddress` plus an explicit `proxyAddresses` add, then `Rename-ADObject` for the CN, then `Set-ADUser -SamAccountName`. `Start-ADSyncSyncCycle -PolicyType Delta` was invoked in the same script (the ADSync module is present on CS-SERVER, confirming Entra Connect runs there). The Entra export is asynchronous — the first Graph read still returned the old UPN, and the object only reflected the rename on a subsequent poll roughly 25 seconds later.
+
+Post-change verification via the `remediation-tool` investigator tier confirmed the cloud object: `displayName = Charity Menle`, `userPrincipalName`/`mail` = `c.menle@cascadestucson.com`, `onPremisesSamAccountName = c.menle`, `accountEnabled = true`, `usageLocation = US`, license `SPB` intact, and `SG-Caregivers` (`8b8d9222`) membership unchanged. `proxyAddresses` carried `SMTP:c.menle@` (primary), `smtp:b.sika@` (alias), and the tenant `smtp:b.sika@NETORGFT4257522.onmicrosoft.com` routing alias that Entra Connect preserved on its own. The 6/29 open item ("Confirm Charity Sika (CSV) == Bariffa Sika (ALIS 309045)") was resolved and closed in the wiki.
+
+---
+
+## Key Decisions
+
+- **Renamed the existing AD object instead of creating a new account**, against the literal wording of the request. A second account would duplicate the identity, consume a second Business Premium seat (SPB pool had only 4 free as of 7/1), and leave two AD objects competing for one ALIS staff record — the `t.lassey-assiakoley` failure mode. The user's own clarification ("just edit the sika bariffa account to match the new name") confirmed this reading.
+- **Stopped and asked before writing** rather than provisioning on a name that matched nothing in ALIS, AD, or any repo doc. The discrepancy between "Menle" and the only on-record Charity (Sika) was too large to resolve by inference.
+- **Set `proxyAddresses` explicitly** (`SMTP:c.menle@` primary + `smtp:b.sika@` alias) rather than relying on the UPN change to move the mailbox. These caregiver objects have an empty `proxyAddresses`, so Exchange Online derived primary SMTP from the UPN at provisioning; renaming the UPN alone is not a reliable way to move primary SMTP, and without the old address as an alias, inbound mail to `b.sika@` would bounce.
+- **Changed `sAMAccountName` to `c.menle`** rather than leaving `b.sika`. The Cascades design is Windows login = email = M365/ALIS identity (one credential everywhere); leaving the old sAMAccountName would have defeated it.
+- **Did not touch group, license, or password.** All three ride the unchanged object — `SG-Caregivers` membership, Business Premium, and `PSO-Caregivers` (never-expire) survive a rename. Re-adding any of them would have been a no-op at best.
+- **Left ALIS alone.** The user explicitly took that side. Her ALIS record already reads `Charity Menle` / `c.menle@`, so no `--format update` .xls import was needed.
+
+---
+
+## Problems Encountered
+
+- **`--json` is a global flag on the `alis` CLI, not a subcommand flag.** `alis.py staff --json` errored with `unrecognized arguments: --json`; the correct form is `alis.py --json staff`. Resolved by moving the flag before the subcommand.
+- **Used `$UID` as a shell variable in a Bash tool script.** `UID` is readonly in bash, so the assignment failed (`readonly variable`) and the downstream Graph `licenseDetails` / `memberOf` calls silently ran against an empty user id, returning nothing. Resolved by renaming the variable to `OBJ`. Logged to `errorlog.md` via `log-skill-error.sh --friction`.
+- **First Graph read after the delta sync still returned the old UPN**, which reads as a failed sync. It is not — `Start-ADSyncSyncCycle` returned `Success` and the Entra export is asynchronous. Resolved by polling the object by its stable objectId (`0dd5cb5d-…`) until the UPN flipped, which took roughly 25 seconds. Note the lookup had to be done by objectId or old UPN, since `GET /users/c.menle@…` 404s until the sync lands.
+
+---
+
+## Configuration Changes
+
+**Live AD / Entra (CS-SERVER, `cascades.local`) — user object `cfa2d909-4cf2-46a5-8a1c-120602e2a2e2`:**
+
+| Attribute | Before | After |
+|---|---|---|
+| `sAMAccountName` | `b.sika` | `c.menle` |
+| `userPrincipalName` | `b.sika@cascadestucson.com` | `c.menle@cascadestucson.com` |
+| `CN` / `Name` | `Charity Sika` | `Charity Menle` |
+| `DisplayName` | (empty) | `Charity Menle` |
+| `Surname` | `Sika` | `Menle` |
+| `mail` | (empty) | `c.menle@cascadestucson.com` |
+| `proxyAddresses` | (empty) | `SMTP:c.menle@cascadestucson.com`, `smtp:b.sika@cascadestucson.com` |
+
+Unchanged: `GivenName` (`Charity`), `Enabled` (true), password, `SG-Caregivers` membership, Business Premium (`SPB`) license, `PSO-Caregivers` resultant policy, OU (`OU=Caregivers,OU=Departments,DC=cascades,DC=local`).
+
+**Repo files modified:**
+- `wiki/clients/cascades-tucson.md` — resolved the 6/29 "Confirm Charity Sika == Bariffa Sika" open item; added new subsection **"Caregiver name changes -- rename, never re-create"** documenting the procedure, the `proxyAddresses` gotcha, the async-sync gotcha, and the vault-key gotcha.
+- `clients/cascades-tucson/docs/cloud/caretaker-phones-only-list.md` — roster row `Charity Sika | b.sika` -> `Charity Menle | c.menle`.
+- `errorlog.md` — one `--friction` entry (bash `$UID` readonly).
+
+---
+
+## Credentials & Secrets
+
+- **No credential was created, rotated, or changed.** Her password is unchanged by the rename.
+- **Vault key gotcha:** Charity Menle's temp password remains filed under the OLD sAMAccountName key — `b.sika` in `clients/cascades-tucson/caregiver-temp-passwords-2026-06-30.sops.yaml`. Retrieve with `vault get` (NOT `get-field` — the keys contain dots). She now signs in as `c.menle` with that same password. The vault entry was deliberately not re-keyed.
+- Tokens used this session: GuruRMM JWT via `.claude/scripts/rmm-auth.sh` (vault `infrastructure/gururmm-server.sops.yaml`); ALIS JWT via `clients/cascades-tucson/alis-api-howard-user.sops.yaml`; Graph token via `remediation-tool` `get-token.sh cascadestucson.com investigator`.
+
+---
+
+## Infrastructure & Servers
+
+- **CS-SERVER** — `192.168.2.254` (SMB clients use `192.168.2.248`). DC / DNS / file server / Hyper-V host. GuruRMM agent `c39f1de7-d5b6-45ae-b132-e06977ab1713` (resolved live via `rmm-search.sh`, never hardcoded). **Confirmed this session: the `ADSync` module is present on CS-SERVER — Entra Connect runs here**, so `Start-ADSyncSyncCycle -PolicyType Delta` can be dispatched directly to this agent.
+- **Tenant:** `cascadestucson.com`, routing domain `NETORGFT4257522.onmicrosoft.com`.
+- **Entra objects:** user `0dd5cb5d-6143-4151-b4a7-6e37b3d071b0` (cloud), AD GUID `cfa2d909-4cf2-46a5-8a1c-120602e2a2e2`; group `SG-Caregivers` = `8b8d9222-5d71-419a-936d-56d895c6c332`.
+- **ALIS:** communityId 622, staffId **309045** — now `Charity Menle`, `primaryEmail = c.menle@cascadestucson.com`, status Hired, jobRole `Certified Caregiver`, securityRoles `[Caregiver (Cascades)]`.
+
+---
+
+## Commands & Outputs
+
+Resolve the agent (never hardcode the UUID):
+```bash
+bash .claude/scripts/rmm-search.sh cs-server -c cascades --json
+# -> CS-SERVER  c39f1de7-d5b6-45ae-b132-e06977ab1713  online
+```
+
+Read the ALIS roster (note `--json` is a GLOBAL flag, before the subcommand):
+```bash
+bash .claude/scripts/py.sh .claude/skills/alis/scripts/alis.py --json staff --limit 1000
+```
+
+The rename itself (dispatched to CS-SERVER as `powershell`, `cmd:518f678e`, exit 0):
+```powershell
+$u = Get-ADUser b.sika -Properties proxyAddresses
+$g = $u.ObjectGUID
+Set-ADUser -Identity $g -Surname "Menle" -DisplayName "Charity Menle" `
+  -UserPrincipalName "c.menle@cascadestucson.com" -EmailAddress "c.menle@cascadestucson.com" `
+  -Add @{proxyAddresses=@("SMTP:c.menle@cascadestucson.com","smtp:b.sika@cascadestucson.com")}
+Rename-ADObject -Identity (Get-ADUser -Identity $g).DistinguishedName -NewName "Charity Menle"
+Set-ADUser -Identity $g -SamAccountName "c.menle"
+Import-Module ADSync; Start-ADSyncSyncCycle -PolicyType Delta   # -> Result: Success
+```
+
+Post-sync Entra verification (poll by objectId — `GET /users/c.menle@…` 404s until the export lands):
+```
+displayName: Charity Menle | userPrincipalName: c.menle@cascadestucson.com
+mail: c.menle@cascadestucson.com | onPremisesSamAccountName: c.menle
+accountEnabled: true | usageLocation: US | license: SPB
+proxyAddresses: smtp:b.sika@cascadestucson.com, SMTP:c.menle@cascadestucson.com,
+                smtp:b.sika@NETORGFT4257522.onmicrosoft.com
+memberOf: SG-Caregivers  8b8d9222-5d71-419a-936d-56d895c6c332
+```
+
+Error encountered and its fix:
+```
+/usr/bin/bash: line 15: UID: readonly variable     # $UID is reserved in bash -> use OBJ
+alis: error: unrecognized arguments: --json        # --json is a global flag: alis.py --json staff
+```
+
+---
+
+## Pending / Incomplete Tasks
+
+- **Howard (ALIS side, self-assigned):** disable ALIS-native 2FA for Charity Menle so "Sign in with Microsoft" completes silently on the shared Samsung phone. The Email=UPN join key is now satisfied on both sides.
+- **Tell Charity her login username changed** to `c.menle` — her password did NOT change and is still vaulted under the `b.sika` key in `caregiver-temp-passwords-2026-06-30.sops.yaml`.
+- **Not verified end-to-end:** actual phone SSO sign-in as `c.menle`. Everything upstream of it (UPN, license, group, PSO, ALIS email) is confirmed, but no sign-in was observed this session.
+- Carried over, untouched this session: **Juan Andrade (`j.andrade`) offboards 2026-07-11** (disable + remove from `SG-Caregivers` + reclaim SPB); ALIS Email=UPN backfill for the remaining caregivers; ALIS records for the 3 new hires (Munezero, Cota, Robinson); Vallejo's ALIS Email=UPN; ALIS app timeout 20 -> 15 min; reboot NURSESTATION to activate the lockdown GPO.
+
+---
+
+## Reference Information
+
+- GuruRMM command id: `518f678e-7f9f-42f9-b8e5-f0317a84ba36` (the rename, exit 0). Earlier read-only probes: `eb5855c9-…` (name search), plus one attribute read.
+- `#dev-alerts` post: message_id `1524831396915314729`.
+- Syncro customer ID **20149445**. No ticket was opened for this change.
+- 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)".

errorlog.md

@@ -21,6 +21,10 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure ·
 
 2026-07-09 | GURU-BEAST-ROG | bash/env | [friction] reported wrong current time: Git Bash 'TZ=America/Phoenix date' silently ignored TZ and printed UTC mislabeled as AZ; use PowerShell Get-Date (or explicit UTC-7 math) on Windows for time reporting [ctx: thread=lens-auto-browser-hijack corrected_by=Winter]
 
+2026-07-09 | Howard-Home | bash/env | [friction] used $UID as a variable in a Bash tool script; UID is readonly in bash so the assignment failed and the downstream Graph calls silently ran with an empty id - use a non-reserved name (OBJ/USER_ID)
+
+2026-07-09 | Howard-Home | screenconnect/rmm-deploy | GuruRMM one-liner install did not complete on T&C Sorensen SERVER (Server 2016 Essentials) despite live SC guest; sent twice, no enrollment ~15min - needs WMI/TLS/PS-via-SC diagnosis [ctx: ref=SRV02/CP-QB legacy-server install pattern; session=08eaff71]
+
 2026-07-09 | Howard-Home | save/sync.sh | [friction] session log written inside the guru-rmm submodule was NOT committed by /save (sync.sh only stages super-repo; git add -A does not commit files inside a submodule). Log sat untracked through two syncs. Fix: for project-scoped logs in a submodule, commit+push INSIDE the submodule, then 'sync.sh --with-submodules' to advance the pointer. [ctx: project=guru-rmm ref=save-command]
 
 2026-07-08 | Howard-Home | screenconnect/syncro | [correction] hand-rolled raw curl against ScreenConnect + Syncro APIs to look up machines/billing instead of using the /screenconnect (sc.py), /syncro, and /rmm-search skills [ctx: ref=CLAUDE.md skill-first]

wiki/clients/cascades-tucson.md

@@ -156,7 +156,7 @@ GPS is billed via a counter tied to the number of Syncro assets (not a fixed dev
 The caregiver phone-SSO onboarding was executed 2026-06-30. To silently SSO into ALIS on a shared Samsung phone, each caregiver must be (1) in `SG-Caregivers` (bypasses the tenant-wide all-users-MFA CA policy, falls under the location+device posture), (2) M365-licensed (Business Premium, which also carries the Entra ID P1 the CA lockdown needs per-user), and (3) have ALIS staff `Email` = Entra UPN. **Live AD state:** `OU=Caregivers` holds 42 objects = 40 enabled real caregivers + `pilot.test` (test artifact) + `n.castro` (disabled). All 40 real caregivers had NEVER logged into the domain (bulk-created 2026-05-16/18) and were UNLICENSED before this session.
 - **DONE (Entra/identity):** all 40 caregivers added to `SG-Caregivers` (was 38; added `c.lassey` + `p.sandoval-beck`), assigned **Microsoft 365 Business Premium** (`usageLocation=US` first, then `assignLicense`), and given unique phone-typeable AD temp passwords with **forced change at next logon** (hybrid PHS -> the AD password is also the M365/phone sign-in). Temp passwords vaulted at `clients/cascades-tucson/caregiver-temp-passwords-2026-06-30.sops.yaml` (40 entries; retrieve with `vault get`, NOT get-field -- keys contain dots; delivered to Howard via Discord DM). **`SG-Caregivers` is frontline caregivers ONLY** -- Veronica Feller + Christine Nyanzunda (admin-adjacent) and `pilot.test`/`n.castro` are intentionally excluded (reverses the earlier 6/4 plan to add Feller/Nyanzunda).
 - **REMAINING gate (Howard handling -- ALIS side):** set each caregiver's ALIS staff `Email` = Entra UPN so "Sign in with Microsoft" resolves. Of the 40 AD caregivers: 23 confirmed ALIS caregivers (just need Email=UPN), 5 in ALIS with blank job role (confirm caregiver + Email=UPN), 5 Med Techs (Email=UPN; Howard earlier said "ignore for the moment" -- revisit), **7 have NO ALIS staff record (must be created before SSO can work)**, and **3 ALIS caregivers have no AD account** (Judith Palmer, Joey Ty, Alejandra Vallejo -- create AD accounts if they need phones). Also blanket-disable ALIS-native 2FA for the caregiver bucket as records are matched. NOTE: Zeke Huerta stays `e.huerta@cascadestucson.com` (do NOT "correct" to z.huerta) -- his ALIS Email must be `e.huerta@`. Build path: `alis` skill `build-import` -> upload .xls in ALIS UI (no staff-write API).
-- **Prior crosscheck (2026-06-29):** phone-only caregivers = NONE (all caregiver rows are `D+P`; only the 3 Transportation drivers are phone-only and do not need ALIS). 7 caregiver-list people are present in ALIS only as **Discharged** records (Niel Castro, Kasey Flores, Bella Mendoza, Corey Tate, Gloria Williford, Mary Kariuki [DUP records 429856/429858], Maia Baker) -- decide reactivate-vs-recreate. Confirm Charity Sika (CSV) == Bariffa Sika (ALIS 309045).
+- **Prior crosscheck (2026-06-29):** phone-only caregivers = NONE (all caregiver rows are `D+P`; only the 3 Transportation drivers are phone-only and do not need ALIS). 7 caregiver-list people are present in ALIS only as **Discharged** records (Niel Castro, Kasey Flores, Bella Mendoza, Corey Tate, Gloria Williford, Mary Kariuki [DUP records 429856/429858], Maia Baker) -- decide reactivate-vs-recreate. **[RESOLVED 2026-07-09] Charity Sika (CSV) == Bariffa Sika (ALIS 309045)** -- same person; she has since legally changed her name to **Charity Menle** and the AD/Entra account was renamed to match (see Name changes below).
 - **[UPDATE 2026-07-01] Roster reconciled against the client's updated caretaker list + CA phone-login cutover.** The client's list was checked 1:1 against live AD (`OU=Caregivers`, 42 objects) via GuruRMM. Executed on CS-SERVER: **8 accounts disabled + removed from `SG-Caregivers` + Business Premium reclaimed** -- the 7 already-flagged leavers (b.mendoza, c.tate, d.fierros, g.williford, k.flores, m.baker, m.kariuki, all previously ALIS-Discharged/no-record and never logged in) plus `t.lassey-assiakoley` (client confirmed Tele Sepopo Lassey Assiakoley = Celia Lassey -- a duplicate of `c.lassey`, which was kept). **4 new caretakers created** (OU=Caregivers + `SG-Caregivers` + Business Premium + forced-change temp passwords): a.vallejo (Alejandra Vallejo, already an ALIS caregiver with no prior AD account), j.munezero (Jeanpabtiste Munezero), n.cota (Nicole Cota), k.robinson (Katlyn Robinson). Temp passwords vaulted at `clients/cascades-tucson/caregiver-temp-passwords-2026-07-01.sops.yaml` (retrieve with `vault get`, not `get-field` -- dotted keys). **`SG-Caregivers` is now 35 members** (down from 40; cloud group `8b8d9222` verified synced with all 4 new hires present). SPB pool: 45 enabled / 41 consumed (4 free).
   - **Zeke Huerta (e.huerta) moved to front desk** -- removed from `SG-Caregivers` only; his AD account stays in `OU=Caregivers` because Entra Connect's sync scope covers ONLY `OU=Caregivers` / `OU=Groups` / `OU=Caregiver Devices` -- an OU move would delete his cloud object. OU move deferred until `OU=Administrative` enters sync scope. He now falls under the tenant-wide `Require MFA for all users` policy with **no registered MFA method -- Authenticator registration is pending.**
   - **Christine Nyanzunda reaffirmed OUT of `SG-Caregivers`** despite the client's list naming her as a caretaker -- Howard held the frontline-only rule (established 2026-06-30). She keeps her existing `christine.nyanzunda` account with its broader (admin-adjacent) access.
@@ -167,6 +167,13 @@ 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 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**.
+- **Procedure (CS-SERVER, verified 2026-07-09):** `Set-ADUser` sets `Surname`/`DisplayName`/`UserPrincipalName`/`EmailAddress`, then `Rename-ADObject` for the CN, then `Set-ADUser -SamAccountName`. Follow with `Start-ADSyncSyncCycle -PolicyType Delta` (the ADSync module lives on CS-SERVER). Entra export is async -- the cloud object still shows the old UPN for up to a minute; poll before concluding the sync failed.
+- **Always set `proxyAddresses` explicitly** -- `SMTP:<new>@` (primary) + `smtp:<old>@` (alias). These caregiver objects have an EMPTY `proxyAddresses`, so Exchange Online derived primary SMTP from the UPN at provisioning; renaming the UPN alone is not a reliable way to move the primary SMTP, and without the old address as an alias, inbound mail to it bounces. Entra Connect preserves the tenant `*.onmicrosoft.com` routing alias on its own.
+- **The password does NOT change** and no group/license action is needed (`SG-Caregivers` membership, Business Premium, and `PSO-Caregivers` all ride the unchanged object). **Vault gotcha:** her temp password stays filed under the OLD key -- Charity Menle's is `b.sika` in `clients/cascades-tucson/caregiver-temp-passwords-2026-06-30.sops.yaml`. She now signs in as `c.menle` with that same password.
+
 ### Caregiver password expiry -- `PSO-Caregivers` (never-expire, created 2026-07-02)
 **Why it exists:** caregiver temp passwords are used on shared phones that cannot run the "must change password" flow, so ANY password expiry re-breaks phone login (see the forced-change gotcha above). To stop the 42-day domain `MaxPasswordAge` from re-expiring the whole cohort (~2026-08-13), a **Fine-Grained Password Policy `PSO-Caregivers`** was created on CS-SERVER.
 - **Config:** Precedence 10, **`MaxPasswordAge=00:00:00` (never expires)**; every other setting mirrors the Default Domain Policy (Complexity on, MinLength 7, History 24, Lockout 5 / 30 min). `AppliesTo = SG-Caregivers` -- rides the group, so it **auto-covers future hires** and a user removed from the group reverts to the 42-day domain default. **Verified:** `Get-ADUserResultantPasswordPolicy` returns `PSO-Caregivers` (`MaxPasswordAge=00:00:00`) for the cohort. Creating it did NOT change any current password.