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

sync: auto-sync from HOWARD-HOME at 2026-06-30 12:39:43

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-30 12:39:43
This commit is contained in:
Howard Enos
2026-06-30 12:40:12 -07:00
parent bc6dde5b89
commit 5db3a27685
2 changed files with 150 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
clients/cascades-tucson/docs/security/offboarding-2026-06-30-tamra-matthews.md
View File

@@ -24,16 +24,19 @@
| 7 | Remove **O365 Business Standard** license (`f245ecc8…`) | confirmed 0 licenses — **frees 1 seat** |
| 8 | Remove from groups `Sales`, `All Cascades`, `SG-SSPR-Eligible` | HTTP 204 ×3 |
### AutoMapping caveat (delegate auto-attach)
- **Crystal Rodriguez + Ashley Jensen** — added with `AutoMapping:$true`; the shared mailbox
**auto-attaches** in their Outlook.
- **Megan Hiatt + Meredith Kuhn** — `AutoMapping:$true` would not persist via the ComputerGuru
Exchange Operator app: the cmdlet echoed success but the grant rolled back (a failed
`msExchDelegateListLink` write aborts the whole `Add-MailboxPermission` transaction). Re-added with
`AutoMapping:$false`, which **persisted**. They have full access but the box does **not**
auto-attach — one-time manual add in Outlook (File → Open & Export → Other User's Folder, or add
`tamra.matthews@cascadestucson.com` as an additional mailbox), **or** flip auto-mapping from an
interactive EXO PowerShell session later (`Add-MailboxPermission … -AutoMapping $true`).
### AutoMapping — all 4 auto-attach (resolved)
- **All four delegates** (Crystal Rodriguez, Ashley Jensen, Megan Hiatt, Meredith Kuhn) have
**FullAccess with AutoMapping** — the shared mailbox auto-attaches in their Outlook and stays
until they remove it.
- **Gotcha encountered + fix:** the first pass added all 4 in a rapid loop with `AutoMapping:$true`;
only Crystal + Ashley persisted — Megan + Meredith rolled back to NONE (cmdlet echoed success).
Cause: rapid sequential AutoMapping writes contend on the *same* `msExchDelegateListLink` attribute
on Tamra's mailbox; the middle writes lost the race and a failed link-write aborts the whole
`Add-MailboxPermission` transaction. **Fix:** re-grant the missing users **one at a time, spaced
(~6-8s), with verify-and-retry** — `Remove-MailboxPermission` → poll until NONE →
`Add-MailboxPermission -AutoMapping $true` → confirm it persists. Both took on the first spaced
attempt. (The literal `msExchDelegateListLink` list is not exposed in the Exchange Operator REST
schema; persistence of an `AutoMapping:$true` grant is the success signal.)
## Actions completed (on-prem AD, CS-SERVER)
- `Set-ADAccountPassword -Reset` (random, vaulted)
@@ -54,9 +57,8 @@
## Open follow-ups
- [ ] **ALIS staff profile** — confirm whether Tamra had ALIS access; if so, disable the staff record
(audit record stays). Her M365 SSO tie is already severed by the sign-in block.
- [ ] **AutoMapping for Megan Hiatt + Meredith Kuhn** — either they add the shared mailbox manually,
or flip `-AutoMapping $true` from an interactive EXO session (the app-based REST path won't
persist it for these two). Crystal + Ashley already auto-attach.
- [x] ~~AutoMapping for Megan Hiatt + Meredith Kuhn~~ — **RESOLVED 2026-06-30**: re-granted one at a
time (spaced) so AutoMapping persisted. All 4 now auto-attach.
- [ ] **Reconcile** Tamra out of forward-looking plans/rosters. Share roster
`docs/migration/share-group-roster-proposed-2026-06-25.md` already shows her struck-through
*(leaving)*; `docs/servers/active-directory.md` OU=Marketing row updated to disabled +