Claude Cowork vs Copilot Cowork: why the Microsoft answer wins for SMB

I’ve watched a lot of clients spend the last twelve months stitching together AI tools that don’t talk to each other. A Claude tab here. A ChatGPT tab there. A Copilot tab somewhere in the middle. Then a folder of CSVs they keep dragging in and out of each one.

That’s not a workflow. That’s a tax.

So when Anthropic shipped Claude Cowork and Microsoft shipped Copilot Cowork in roughly the same window, the question landed in my inbox: which one do we tell our clients to use?

I’ll save you the suspense. For an SMB already paying for Microsoft 365, it’s not close.

What is Cowork, really?

Cowork is the bit that does the work, not the bit that talks about it. You give it an outcome — “draft the quarterly update from these meeting notes and send it to the leadership team” — and it goes off and does the thing.

That’s the shared idea. Both products own it. The split is in where the work happens.

Claude Cowork lives on your desktop. You mount a folder, drop your files in, and Claude runs in a sandbox on your machine. It doesn’t see your inbox. It doesn’t see your calendar. It doesn’t see your Teams chats unless you’ve copy-pasted them in. You bring the data to the model.

Copilot Cowork is the inverse. It already lives inside Microsoft 365, grounded in your Outlook, Teams, SharePoint, OneDrive, and calendar through Work IQ. You don’t mount anything. The model is already where your data lives.

Notice what’s missing? The mounting step. The “let me copy this folder over” step. The “hang on, I need to paste in the email thread” step.

For SMBs, that’s the whole game.

Step-by-Step: getting Copilot Cowork going

If you’re licensed for Microsoft 365 Copilot and enrolled in the Frontier preview, the start is short.

Open Cowork in Microsoft 365

Browse to m365.cloud.microsoft, sign in, and pick Cowork from the agent list. If you don’t see it, check Frontier enrolment under Copilot settings.

Describe the outcome

Skip the prompt-engineering nonsense. Talk like a person.

Read my inbox from this week, find anything tagged from a client,
draft a Friday wrap-up email summarising open items, and post a
short version into the Operations channel in Teams.

Notice what’s missing? Any reference to a file path. Any “first export your inbox to CSV” step. Cowork already has the inbox, the calendar, the Teams channels, and the SharePoint files. It just needs the instruction.

Approve the action

Cowork shows you exactly what it’s about to send, post, or schedule before it does it. You hit Send, Post, or Cancel. The full flow is in the getting started doc if you want to walk a client through it.

Set the schedule

Want it to do this every Friday at 4pm? Schedule the prompt and walk away. Copilot doesn’t get tired. Use that.

Why this actually changes behaviour

Claude Cowork is a beautifully built tool. For a developer or a data analyst on a Mac with a folder full of CSVs, it sings. I’m not knocking it.

But that’s not the SMB picture. The SMB picture is a bookkeeper, a sales lead and a director who all live inside Outlook and Teams from 8am to 6pm. Their data isn’t in a folder on their desktop. It’s in their mailbox, their channel chats, their SharePoint sites and their meeting transcripts.

“But couldn’t we just pipe our M365 data into Claude?”

You could. You’d be paying twice — once for M365, once for Claude — and you’d be exporting business data into a different vendor’s environment to do work the platform you already own can do natively.

That’s not a productivity gain. That’s a procurement problem.

Here’s the real win. Copilot Cowork sits behind the same Entra identity, the same conditional access, the same Purview labels and the same retention policies your tenant already runs. The governance story is already built. There’s no second tool to license, secure, train, or audit.

My recommendation? If you’re an MSP and you’re not walking your SMB clients through Copilot Cowork, you’re leaving value on the table — theirs and yours.

Meet people where they already are.

Cowork isn’t a second AI app for your clients to learn. It’s the work, finally getting done in the place it was always supposed to happen.

Entra ID backup just turned up in your Business Premium tenant

A few weeks ago I logged into a Business Premium tenant to do something completely unrelated and noticed a new node in the Entra portal: Backup and Recovery. No upsell banner, no add-on prompt, no “contact your reseller”. Just there. Sitting under Identity governance like it had always been part of the furniture.

That’s the bit worth pausing on. Microsoft has quietly turned identity backup into table stakes for every BP tenant. Notice what’s missing? An invoice.

For years the conversation around protecting your directory has been someone else’s product pitch. Third-party backup vendors built entire businesses on the fact that Microsoft wouldn’t restore a Conditional Access policy you nuked at 4pm on a Friday. Now Microsoft is restoring it for you.

What is Entra Backup and Recovery, really?

It’s a daily snapshot of the configuration that runs your tenant’s identity. Users, groups, applications, service principals, Conditional Access policies, named locations, the authentication methods policy — the things that, when they go missing, take down sign-in for your whole client base.

Five days of retention. Tamper-resistant. No global admin can switch it off, no compromised account can wipe the safety net before the bad thing happens. That’s not a feature. That’s governance.

Important caveats so you don’t sell something that isn’t there. Hard-deleted objects are gone — the recycle bin still does its 30-day job for users and groups, but Backup is for configuration recovery, not undeleting things. Hybrid identity synced from on-premises AD has limitations. Workforce tenants only — not B2C or External ID. And it’s currently in Public Preview, so treat it like one. The official overview is worth a read before you stand in front of a client.

A daily snapshot you can’t disable is more honest than a backup product you forget to renew.

Step-by-Step: turning it on for a Business Premium tenant

1. Sign into the Entra admin centre

Use a Global Administrator account. Navigate to Identity governance → Backup and Recovery. If the node isn’t there yet, give the tenant a day — rollout is staged.

2. Enable the service

It’s a single switch. Once enabled, the first snapshot is captured within 24 hours. There’s nothing to license — Business Premium already includes Entra ID P1, which is the bar.

3. Assign the right roles

There are two purpose-built ones: Microsoft Entra Backup Reader and Microsoft Entra Backup Administrator. Don’t hand recovery rights to every Global Admin out of habit. Restoring a Conditional Access policy from a five-day-old snapshot is exactly the sort of move you want logged against a named, scoped role.

4. Run a Difference Report before you restore anything

This is the part that earns its keep. Before recovering an object, the portal shows you what will change — what’s in the snapshot, what’s live, and where they disagree. You see the diff before you click. The supported objects and limitations(opens in new window) page tells you exactly what’s in scope.

Why this actually changes behaviour

Here’s the real win. The reason MSPs have been selling backup-for-Entra add-ons is fear — what if? That conversation gets harder when Microsoft has put a tamper-resistant safety net in the box.

My recommendation? Stop selling fear. Start showing governance. Walk your BP clients through their backup status, the role separation, and the recovery flow for applications and service principals. It takes ten minutes and it positions you as the person who knew this was already there, not the person trying to bolt something on top.

That’s not a product conversation. That’s an advisor conversation.

The relief, when you find it, isn’t the relief of buying a safety net. It’s the relief of finding one you didn’t have to install.

Need to Know podcast–Episode 364

A weekly roundup of Microsoft Cloud news with a focus on SMBs. Key topics include Microsoft’s internal testing of an always-on AI assistant, major security threats such as Russian state-sponsored router hijacking and advanced phishing attacks, updates to Microsoft Teams, and a retrospective on SharePoint’s evolution. Robert also discusses the challenges and strategies for adopting AI in business, emphasizing the need for a unified, collaborative approach to AI usage within organizations.

Brought to you by www.ciaopspatron.com

you can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-365-siloed-ai/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

or Spotify:

https://open.spotify.com/show/7ejj00cOuw8977GnnE2lPb

Don’t forget to give the show a rating as well as send me any feedback or suggestions you may have for the show

Resources

CIAOPS Need to Know podcast – CIAOPS – Need to Know podcasts | CIAOPS

X – https://www.twitter.com/directorcia

director@ciaops.com

CIAOPS Blog – CIAOPS – Information about SharePoint, Microsoft 365, Azure, Mobility and Productivity from the Computer Information Agency

Join my Teams shared channel – Join my Teams Shared Channel – CIAOPS

CIAOPS Merch store – CIAOPS

Become a CIAOPS Patron – CIAOPS Patron

CIAOPS Brief – CIA Brief – CIAOPS

CIAOPS Labs – CIAOPS Labs – The Special Activities Division of the CIAOPS

Support CIAOPS – Support CIAOPS

Get your M365 questions answered via email

Join the CIAOPS Email list – Please fill out this form

A special thanks to the CIAOPS Patron community for making this podcast possible. You can find the benefits of a subscription to the community and become a member at https://www.ciaopspatron.com

Show notes

Microsoft tests ‘ClawPilot’ AI agent for 3,000 staff

SOHO router compromise leads to DNS hijacking and adversary-in-the-middle attacks

What’s New in Microsoft Teams | April 2026

ClickFix campaign uses fake macOS utilities lures to deliver infostealers

The Future of SharePoint

Breaking the code: Multi-stage ‘code of conduct’ phishing campaign leads to AiTM token compromise

Tuning Safe Links and Safe Attachments in Defender for Office 365 Without Breaking Your Tenant

If you’re running M365 Business Premium for clients, Safe Links and Safe Attachments are already doing work — whether you configured them or not. The Built-in protection preset applies to every mailbox the moment Defender for Office 365 is licensed. The question isn’t “is it on?” — it’s “is it tuned for the way your client actually receives mail?” Out of the box, it’s closer to a safety net than a security control.

Prerequisites MSPs skip

Before you touch a single policy, confirm three things. First, mail has to flow through Exchange Online Protection. Hybrid tenants with a third-party gateway in front (Mimecast, Proofpoint, anything rewriting URLs) will often cause Safe Links to skip wrapping — Microsoft explicitly warns that pre-wrapping can prevent Safe Links from processing the link at all. Second, confirm licensing: Safe Links and Safe Attachments require Defender for Office 365 Plan 1 (included in Business Premium). Plan 2 features (Safe Documents, Threat Explorer real-time detections) need separate entitlement. Third, set quarantine notifications up before you tighten policies — users need end-user spam notifications or a quarantine policy with access enabled, or your service desk gets the entire phishing queue.

Where to configure — Standard preset, not custom, 90% of the time

The Microsoft Defender portal is your canonical surface: security.microsoft.com → Email & collaboration → Policies & rules → Threat policies. From there:

Preset security policies for 90% of clients. Enable Standard, assign to all recipients by domain.
Safe Links and Safe Attachments tiles are for custom policies — only use them when a specific user group needs different behaviour (execs on Strict, a lab OU excluded, etc.).
Configuration analyzer — this is the tile most MSPs never click. It diffs your current policies against Standard and Strict baselines and flags every setting that’s weaker than Microsoft’s recommendation.

Microsoft’s own guidance is explicit: prefer presets over custom policies. See Set up Safe Links policies and Set up Safe Attachments policies.

The rollout pattern that actually works

Don’t flip Strict on Monday morning. Use a three-ring rollout:

Ring 1 — IT and security-aware staff (week 1). Assign Standard preset. Watch quarantine, false-positive submissions, and user complaints. This ring tolerates noise.
Ring 2 — a tolerant business unit (week 2–3). Finance is usually a bad pilot (high-volume invoices with wrapped URLs confuse people). Pick sales ops, marketing, or IT-adjacent teams.
Ring 3 — everyone else (week 4+). By now you have a real signal on which domains need Tenant Allow/Block entries.

For Strict preset, add a fourth ring limited to exec and finance groups — or leave it off. Strict’s aggressive bulk thresholds (BCL 4) will blow up newsletters and marketing workflows. Details at Preset security policies.

Top three pitfalls

1. Custom policies silently overriding presets. Preset security policies have the highest priority except when a custom policy explicitly targets the same user. If you inherited a tenant with a custom Safe Links policy from 2019 that says AllowClickThrough = true, it beats your shiny new Standard preset. Audit first: open every existing policy before assigning presets.

2. Over-allowlisting domains. Every entry in “Do not rewrite the following URLs” is a permanent click-through exception. Treat it like firewall rules — justify, document, review annually. A forgotten *.sharepointdomain.com wildcard is how payloads land.

3. Ignoring the Configuration analyzer. Run it quarterly. Tenants drift: an admin raises a threshold to silence a complaint, nobody reverses it, six months later the baseline is gone. The Configuration analyzer surfaces this in one screen.

Tune deliberately, measure through Threat Explorer, and treat preset policies as your default — the time to build a custom policy is when you can describe exactly which preset setting it’s overriding and why.

A Great Product Scales. A Great System Scales. But Leaders Multiply.

Most MSPs I talk to are chasing scale.

More endpoints. More seats. More tools. More revenue per engineer.

And that makes sense—up to a point.

But here’s the uncomfortable truth: products scale. Systems scale. Dashboards scale. Yet the thing that actually determines whether an MSP breaks through the next ceiling isn’t any of those.

It’s leadership.

In particular, whether you’re multiplying your people—or slowly becoming the bottleneck without realising it.

The Hidden Scaling Problem in Many MSPs

I see this pattern constantly.

The MSP owner is sharp. Knows the stack inside out. Answers client questions quickly. Fixes problems fast. Reviews every proposal. Tweaks every process.

On the surface, it looks like control. Underneath, it’s fragile.

Because when knowledge, judgement, and decision‑making live in one or two heads, the business doesn’t really scale—it stretches. And stretched systems eventually snap.

This is where Microsoft 365 Copilot genuinely changes the conversation—not because it “does AI”, but because it shifts who can think, decide, and act with confidence.

Copilot Isn’t About Speed. It’s About Trust.

When I work with MSP teams implementing Copilot properly, the biggest change isn’t faster emails or prettier documents.

It’s trust.

A junior engineer can review a complex email thread and ask Copilot to summarise what actually matters—before responding to a client.

A service manager can draft options for a tricky renewal conversation without escalating every time.

An account manager can walk into a QBR already across usage, risks, and open issues—without waiting for someone else to spoon‑feed them.

That’s not automation. That’s capability transfer.

Instead of leaders being the thinking engine for the business, Copilot becomes a quiet amplifier that helps the team think better on their own.

Systems Scale. Leaders Multiply.

Here’s the distinction I think too many MSPs miss.

Systems help people follow rules. Leaders help people exercise judgement.

Copilot sits squarely in the second category—if you use it intentionally.

I’ve seen MSPs roll it out as “another tool” and get negligible value. Everyone plays with prompts for a week, then goes back to old habits.

The MSPs getting real results are doing something different: they’re pouring into their people.

They’re teaching staff how to reason through problems using Copilot as a second brain. How to sanity‑check assumptions. How to prepare before asking for help instead of defaulting to escalation.

That’s leadership multiplication.

And it compounds faster than any new tool rollout ever will.

What This Means for MSP Owners

If you’re serious about scaling, the question isn’t “Have we deployed Copilot?”

It’s:

Are my people making better decisions without me?
Are conversations getting clearer, not noisier?
Are we reducing dependency on tribal knowledge?

Copilot won’t fix weak leadership. But in the hands of leaders who invest time, context, and expectation into their teams, it accelerates growth in ways traditional systems never could.

The Return Might Surprise You

Here’s what tends to happen when MSP leaders commit to developing people—not just installing tools.

Fewer interruptions. Faster client responses without panic. Better internal conversations. More confidence across the business.

And eventually, something even more valuable: space.

Space to think strategically instead of reactively. Space to focus on the business instead of being trapped inside it.

So yes—great products scale. Great systems scale.

But if you want an MSP that genuinely grows without breaking, keep pouring into your team.

That return doesn’t just surprise you.

It changes everything.

Shipping Intune App Protection Policies for BYOD: What Actually Works in Production

App Protection Policies (APP, sometimes called MAM) are the single highest-ROI control in Business Premium for BYOD. You get corporate data containerisation on an unenrolled iPhone or Android device in about an afternoon — if you avoid the usual landmines. Here’s the pattern I ship to MSP clients.

Prerequisites people miss

APP only protects apps that implement the Intune App SDK (Outlook, Teams, Word, Edge, OneDrive, etc.). That’s most of M365, but not every third-party app the user loves. Before you touch a policy:

Every targeted user must have an Intune Plan 1 licence (bundled in Business Premium and the E3/E5 stack).
Company Portal must be installed on Android. iOS doesn’t strictly need it for MAM-WE (without enrolment), but Authenticator is required for sign-in brokering.
For Android, you need the Play Integrity verdict configured if you plan to block rooted devices — and Play Store access, which rules out many China-market devices.
Decide now whether you’ll pair APP with a Conditional Access grant of Require app protection policy. If yes, your CA policy needs to exclude break-glass accounts and any service accounts that hit Graph from mobile.

See the App protection policies overview for the full support matrix.

Where to configure

Everything lives in the Microsoft Intune admin center at intune.microsoft.com:

Apps → App protection policies → Create policy → pick iOS/iPadOS or Android. You create one policy per platform.
Target apps: start with “Selected apps” and pick the core Microsoft apps. Do not start with “All Microsoft Apps” — you’ll regret it the first time Teams Rooms or a hybrid meeting app trips the policy.
Data protection settings: align with Microsoft’s Level 2 enterprise enhanced framework as your default. Level 1 is too loose for anyone storing client data; Level 3 breaks copy/paste workflows most SMBs rely on.
Access requirements: PIN of 6 digits, biometric allowed, 30-minute offline grace.
Conditional launch: jailbreak/root = Block access, min OS version = current−1, max PIN attempts = 5 → Wipe data. Full reference at Conditional launch actions.

The rollout pattern that actually works

Three rings, two weeks each, no exceptions:

Ring 0 — IT and champions (5–10 users). Assign to a dynamic security group. Set Conditional launch actions to Warn, not Block. Let it bake. You are looking for app conflicts, not policy correctness.
Ring 1 — Pilot department (25–50 users). Flip conditional launch to Block. Enable CA “require app protection policy” in report-only mode. Watch sign-in logs for a week — you will find the one user still using the native iOS Mail app.
Ring 2 — Everyone. Move CA to On. Decommission any “allow legacy auth” exceptions at the same time — clients will push back, hold the line.

Use assignment filters (not separate groups) to carve out corporate-owned devices from BYOD rules. It scales; groups don’t.

The three pitfalls that bite

1. Policy conflicts silently pick the most restrictive value. If a user is in two groups with different PIN lengths, they get the longer one — and no error surfaces. Run one policy per platform per persona. Document which group wins.

2. Selective wipe isn’t device wipe. Apps → App selective wipe removes corporate data from managed apps only — photos, personal iMessages, the user’s Spotify library all stay. Train your service desk to say this out loud when an employee leaves. Also: the wipe only fires the next time the user opens the app, and can take 30 minutes.

3. Conditional launch “Min OS version” will brick users overnight. When Apple ships iOS 19 and you’ve set “Min OS version = 18”, a user on 17 walks in on Monday and can’t open Outlook. Always pair Min OS version with a Warn action first, run it for a fortnight, then escalate to Block.

Get these three right and APP is genuinely boring — which, for mobile security, is exactly what you want.

Self-Service Password Reset with writeback: the rollout that doesn’t burn your helpdesk

SSPR is a box most MSPs tick on day one of a Business Premium tenant and then never look at again. That’s fine until a hybrid customer calls because Karen changed her password on My Sign-Ins, logged into her domain-joined laptop, and got rejected. SSPR without writeback is half a feature. Here’s how to deploy the whole thing properly.

Prerequisites people miss

The obvious ones — an Entra ID P1 license (included in Business Premium) and either Entra Connect Sync or Entra Connect Cloud Sync — aren’t where rollouts die. The misses are:

On-prem AD permissions for the sync account. The account running Connect (or the Cloud Sync provisioning agent) needs Reset password, Change password, Write lockoutTime, and Write pwdLastSet on the user OUs. The Connect wizard grants these if you let it; locked-down AD environments often don’t. Writeback fails silently if these are missing.
A matching on-prem password policy. Entra enforces its own complexity rules. If your on-prem policy is stricter (minimum length, history, banned words), a user’s new cloud password will be rejected by AD when it writes back, and the user will see a generic error. Align them before you enable, not after.
Combined registration actually enabled and enforced. Legacy SSPR-only registration still exists in old tenants. If users register methods for MFA but not SSPR, the reset flow blocks them.

See Microsoft’s writeback concept doc for the full supported-operations list: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-writeback(opens in new window).

Where to configure it

Everything is in the Entra admin centre — no PowerShell required for a standard deploy.

Protection → Password reset → Properties to scope SSPR to a pilot group, then all users.
Protection → Password reset → Authentication methods to require two methods and pick which ones (drop SMS, keep Authenticator + email, add Questions only if you must).
Protection → Password reset → On-premises integration to flip writeback on. If you’re using Cloud Sync, enable it in the provisioning agent config per the tutorial: https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-cloud-sync-sspr-writeback(opens in new window).
Protection → Authentication methods → Registration campaign to nudge users into combined registration: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-registration-mfa-sspr-combined(opens in new window).

The rollout pattern that works

Don’t flip it on tenant-wide. The pattern that doesn’t generate tickets:

Pilot group of ~10 — IT plus two friendly business users. Scope SSPR to that group only. Verify a reset from My Sign-Ins actually lands in AD (pwdLastSet on the DC is your proof).
Registration campaign to the pilot for 14 days. Force them through combined registration. Watch the Registration report for stragglers.
Broaden by department, not by “All users.” Finance first, then ops, then field staff. Each wave gets the campaign a week before the SSPR scope flips.
Protect the registration step with Conditional Access. Use Register security information as the user action and require MFA (or a Temporary Access Pass for new starters): https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration(opens in new window). Without this, an attacker who phishes a password can register their own MFA method and own the account.

Top pitfalls

Admins can’t use SSPR the same way users can. Privileged roles are locked to strong methods and can’t rely on Security Questions. Test with an admin-tier account before you cut over — and keep a break-glass account that is explicitly excluded from the CA registration policy.
Writeback “works” but the user still can’t log in. Nine times out of ten this is cached credentials on a domain-joined laptop that hasn’t seen a DC since the reset. Tell the user to connect to the corporate network or VPN and lock/unlock. Bake this into your helpdesk script.
Cloud Sync vs Connect Sync confusion. You can run them side-by-side, but writeback must be enabled on whichever one syncs that user’s domain. Audit first — we’ve seen tenants with both running where writeback was enabled on the wrong one and nobody noticed until a reset failed.

Enable it properly once, and SSPR moves from a compliance checkbox to a real helpdesk-deflection tool.

A Cleaner Way to Connect PowerShell to Exchange Online

If you still rely on Connect-ExchangeOnline with a username, password, and an MFA prompt, you already know the pain. Scripts break overnight. Scheduled tasks fail when a token expires. Service accounts get flagged by conditional access. And the moment someone enables MFA on the admin account you’ve been quietly using, your automation falls over.

I’ve been written a new script —

https://github.com/directorcia/Office365/blob/master/o365-connect-exo-cert.ps1

with full documentation here:

https://github.com/directorcia/Office365/wiki/Connect-to-Exchange-Online-with-Certificates

— that swaps all of that for certificate-based app authentication. There’s nothing exotic about the underlying approach; Microsoft has supported it for years. What’s been missing is a clean, one-shot way to set it up without spending an afternoon clicking through the Entra portal. That’s what this script gives me, and I think it earns its place in any MSP’s toolkit.

What the Script Actually Does

There are two modes, controlled by switches.

-GenerateLocalCertificate creates a self-signed RSA-2048 certificate in your current user’s certificate store, exports the public key as a .cer file, and optionally exports a password-protected .pfx. By default it’s valid for two years. That’s the local side of the handshake.

-UseCertificateAuth is the everyday mode. You tell it which tenant to connect to — or let it look up the details in a profile map file — and it signs into Exchange Online using that certificate. No password. No browser. No MFA dialog.

The clever bit is the third option: combining -GenerateLocalCertificate with -ProvisionEntraApp -Tenant 'contoso.onmicrosoft.com'. In a single run, the script will generate the local certificate, authenticate to Microsoft Graph via a device-code flow, create the Entra ID app registration if it doesn’t exist, upload the certificate, grant Exchange.ManageAsApp and Application.Read.All with admin consent, create the matching service principal, sign you into Exchange Online to add the app to the Organization Management role group, and save the tenant, app ID, and certificate thumbprint to a JSON profile file so future connections don’t need any of those parameters.

That’s a job that normally takes twenty minutes of clicking, copying GUIDs, and second-guessing whether the right role got assigned. The script does it in about ninety seconds.

Getting Started

If you’re new to certificate auth, the first run is the one that matters. Drop the script onto an admin machine, open PowerShell, and run:

.\o365-connect-exo-cert.ps1 -GenerateLocalCertificate -ProvisionEntraApp -Tenant 'yourtenant.onmicrosoft.com'

You’ll be prompted to sign in twice — once via device code for the Graph permissions (which if you use the –copydevicecodetoclipboard, option will put the required device code straight into the clipboard to paste into the request), then again with Connect-ExchangeOnline so the script can add the app to the role group. Both need a Global Admin account. After that, every future run is just:

.\o365-connect-exo-cert.ps1 -UseCertificateAuth -Tenant 'yourtenant.onmicrosoft.com'

No prompts. No browser. The script reads the tenant, app ID, and thumbprint from o365-exo-cert-auth.json (saved to parent directory), finds the certificate in your local store, builds a signed JWT, and you’re in. One caveat worth flagging: when you’ve just provisioned a brand-new app, give it fifteen to thirty minutes for role assignments to replicate before you try to connect. The script warns about this in its output, but it’s the single most common reason a fresh setup looks broken when it isn’t.

If you’re managing more than one tenant, the profile file is where this really earns its keep. Each provisioning run appends or updates an entry, so you can ask for a connection by -ProfileName, -Tenant, or -Organization and the script picks the right credentials. When several profiles match, it lists them and lets you choose.

Why Certificates Beat Passwords

The security argument is the easy one. A certificate’s private key never leaves the machine that generated it. Nothing crosses the wire that an attacker could intercept and replay. There’s no shared secret to rotate across a team, no admin password sitting in a vault that someone might extract, and no MFA bypass to engineer because the flow doesn’t involve a user account at all.

Permissions are scoped too. The app holds only Exchange.ManageAsApp and read-only access to application metadata. If the certificate is ever compromised, you remove the key credential from the app registration and the access is gone — no password reset required, no impact on any human admin account.

The script enforces TLS 1.2, refuses to assign RBAC if the EXO session has landed in the wrong tenant, warns when the certificate is within thirty days of expiry, and keeps the device-code value off the clipboard by default to avoid leaks on RDP or shared sessions. Small things, but they add up.

Why It’s a Win for Automation

Certificate auth is what makes unattended Exchange Online work actually unattended. A scheduled task running at 2 a.m. doesn’t have a human to click “Approve” on an MFA prompt. With this approach, you point Task Scheduler at the script with -noprompt, pass the tenant, and walk away.

For an MSP, that becomes a per-tenant capability rather than a per-admin one. One profile file, one shared script, separate certificates per tenant or per admin machine — and now mailbox audits, distribution group cleanup, shared mailbox provisioning, and any of the other recurring chores you keep meaning to automate can run on a timer instead of waiting for a quiet Friday afternoon. Pair it with a Power Automate flow or a daily Copilot summary in Teams, and you’ve got reporting that lands in front of the right people without anyone signing in.

Where I’d Take It Next

If you’ve never moved off interactive sign-in for Exchange Online, this is the path I’d take. Spend half an hour standing it up against a test tenant. Get comfortable with the profile file. Then start moving your scheduled work over, one job at a time. The shift from “who’s signing in?” to “which certificate is presenting itself?” is a quiet one, but once your automation stops breaking every time an admin’s MFA settings change, you won’t go back.