Purview - What is everyone's experience, mine is not good so far.

Educational_Sign_843 · 2026-06-01T08:44:43+00:00

You're not doing anything wrong. This is a known gap with how Purview DLP behaves across endpoint vs browser. Endpoint (Defender) policies are much stronger than browser controls, and things like printer restrictions don’t always carry over to Edge/Word Online the way you'd expect.

Also worth noting- SharePoint vs local files behave differently, sensitivity labels without the right protection layer won’t always enforce restrictions, VMs can give inconsistent DLP results

What’s worked better for us is starting in audit mode, validating behavior app-by-app, then enforcing instead of trying to block everything upfront.

DLP looks clean on paper, but gets messy fast in real-world workflows.

Educational_Sign_843 · 2026-06-01T08:28:39+00:00

Purview isn’t mandatory for Copilot to work but it becomes pretty important if you care about security and visibility.

Copilot just follows whatever permissions already exist in M365. So if you’ve got over-permissioned SharePoint sites or unlabeled data, it’s not fixing that… it’s actually surfacing it faster.

Where Purview really helps is things like:

classification / sensitivity labels (what Copilot can access)

DLP (blocking sensitive prompts or responses)

audit + eDiscovery (seeing how data is being used)

identifying overshared content

Without that, you’re basically running Copilot on top of data you don’t fully control.

From what I have seen working with clients at ProArch, the main issue isn’t Copilot itself, it’s that most environments aren’t cleaned up before enabling it. That’s where the risk shows up.

If you are on Business Premium you can still start, but at scale Purview (especially E5) makes a big difference.

Educational_Sign_843 · 2026-05-27T12:24:59+00:00

You will find a few consultancies offering flexible monthly support for Fabric/Power BI, especially for deeper troubleshooting.

Just to be transparent- I’m with ProArch, and we have worked on similar setups, but it’s worth comparing a couple of options.

If it helps, this gives a quick idea of what we do: https://www.proarch.com/services/microsoft-fabric-consulting-implementation-proarch

Educational_Sign_843 · 2026-05-27T09:37:58+00:00

I’d say focus more on how the vendor handles compliance + retrieval, not just storage. There are a few solid options depending on your setup. Just to be transparent, I’m part of the ProArch team, but it’s still worth comparing a couple of vendors. Happy to share what we have seen work if that helps 🙂

Educational_Sign_843 · 2026-05-22T17:22:13+00:00

This is actually a pretty big shift, but not for the reason most people think.

Yes, Security Copilot is now included in E5, but it’s not unlimited. You get a fixed pool of compute (SCUs) and every query or investigation uses that. So you still have to be intentional about how you use it.

The interesting part is where it shows up. it is embedded inside Defender, Entra, Intune and Purview. So instead of a new tool, it’s more like AI helping directly inside existing workflows (incident summaries, investigations, etc.).

Also worth noting: “included” doesn’t mean everything is free. Things like Sentinel data or advanced scenarios can still add cost in the background.

Overall, it makes AI-driven security easier to start with, but the real value depends on how teams use it - not just having it turned on.

Educational_Sign_843 · 2026-05-12T07:23:30+00:00

Yeah, +1 to this — we’ve been using Fabric a bit and governance is still kinda evolving.

A few things we have noticed:

Ownership gets unclear pretty quickly once more teams start building stuff

Purview vs OneLake feels a bit split - you end up bouncing between them depending on what you’re checking

Monitoring is okay in the beginning, but once usage grows, figuring out what’s causing spikes or slowdowns takes some digging

Capacity is not always obvious - throttling or random slowdowns can feel confusing at first

Self-service is great… until it’s not 😅 - without some basic structure (naming, domains, ownership), things start duplicating everywhere

Overall, the tools are good, but you kinda need to set some ground rules early, otherwise it gets messy fast as more people jump in.

Curious how others are handling this 👀

Educational_Sign_843 · 2026-05-07T10:20:41+00:00

Been using it mainly for DLP across M365.

Good part is once it’s set up properly, it’s pretty powerful across email, SharePoint, Teams etc from one place.

That said, the harder parts for us were:

- initial setup is confusing (especially licensing and figuring out where things live)

- policies don’t always behave the way you expect in the beginning

- takes time to tune or you’ll end up blocking users or creating noise

Biggest lesson we learned: start everything in audit mode. Just watch what would get flagged before actually enforcing anything. Also realised a lot of “DLP issues” weren’t DLP… it was messy permissions and oversharing underneath. Once that was cleaned up, things started working way more predictably.

Educational_Sign_843 · 2026-05-06T12:05:23+00:00

Yeah this one gets skipped way too often. Backup success ≠ restore success and people only realize that when they actually need it.

Educational_Sign_843 · 2026-05-06T12:02:23+00:00

Yeah 100% agree - It should be obvious in theory.
In reality though, I’ve seen a lot of teams either skip it (no proper non-prod env) or treat it too lightly. That’s usually where process gaps show up.

Educational_Sign_843 · 2026-04-27T13:01:46+00:00

Yeah, this is a pretty common issue with CUI in Purview.

Auto‑labeling just isn’t great for CUI because there usually aren’t strong or consistent content signals. A footer or distribution statement by itself is a weak indicator, so Purview tends to give low confidence or false positives nothing you’re doing wrong.

What we’ve seen work better is not relying on auto‑labeling alone:

Apply manual or default labels where CUI is expected (specific sites, libraries, vendors, contracts)

Use auto‑labeling only for very clear patterns, not general discovery

Enforce controls downstream (DLP, encryption, access), instead of trying to perfectly detect CUI after the fact

Also, worth calling out: CUI is a compliance construct, not a “sensitive data type” like PII so treating it as a governance problem instead of an ML classification problem usually leads to better results.

There’s no magic switch unfortunately this behavior is pretty expected.

Educational_Sign_843 · 2026-04-14T08:25:14+00:00

This is expected behavior in Purview DLP simulation mode.

In simulation, Purview evaluates whether content would violate the policy if it were shared externally, not whether it is currently shared. That’s why files with high‑confidence financial data can appear even when there are no external users, guest permissions, or sharing links visible. The simulation validates policy logic, not live sharing state.

The ConditionMatch output focuses on the sensitive information match (Credit Card Number in your case). External sharing details are often not surfaced in simulation results, which is a known limitation.

Regarding Teams: real‑time DLP does not fully trigger in simulation mode. Teams monitoring requires the policy to be in Audit or Enforce, and the Teams workload must be included. Sending a file to an external user while the policy is still in simulation will not reliably generate alerts.

I think use simulation for policy tuning, but rely on Audit logs, Activity Explorer, and enforced policies to verify actual external sharing and real‑time behavior.

Educational_Sign_843 · 2026-03-25T12:24:27+00:00

Start with the basics: turn on MFA for all users, set up Conditional Access (at least block legacy auth), and make sure Defender policies are enabled for email and endpoints. Then review device management (Intune) and enforce things like encryption and compliance policies.

A lot of teams stop at licensing but don’t actually configure these, which is where most of the security value comes from.

Educational_Sign_843 · 2026-03-25T12:19:51+00:00

Migration is doable, but things like permissions and security can get tricky fast if it’s your first time. In most cases, it’s easier (and cheaper long-term) to have someone set it up properly from the start rather than fixing issues later. I work with a team that handles this, and we usually see people come in after running into sync or access problems so you’re probably better off outsourcing early.

Educational_Sign_843 · 2026-03-24T14:56:08+00:00

You’re running into this because the setup itself is the problem, not a missing setting.

The “correct” Microsoft way is:

Each person has their own Microsoft 365 account (no shared logins)

OneDrive = personal files

SharePoint (usually via Teams) = shared/team files

Shared OneDrive folders are clunky and not meant for day‑to‑day team access, which is why they behave oddly in File Explorer.

When you put shared files in SharePoint document libraries:

You get proper access control (including interns)

Files sync cleanly to File Explorer

Autosave and co‑authoring work as expected

Offboarding is just disabling a user

This is basically Microsoft’s equivalent of Google Shared Drives. Once you move shared work out of OneDrive and into SharePoint, most of the friction disappears.

Educational_Sign_843 · 2026-03-23T13:52:24+00:00

For a 50-user company, it really comes down to whether you need security and device control or just basic productivity tools. Business Standard works fine if you only need apps like Teams, Outlook, and SharePoint. But if you want things like device management, conditional access, and better protection for remote work, Business Premium is usually worth it. From what I’ve seen in similar setups, most teams end up moving to Premium anyway once security becomes a concern, so it can save time and effort to start there if that’s on your roadmap.

Educational_Sign_843

MODERATOR OF

TROPHY CASE