Files

Howard Enos b6eb59e8ed Session work 2026-05-04: Grabb Leap calendar fix, Dataforth lobby phone VLAN, IMC printer + VPN

- Grabb & Durando: investigated and resolved Svetlana Larionova's Leap-to-M365 calendar OAuth consent issue (Graph-side report + session log). Syncro #32245.
- Dataforth: lobby phone (ext 201) was offline due to D1-Server-Room port 1 being on the wrong VLAN; reconfigured to VLAN 100, phone re-provisioned and registered. Session log + PROJECT_STATE update. Syncro #32246.
- Instrumental Music Center: Station 2 receipt printer reconnect + VPN install on Manda's machine. Syncro #32247.
- Memory: generalized the Syncro blank-contact rule (was Cascades-only) and added the labor-type rule (never use "Prepaid project labor") per Winter's 2026-05-04 corrections.
- Gitignored `.claude/tmp/` so per-session helper scripts don't sneak in.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-04 13:51:59 -07:00

5.1 KiB

Raw Permalink Blame History

Grabb & Durando — Leap M365 Calendar Sync + Teams + Monitor

Date (UTC): 2026-05-04 Tech: Howard Enos User helped: Svetlana Larionova (slarionova@grabblaw.com) Tenant: grabblaw.com (032b383e-96e4-491b-880d-3fd3295672c3)

User

User: Howard Enos (howard)
Machine: Howard-Home
Role: tech

Summary

Multiple support items for Svetlana at Grabb & Durando in one session: got Leap's M365 calendar sync working for her account (admin-consent + token-rebind cleanup), added a second monitor to her workstation, and resolved a Teams file-send issue.

1. Leap M365 calendar sync — root cause and fix

Problem

Svetlana could not add calendar events from Leap to M365. Leap displayed "no admin permissions" during the connect-to-M365 flow.

Root cause

The error message is misleading — it's an OAuth consent block, not an RBAC issue. Leap's user-facing app (appId a7d19842-33e2-457b-a399-d4e6ec010f0a, registered in tenant as service principal 7dd62220-081d-4c6b-8184-dc3187e81578) requests scopes including Mail.ReadWrite, Mail.Send, Files.ReadWrite.All along with Calendars.ReadWrite. The grabblaw.com tenant's user-consent policy (microsoft-user-default-recommended + microsoft-user-default-allow-consent-apps) classifies those as high-risk and blocks user-level self-consent. New users have to be admin-approved for Leap to connect — at the time of investigation, five other users (jsosa, rpesqueira, avazquez, jwilliams, yheredia) already had per-user Principal grants from a prior approval round; Svetlana didn't because she was onboarded later.

Investigation

Used the ComputerGuru Security Investigator (Graph read-only) app to:

Pull Svetlana's user record — confirmed accountEnabled=true, license O365_BUSINESS_PREMIUM, no admin roles, no group memberships beyond the company DL.
Enumerate the LEAP service principals — found two: a daemon/app-only app (5602fc50…, has Calendars.ReadWrite Application permission) and the user-facing delegated app (a7d19842…, requires per-user delegated consent).
Confirm the 5 working users had Principal-type OAuth grants on the delegated app and 4 of them had no admin roles. Conclusion: she did not need an admin role — just admin approval for the Leap app for her account.

Full investigation report: clients/grabb-durando/reports/2026-05-04-leap-calendar-permission-investigation.md.

Fix

Mike granted tenant-wide consent (consentType=AllPrincipals) on the LEAP delegated app at 16:26 UTC via sysadmin@grabblaw.com. Verified via oauth2PermissionGrants endpoint — grant count on LEAP2 went from 5 (per-user Principals) → 6 (5 Principals + 1 AllPrincipals).

This is broader than my original recommendation (per-user via Admin Consent Request), but it has a useful side-effect: any future new hire at Grabb & Durando won't hit the consent block — Leap will just work.

Second issue — Leap bound to sysadmin's identity

After consent, Leap stopped asking for admin permission but threw "unable to subscribe to notifications. leap cannot complete this action" instead. On further inspection, Leap was syncing sysadmin's mailbox/calendar instead of Svetlana's — because when Mike signed in to Leap on Svetlana's PC to grant consent, Leap stored sysadmin's user token as the calendar identity.

Resolution steps Howard performed

Ran Leap repair (leap.us) — did not fully fix.
Revoked the M365 OAuth grant for Leap on sysadmin's account.
Deleted the Leap Outlook integration cache from %LOCALAPPDATA%\Microsoft Corporation\ on Svetlana's PC.
Re-enabled the M365 connection in Leap, signing in as Svetlana.
Calendar sync now works against Svetlana's mailbox.

Going forward

For future new hires at Grabb & Durando, do NOT have an admin sign in to Leap on the user's machine to grant consent — the admin's identity gets bound to that Leap install. Either:

Have the user run the connect flow themselves (tenant-wide consent now exists, so they should sail through), OR
If broader consent is ever needed, grant it via the Entra portal admin-consent flow, not by signing in to the third-party app.

2. Teams not sending files — "outside of their domain"

Svetlana was getting blocked sending files in Teams. Root cause: the recipient was outside the grabblaw.com domain. Teams correctly enforces the firm's external-collaboration policy; this isn't a bug. Walked through the limitation with her so she knows when to use email/secure-share for external recipients vs. Teams for internal.

(No tenant-side change needed — this is policy working as intended.)

3. Second monitor

Added a second monitor to her workstation. Plug-and-play; configured display arrangement.

Tools / accounts touched

ComputerGuru Security Investigator (Graph read-only) — investigation only
sysadmin@grabblaw.com — granted tenant-wide consent for LEAP delegated app
Svetlana's PC — Leap repair, deleted %LOCALAPPDATA%\Microsoft Corporation\ Leap cache, re-signed in to Leap

Follow-up

Syncro ticket to create + bill (this session).
No further M365 / Leap work needed unless calendar sync regresses.

5.1 KiB Raw Permalink Blame History