claudetools/.claude/messages/for-mike.md

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:

# 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.