Category: Microsoft 365

CIAOPS AI Dojo 012

image

What’s the session about?

This month we will be focusing on new Copilot features and updates as well as optimising AI for Small Business.

Who should attend?

This session is perfect for:

  • IT administrators and support staff
  • Business owners
  • People looking to get more done with Microsoft 365
  • Anyone looking to automate their daily grind

Save the Date

Date: Friday the 29th of May 2026

Time: 9:30 AM Sydney AU time

Location: Online (link will be provided upon registration)

Cost: $80 per attendee (free for Dojo subscribers)

Register Now

DSPM: The End of Guessing About Your Sensitive Data

image

Most Microsoft 365 tenants I walk into are flying blind on data.

The sensitivity labels exist. A couple of DLP policies exist. Someone once turned on Insider Risk Management because a consultant said so. And then nothing. Nobody knows what’s working, what’s exposed, or which sensitive files are sitting wide open in a SharePoint site shared with half the planet.

That’s not a security posture. That’s a guess.

The tool that finally ends the guessing is Microsoft Purview Data Security Posture Management. If you’ve got E5 or the Purview Suite and you’re not showing this to your clients, you’re leaving value on the table.

What is DSPM, really?

DSPM is the dashboard that tells you, in plain English, where your sensitive data is sitting unprotected and which users are handling it carelessly. It pulls signals from the tools you already pay for — DLP, Information Protection, Insider Risk Management, Adaptive Protection — and stitches them into one view.

The clever bit is the correlation. Before DSPM, you’d open five different blades, cross-reference three different reports, and still miss half of it. Now the findings and recommendations land on one page, with a one-click path to spin up the matching policy.

That’s not a report. That’s a to-do list with context.

Step-by-Step: turning DSPM on

Portal only. Stay in the GUI — easier for you, easier to hand off to the next admin.

Open the Purview portal

Sign in to the Microsoft Purview portal as a member of the Data Security Management role group, an Insider Risk Admin, or a Compliance Administrator. Global Admin works too, but please don’t use it if you can help it.

Open the DSPM solution

From the home page, go to Solutions → Data Security Posture Management → Overview.

Turn on analytics

On the Overview page, click Turn on analytics. That one switch also enables DLP analytics and Insider Risk analytics behind the scenes if they aren’t already on. One click, three switches. The full checklist is in the Get started with DSPM article.

Wait

Yes, really. The automated scan across your tenant can take up to three days on anything larger than a handful of users. Walk away. Brew a coffee. Come back on Thursday.

Review the recommendations

Back on the DSPM dashboard, open Recommendations. Each one tells you what was found, why it matters, and offers a one-click path to create the DLP or Insider Risk policy that fixes it. You don’t start from a blank policy screen anymore — you start from your tenant’s real gaps.

Track trends over time

Use the Analytics and Reports tabs in client reviews. A trend line of risky activity going down beats any invoice justification I’ve ever tried to write.

Why this actually changes behaviour

“Are we protected?”

That’s the question every SMB owner asks. Most of us have been answering with vibes. Good vibes, educated vibes, but vibes.

DSPM changes the answer. You can point at a number. You can point at a recommendation you actioned last month and the unprotected file count that dropped because of it. You can show, not tell.

For MSPs, that’s a QBR slide that sells itself. For internal IT, it’s the evidence you need when the CFO asks what the Microsoft Purview licence is actually doing for the business.

And if Copilot is already in the tenant — which, let’s be honest, it increasingly is — then DSPM for AI is your next stop. Same lens, pointed at what people are pasting into Copilot prompts and what’s flowing back out.

Copilot doesn’t slow down. Neither does your data sprawl. Use something that keeps up.

DSPM isn’t there to create more work. It’s there to stop the guessing.

Autopilot + ESP: The Deployment Pattern That Actually Survives Contact With Real Users

image

If you’re still PXE-booting laptops in the back room in 2026, you owe your techs a better life. Windows Autopilot with a properly configured Enrollment Status Page (ESP) is the MSP deployment pattern that scales — but only if you stop treating ESP as a tick-box and start treating it as the gate that enforces your security posture before the user ever sees a desktop. Here’s the deploy-it-well version.

Prerequisites People Miss

Business Premium gets you the licensing — Entra ID P1, Intune, and Windows 11 Pro/Enterprise entitlements. The bits that actually bite:

  • Automatic MDM enrollment must be on. Entra admin center → Mobility (MDM and WIP) → Microsoft Intune → MDM user scope = All (or a group). Miss this and the device joins Entra but never enrols into Intune, and the ESP just hangs.

  • Hardware hash registration path. For anything beyond a one-off, get the reseller to register devices to your tenant at purchase. Manual CSV uploads at OOBE are fine for a test VM; they’re a tax on your L1 team in production.

  • TPM 2.0 + device attestation are non-negotiable for self-deploying and pre-provisioning scenarios. VMs won’t cut it, and attestation needs outbound HTTPS to vendor-specific endpoints.

  • Cloud-native over hybrid join. Microsoft’s own guidance is explicit: deploy new devices as Entra-joined. If you’re still standing up the Intune Connector for AD in 2026, have a very good reason written down.

Full list: Windows Autopilot requirements.

Where To Configure

Everything lives in the Microsoft Intune admin center. Two paths you’ll wear out:

  • Deployment profile — Devices → Windows → Device onboarding → Enrollment → Windows Autopilot → Deployment Profiles → Create profile → Windows PC. User-driven, Entra-joined, Standard user account type, hide EULA and privacy settings, set a device name template, allow pre-provisioned deployment.

  • ESP profile — Devices → Device onboarding → Enrollment → Windows tab → Enrollment Status Page → Create. Do not edit the default “All users and all devices” profile — create your own and give it a higher priority.

References: Configure Windows Autopilot profiles and Set up the Enrollment Status Page.

The Rollout Pattern That Works

Three rings, same as your update rings. Don’t skip this.

  1. Pilot (IT / internal). Loose ESP — Block device use = No, timeout 90 minutes, log collection on. You want visibility, not gates.

  2. Early adopters. ESP enforced at the device phase only. Block device use = Yes, timeout 60 minutes, custom error message with your service desk number. Turn off the User / Account Setup phase — the overwhelming majority of ESP failures happen there, and device-targeted apps have already installed by that point.

  3. Production. Lock it. Required blocking apps = your EDR (Defender), BitLocker initiation, and one small “canary” Win32 app that proves apps are actually flowing. No more than five blocking apps total.

Assign both profiles to a dynamic device group filtered on (device.devicePhysicalIDs -any _ -contains "[ZTDId]") so Autopilot-registered devices land automatically.

Top Pitfalls

  • Too many blocking apps. Every blocking app is a potential ESP timeout. Keep it to security essentials; let the rest stream in post-desktop via required assignments.

  • User-phase ESP left enabled. User-targeted apps plus Known Folder Move plus OneDrive sync at first login is a timeout factory. Disable the account setup phase unless you have a specific, measured reason to keep it.

  • Dynamic group latency. Group membership can take minutes to evaluate and devices race ahead of policy. Mitigation: move to Autopilot device preparation (enrollment-time grouping) for new greenfield tenants, or accept the ring-one pilot friction as the cost of dynamic groups.

For the broader lifecycle picture, start at Overview of Windows Autopilot.

Deploy it once, deploy it tight, and your zero-touch goes from aspirational to boring — which is exactly what production should be.

Attack Surface Reduction Rules in Microsoft 365 Business Premium: A Practical Deep Dive

image

If you manage Business Premium tenants for SMB clients, Attack Surface Reduction (ASR) rules are arguably the highest-leverage defensive control you’re not fully exploiting. They ship with Defender for Business (included in Business Premium), they cost nothing extra to enable, and they block the precise behaviours that commodity ransomware and living-off-the-land attacks depend on — Office spawning child processes, Win32 API calls from macros, credential theft from LSASS, and PSExec-style lateral movement. This post assumes you already know what ASR is. The goal here is to help L2/L3 engineers deploy it without breaking line-of-business apps.

Prerequisites the documentation underplays

ASR has hard dependencies that silently downgrade rules to “not configured” if missed. Microsoft Defender Antivirus must be the active AV (not passive, not disabled by a third-party product), real-time protection must be on, and cloud-delivered protection must be on — several rules won’t evaluate without cloud lookups. Verify these under Microsoft Defender portal → Endpoints → Configuration management → Device configuration, and confirm the device shows as “Active” in the device inventory. Tamper Protection must also be enabled tenant-wide; without it, local admins or malware can disable ASR in seconds.

Where to configure in Business Premium

Business Premium gives you two supported paths. The simplified experience lives at security.microsoft.com → Device configuration → Next-generation protection / Firewall, but ASR rules specifically are configured through Intune. In the Microsoft Intune admin center, go to Endpoint security → Attack surface reduction and create an “Attack surface reduction rules” profile targeting Windows 10/11. Avoid mixing this with legacy Endpoint Protection templates or Group Policy — conflicting sources result in the classic “last writer wins” behaviour, and you will spend hours chasing phantom rules. If a device is co-managed or has stale GPOs, check Event Viewer → Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational (event IDs 1121, 1122, 5007) to confirm which source applied.

The rollout pattern that works

Do not flip rules straight to Block. The proven pattern is: enable every rule in Audit mode, leave it for two to four weeks, then review the ASR report at security.microsoft.com → Reports → Attack surface reduction rules. Filter by rule and by device, identify the noisy ones, and build per-rule exclusions before switching to Block. Where available, use Warn mode as a staged step — the user gets a toast and can unblock once, which is invaluable for finance teams running macro-heavy spreadsheets. Warn mode is Windows 10 1809+ only; older builds silently treat it as Block.

Start with the “standard protection” set Microsoft recommends: Block credential stealing from LSASS, Block abuse of exploited vulnerable signed drivers, and Block persistence through WMI event subscription. These have the lowest false-positive rate and the highest return. The two rules that most commonly break things are “Block Office applications from creating child processes” (breaks legitimate mail-merge and older add-ins) and “Block executable content from email client and webmail” (breaks zipped installers).

Pitfalls to pre-empt

Exclusions are path-based and case-sensitive on the file name portion — wildcards work on folders, not extensions. Per-rule exclusions (added in later releases) are preferred over global Defender exclusions; use them so you don’t inadvertently hole-punch the whole AV. If a rule appears to do nothing, check whether the device is in EDR block mode and whether Defender is the active AV — ASR is silently disabled under third-party AV. Finally, ASR events do not always surface as alerts; plumb them into your SIEM via the Defender API or Advanced Hunting (DeviceEvents where ActionType startswith "Asr").

References

CIA Brief 20260502

image

Microsoft 365 Copilot & AI Agents

Microsoft 365 Apps & Productivity

Security & Defender

Identity (Microsoft Entra)

Microsoft Sentinel

Exchange Online

Corporate / Earnings

After hours

Starship – Test like you Fly – https://www.youtube.com/watch?v=ANe_HW4X8oc

Editorial

If you found this valuable, the I’d appreciate a ‘like’ or perhaps a donation at https://ko-fi.com/ciaops. This helps me know that people enjoy what I have created and provides resources to allow me to create more content. If you have any feedback or suggestions around this, I’m all ears. You can also find me via email director@ciaops.com and on X (Twitter) at https://www.twitter.com/directorcia.

If you want to be part of a dedicated Microsoft Cloud community with information and interactions daily, then consider becoming a CIAOPS Patron – www.ciaopspatron.com.

Watch out for the next CIA Brief next week

Building Conditional Access That Actually Works: Requiring Intune‑Compliant Devices

image

Requiring Intune‑compliant devices via Conditional Access is one of the most impactful controls available to Microsoft 365 Business Premium tenants. It’s also one of the easiest ways to accidentally break access if you don’t understand how the moving parts fit together.

This article walks through the end‑to‑end mechanics, not just the clicks, so L2/L3 engineers understand why policies behave the way they do.

Architecture: What Happens During Sign‑In

When a user signs into a cloud app (Exchange Online, SharePoint, Teams):

  1. Microsoft Entra ID evaluates applicable Conditional Access policies

  2. If a policy requires a compliant device, Entra queries Intune
  3. Intune returns a binary verdict: Compliant or Not compliant
  4. Access is granted or blocked accordingly

Microsoft explicitly states that Conditional Access relies on Intune compliance state and will not function as intended without an Intune compliance policy in place. [learn.microsoft.com]

This is not a soft dependency — no compliance policy means every device fails the check.

Step 1: Define “Compliant” in Intune (Before Touching Conditional Access)

In the Intune admin centre (intune.microsoft.com):

Devices → Compliance policies → Create

At minimum for Windows endpoints in Business Premium, Microsoft supports compliance checks such as:

  • BitLocker enabled

  • Secure Boot enabled

  • Minimum OS version

  • Antivirus and firewall present

These controls form the inputs to Conditional Access — they do nothing by themselves. [learn.microsoft.com]

Operational tip:
Assign compliance policies to user groups, not devices. Conditional Access evaluates user sign‑ins, not device objects.

Step 2: Create the Conditional Access Policy

In the Microsoft Entra admin centre (entra.microsoft.com):

Protection → Conditional Access → Policies → New policy

Core configuration (baseline):
  • Users
    • Include: Target user group (do not start with All users)

    • Exclude:

      • Emergency access (break‑glass) accounts

      • Service accounts (where applicable)

Microsoft explicitly recommends excluding emergency access accounts to avoid tenant lockout. [learn.microsoft.com]

  • Target resources

    • Start with: Exchange Online or Office 365

    • Expand later to “All cloud apps”

  • Grant

    • ✅ Require device to be marked as compliant

  • Enable

    • ✅ Report‑only (initially)

This exact flow is documented by Microsoft as the supported deployment approach. [learn.microsoft.com]

Step 3: Report‑Only Mode Is Not Optional

Report‑only mode evaluates the policy without enforcing it. This allows you to:

  • Confirm which users would be blocked

  • Identify unmanaged or unenrolled devices

  • Detect users authenticating from unsupported platforms

Microsoft strongly recommends Report‑only mode before enforcement for Conditional Access policies of this type. [learn.microsoft.com]

Validation path:

  • Entra ID → Sign‑in logs

  • Filter: Conditional Access → Report‑only

  • Review failure reasons

Step 4: Common Failure Scenarios (Seen in the Wild)

“User prompted repeatedly for MFA then blocked”
  • Device is Entra ID joined but not enrolled in Intune
  • No compliance policy applies to the user
“macOS or BYOD phones blocked unexpectedly”
  • Platform not covered by a compliance policy

  • Device enrolment incomplete
“Policy works for admins but not staff”
  • Admins often use already‑managed devices

  • Staff devices lag behind in enrolment

Microsoft documents that Conditional Access can only evaluate compliance for MDM‑enrolled devices. [learn.microsoft.com]

Step 5: When Not to Use Compliant‑Only Access

Microsoft explicitly provides alternative templates where compliance is one of several controls, not the only one, such as:

  • Compliant device OR Microsoft Entra hybrid joined OR MFA

This is recommended where full device management is not realistic. [learn.microsoft.com]

Production Roll‑Out Recommendation

For Business Premium tenants, Microsoft’s own Zero Trust guidance aligns to:

  1. Require MFA first

  2. Enrol devices into Intune

  3. Require compliant devices for core workloads

  4. Expand to all cloud apps once stable [learn.microsoft.com]

Official Microsoft References

What’s actually happening inside an Intune App Protection Policy

image

Most MSPs I work with have shipped App Protection Policies (APP) to a client by now. BYOD iPhone, Outlook Mobile, a PIN, a block on copy-paste to personal apps — done, move on. But when the client’s compliance consultant asks how the data is actually protected, or why a specific action blocks on an unenrolled Android, the hand-waving starts. Here’s what’s actually going on under the covers.

The Intune App SDK, not the OS, is doing the work

An App Protection Policy doesn’t manage the device. That’s the whole point of MAM-without-enrolment. Enforcement lives inside the app itself, courtesy of the Intune App SDK that Microsoft has compiled into Outlook, Teams, Word, Excel, OneDrive, and a growing list of line-of-business apps wrapped with the App Wrapping Tool. When the user signs in with their work identity, the SDK phones home to the Intune service, pulls down the policy that applies to that user plus that app, and starts enforcing it in-process.

That’s why policies are scoped to user and app, not device. The OS on an unenrolled phone has no idea this is happening. The app is quietly running a second policy engine beside the operating system — and a separate wipe scope, which is what lets you revoke org data from a personal device without nuking the phone.

The broker is the hinge

On iOS, Microsoft Authenticator acts as the broker. On Android, it’s Company Portal — even when no device enrolment exists. The broker holds the work identity token and passes it to every SDK-enabled app, which is why one PIN prompt in Outlook covers Teams and Word for the next session. If the broker isn’t installed, APP quietly degrades: the SDK still enforces policy on its own app, but cross-app single sign-on and some advanced integrity checks fall away. A detail worth surfacing in onboarding.

Conditional launch is a local state machine

The under-appreciated piece is Conditional Launch. Every time a managed app resumes, the SDK runs a checklist: is the OS version above the floor, is the device jailbroken or rooted, is the Play Integrity or App Attest result clean, is the user still in good standing with Entra ID, how long since the last check-in? If any requirement fails, the SDK can warn, block, or selectively wipe org data — on its own, from a cached policy, without Intune needing to reach the device at that moment.

The data boundary works the same way. “Save copies of org data” restricted to OneDrive for Business, “Open-in” restricted to other managed apps, encrypted cache at rest — these are decisions made inside the app process by asking the SDK whether the target app is on the allow list and signed in with the same work identity.

Where Conditional Access joins in

The final layer is the Entra ID grant control Require app protection policy. This is what makes APP enforceable rather than optional. The token issued to the app is stamped with a claim confirming the app is compliant with its APP at sign-in. Conditional Access can refuse the token entirely if the app isn’t protected, and with Continuous Access Evaluation the refusal can happen mid-session. That’s the seam between the identity plane and the data plane.

What I’d tell a junior engineer

APP is a policy engine bolted into each app, gated by the broker, validated by Conditional Access. Understand those three layers and the “why did this break” tickets get a lot shorter.

Worth bookmarking: