# Note for Mike

Check this file at sync. Delete items after you've addressed them.

---

## From Howard, 2026-04-22 — Per-user Syncro keys (attribution fix)

I hit the issue that my Syncro comments/line items on ticket #32179 were getting logged as you (user_id 1735) because we share your API key. Fixed it with per-user tokens:

- Generated my own Syncro API token (Custom, admin, indefinite) → `user_id 1750`
- Added vault entry: `msp-tools/syncro-howard.sops.yaml`
- Patched `.claude/commands/syncro.md` to pick the key from `identity.json`'s `user` field, falls back to the shared `msp-tools/syncro.sops.yaml` if no per-user file exists
- Verified `/me` now returns Howard Enos on my machine

**When you get a chance** (after Valleywide settles), do the same for yourself so the shared key can be retired:

1. Syncro → Admin → API Tokens → New (integration or custom, full scopes)
2. `cat > $VAULT_ROOT/msp-tools/syncro-mike.sops.yaml <<YAML ... YAML` (template in the patched syncro.md)
3. `cd $VAULT_ROOT && sops --encrypt --in-place msp-tools/syncro-mike.sops.yaml`
4. Commit + push vault. The skill will pick it up automatically on your next sync.

After your key is in place we can delete `msp-tools/syncro.sops.yaml` (shared). Until then the skill warns on stderr when it falls back to the shared key.

---

## From Howard, 2026-04-22 — Ack: intune-manager + rates

Pulled vault (got `ebdd711` + `1c837ba`). intune-manager vault file loads fine now. Tried a token against grabblaw.com — returns `AADSTS700016` (app not consented in that tenant). Same category as the `defender` case, tenant-onboarding work, not a code bug. No action needed from you.

Rates reply on Syncro — understood, will omit `price_retail` going forward. Saw the syncro.md update.

Good luck with Valleywide — saw the NVRAM corruption log. Holler if you need a hand with anything from here.

---

## From Howard, 2026-04-22 — Intune Manager app is single-tenant (correction to earlier ack)

**TL;DR:** `ComputerGuru - Intune Manager` (`46986910-aa47-4e5e-b596-f65c6b485abb`) was registered with `signInAudience: AzureADMyOrg`. No external tenant can consent it. Needs a one-field PATCH to `AzureADMultipleOrgs`. Every other MSP app is already multi-tenant.

**Evidence** (pulled today via Management app):

```
AzureADMultipleOrgs  Security Investigator
AzureADMultipleOrgs  Exchange Operator
AzureADMultipleOrgs  User Manager
AzureADMultipleOrgs  Tenant Admin
AzureADMultipleOrgs  Defender Add-on
AzureADMyOrg         Intune Manager   <-- the odd one
```

**Correcting my earlier ack above:** I chalked the grabblaw `AADSTS700016` up to "app not consented in that tenant — same category as defender." That diagnosis was wrong. `700016` at the `/adminconsent` endpoint itself (not just at the token endpoint) means the app is invisible to the external tenant's directory — i.e., the audience blocks it before any consent UI even loads. Verified today against Cascades (207fa277-e9d8-4eb7-ada1-1064d2221498) with `admin@cascadestucson.com` — same 700016 straight from the sign-in screen.

**Current impact:** I'm blocked on Cascades MDM phone setup. Can't get a read on what Intune policies/configs/apps already exist on their tenant without this app working. Falling back to portal clicks with Howard, but that's slower and leaves us with no scripted state checks going forward.

**Fix** — one PATCH call against the app object in your home tenant:

```bash
# Via Management app token (you already have this pattern in patch-tenant-admin-manifest.sh)
curl -X PATCH -H "Authorization: Bearer $MGMT_TOKEN" \
  -H "Content-Type: application/json" \
  "https://graph.microsoft.com/v1.0/applications/31017446-c01a-4775-864f-aef96ce43797" \
  -d '{"signInAudience": "AzureADMultipleOrgs"}'
```

Or in the portal: Entra → App registrations → ComputerGuru - Intune Manager → Authentication → **Supported account types** → pick "Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant)" → Save.

**Why I'm not doing it myself:** Howard said no changes to your apps without you in the loop ("it was working and now its not, i dont want to make a bunch of changes"). Ball's in your court — takes ~30 seconds.

**After you flip it, I'll:**
1. Re-click the consent URL with Cascades GA, create the SP + grant scopes
2. Run the Intune readout against Cascades
3. Continue Phase B MDM work with Howard

**Possibly related followups** while you're in there:
- `onboard-tenant.sh` still only auto-consents the original 5 apps. Needs `intune-manager` added so future tenants onboard cleanly.
- `references/tenants.md` consent URL section doesn't have an Intune Manager template yet.
- `SKILL.md` tier table lists 6 tiers, actual is 7.

All three are documentation/script updates, happy to do those myself once the audience is flipped. Let me know.