Who this is for
MSPs and IT providers who deploy the same vendor Outlook add-in (phishing-report buttons, security tooling, productivity add-ins) across many client Microsoft 365 tenants — and need every tenant to end in the same verified state, with paperwork to prove it.
What's inside
- Two deployment routes, and when each fails. The M365 admin portal (Integrated apps) route and the Exchange Online PowerShell route — including the EXO route that works when the portal deploy stalls at the final step despite clean diagnostics.
- The DefaultStateForUser trap. Why a PowerShell-installed add-in can sit disabled per-user even when the install "succeeded," the one setting that fixes it, and why PS-installed add-ins don't appear in Integrated apps (and what that means for updates and removal).
- Tenant authorization / admin consent. The mandatory separate authorization step most deploy guides bury: account consent vs. tenant consent, the popup-block workaround (navigate the main window directly to the consent URL), and why authorization popups can surface scoped to the wrong tenant.
- Tenant-identity verification. Confirm the actual tenant from the connection itself before every change — Microsoft caches sessions, and the tab label lies.
- Post-deploy verification. Org app state (Enabled / ProvidedTo / DefaultStateForUser), capturing the Entra consent app and its exact permission set for the client security file, the live-test submission, and the ~24-hour button-propagation note for client communications.
- End-user launch notice template. A generic one-pager you can adapt per client so users know what the new button is before it appears.
Format
PDF playbook (~15–20 pages) with copy-paste PowerShell snippets and a per-tenant verification checklist you can attach to the ticket as evidence.