rss.livelink.threads-in-node

Microsoft Purview to detect passwords

miro2022 — Thu, 30 Apr 2026 22:26:52 GMT

Hi All

What would you recommend for scanning and setting up scheduled scans in Microsoft Purview to detect passwords or sensitive credentials stored in SharePoint sites and OneDrive?

We would like to discover whether anyone has shared or stored passwords in SharePoint or OneDrive, as we have already had an incident because of this.

Are there any recommended Purview solutions, policies, or detection rules we should use for this? Ideally, we would like to schedule regular scans and receive alerts or reports when potential passwords, credentials, or secrets are detected.

Any advice or recommended approach would be appreciated. thanks

thanks

Miro

Welcome, Purview Lightning Talks audience!

RenWoods — Thu, 30 Apr 2026 12:41:14 GMT

Please log in and then post any of your Data Security (and AI) spillover Purview Lightning Talks questions in the thread below. You can tag them using these hyperlinked handles:

Session Title	Speaker	Tech Community Alias (tag)
The Purview Label Engine: Automated Classification, Translation, and Co-Documentation for Enterprise Tenants	Michael Kirst Neshva	MichaelKirst1970
Stop, Think, Protect: Data Security in Real Life with Purview	Oliver Sahlmann	Oliver Sahlmann
Using Purview to Prevent Oversharing with AI Services	Viktor Hedberg	headburgh
How I Helped My Customers Understand Their AI Usage (and Protect Their Sensitive Data)	Bram de Jager	Bram de Jager
Four Labels Max for Daily Use: Which Ones & Why?	Romain Dalle	RomainDalle_MVP_MCT
Data‑driven Endpoint DLP Solution with Advanced Hunting	Tatu Seppälä	tseppala
The Purview Hack No One Talks About: Container Sensitivity Labels That Fix Oversharing Fast	Nikki Chapple	nikkichapple
Why You Should Create Your Own Sensitive Information Types (SITs)	Niels Jakobsen	Niels_Jakobsen
From Zero to First Signal: Insider Risk Management Prerequisites That Actually Matter	Sathish Veerapandian	Sathish Veerapandian
Securing Data in the Age of AI	Júlio César Gonçalves Vasconcelos	jcvasconcelos
Beyond eDiscovery – Purview DSI for Security Investigation	Susantha Silva	susanthasilva
Elevating Purview DLP with a Real‑World Use Case	Victor Wingsing	vicwingsing

Purview Lightning Talks takes place April 30th at 8am pacific: Webinar Details

Full agenda here.

Also, you can come here at any time and click "Start a Discussion" to post a topic or question to your Purview Community!

Welcome, Purview Lighting Talks audience!

RenWoods — Wed, 29 Apr 2026 22:04:11 GMT

Please log in and then post any of your Risk and Compliance spillover Purview Lightning Talks questions in the thread below. You can tag them using these hyperlinked handles:

The Day Offboarding Exposed Infinite Retention - Nikki Chapple nikkichapple

Length: 10 minutes | Topic: Data Lifecycle Management

A routine Purview request led to an unexpected discovery: more than 9,000 orphaned OneDrives and thousands of inactive mailboxes still storing content long after employees had left. This talk explains how a retain-only policy created hidden retention debt and how Adaptive Scopes can help organisations separate active users from leavers to avoid similar pitfalls.

What's In My Compliance Manager Toolbox: A Cloud Security Architect's Perspective - Jerrad Dahlager j-dahl7

Length: 8 minutes | Topic: Compliance Manager

A practical walkthrough of how I use Compliance Manager across real client engagements to map controls, track improvement actions, and simplify multi-framework compliance. No theory, just what works in the field.

Does M365 Support eDiscovery? - Julian Kusenberg - Leprechaun91

Length: 11 minutes | Topic: eDiscovery

A myth-busting session that separates perception from reality when it comes to Microsoft 365 eDiscovery capabilities.

Also, you can come here at any time and click "Start a Discussion" to post a topic or question to your Purview Community!

Purview Lightning Talks takes place April 30th at 8am pacific: Webinar Details

Welcome, Purview Lighting Talks audience!

RenWoods — Wed, 29 Apr 2026 21:54:01 GMT

Please log in and then post any of your Data Governance spillover Purview Lightning Talks questions in the thread below. You can tag them using these hyperlinked handles:

Improving Discovery, Trust, and Reuse of Analytics with Purview Data Products - CraigWyndowe

Length: 5 minutes | Topic: Governance

This talk shows how bringing Power BI and Fabric assets into Microsoft Purview Governance Domains and Data Products creates a single, trusted view of enterprise analytics. By connecting reports, semantic models, and underlying data with shared metadata, ownership, and business context, organizations can make existing assets easy to discover and safe to reuse.

Also, you can come here at any time and click "Start a Discussion" to post a topic or question to your Purview Community!

Activity explorer scoping to AU

AlaaAy — Wed, 29 Apr 2026 15:39:32 GMT

I remember that Activity Explorer can be fully scoped to Admin Units, and that the Restricted admin can see activity explorer and DLP matching events for the scoped AU only, is that correct?
Cause I was checking and I found the Restricted admin can see the activities also for the users out of the scoped AU. Does that make sense?

eDiscovery search: Sites not available when adding a Group data source

danielschmidt — Mon, 27 Apr 2026 15:30:12 GMT

Hi,

I am attempting to use Purview eDiscovery to search a SharePoint site associated with a Group.

When adding the Data Source, I search for the URL of the SharePoint site, and the Group is returned.

However, after selecting the group and clicking Manage, it indicates Sites are "Not Available".

What causes this, and how do fix it?

My user is a member of the "eDiscovery Manager" role group as an "eDiscovery Administrator", and licensed with "Microsoft 365 E3" and "Microsoft Purview Suite". It is also an Owner of the target Group / SP Site.

Label usage rights not working correctly in office web-view

mdohm1355 — Mon, 27 Apr 2026 07:58:30 GMT

Hello everyone,

I’ve created three simple Purview sensitivity labels (PUBLIC, RESTRICTED, CONFIDENTIAL). RESTRICTED and CONFIDENTIAL use usage-rights, so every internal employee and group is the owner of the document. External users are not permitted to open the document.

Unfortunately, I can’t export or print my labeled documents in the Office Web View. In Office Desktop, however, the labels work correctly.
This issue occurs for various internal users. Tested with Word, Excel, and PowerPoint.

Co-authoring is enabled. User access never expires. Offline access is permitted.

Do you have any ideas?

Label usage rights

Web-view

Office Desktop

Auto Labeling Policy Delay for Old Files (Exsisting Files)

BanuMurali — Sun, 26 Apr 2026 14:44:29 GMT

Hi Everyone,

We are observing a difference in auto labelling policy behaviour in Purview for Sharepoint.

An auto labelling policy has been enabled and scoped to sharepoint with metadata based rule(document creation date or document modification date). The scoped sharepoint only contain 7 unlabeled files that were uploaded before the policy turned on. The policy is working because if i placed any new file after enabling the policy got labelled within about 5 minutes, but the exsisting files are not labeled and remains unlabelled. It seems the new files are evalauated via the near time while exsisting file rely on asychronous mode. Can anyone help explain why exsisting files take longer to be proceesed even when there there are only a few files or share if you faced similar behaviour. This is the test scenario, as we plan to enable the same policy across more than 50 plus sites containing millions of unlabeled files and we want to understand and predict that even though its takes time all exsisting unlabeled files will eventually will be labelled. This is very crucial, so please helo us understand this behaviour.

Regards,

BanuMurali

ErrorBoundary@wicd-mail/main

CCraft301 — Fri, 24 Apr 2026 12:16:04 GMT

I'm trying to investigate a possible phishing email and when I click on View Message List, I get that error. It does show removed after delivery, but I want to block either the sender or the domain.

From Oversharing to Enforcement: A Practical Guide to AI Data Security with Microsoft Purview

George Smyrlis — Thu, 23 Apr 2026 14:58:26 GMT

Why AI Changed the Data Security Problem

AI does not create entirely new categories of risk—it supercharges existing ones. Traditional data leakage stems from ordinary behavior: sharing a document too broadly, sending an email to the wrong person, copying regulated data to an uncontrolled device. Generative AI amplifies all of these because of the power and speed with which it can proactively surface content that may be obsolete, over-permissioned, or ungoverned. DSPM exists to help with exactly this challenge: it continuously scans your environment to identify sensitive data, assess risk, and recommend actions to reduce exposure.

Oversharing at Scale
Before AI, an overshared SharePoint file might sit unnoticed. Now, Copilot can summarize it in response to a casual prompt, distributing its contents far beyond the original audience.
Prompt Leakage
Users can inadvertently expose sensitive information—financial account numbers, health records, project code names—simply by typing them into a Copilot prompt. Because AI interactions feel conversational, users tend to drop their guard.
Shadow AI
Beyond sanctioned tools, employees experiment with unapproved AI services.
Autonomous Agents

Autonomous agents expand the data security threat surface by acting independently on sensitive information across systems and boundaries. Their ability to access and share data without direct user interaction increases the risk of oversharing, exfiltration, and unauthorized access, while also introducing complex behavior patterns that are harder to monitor, govern, and control using traditional security models.

What Microsoft Purview Now Brings Together

Data Security Posture Management (DSPM)

DSPM consolidates insights from Data Loss Prevention (DLP), Insider Risk Management, Information Protection, and Data Security Investigations into a single view for monitoring data risks, policy coverage, and posture trends. Now also in Public Preview, DSPM extends coverage to third-party SaaS and IaaS platforms such as Google Cloud Platform, Snowflake, and Databricks, and integrates with partner solutions including Cyera, BigID, and OneTrust for comprehensive risk insights.

A central innovation in this version is data security objectives—prominent, selectable cards that each represent a specific security goal. Selecting an objective guides administrators through an end-to-end workflow that groups together the most relevant Purview solutions—information protection, DLP, Insider Risk Management, and eDiscovery—so teams can focus on achieving a specific data security outcome rather than navigating separate solutions.

Each Outcome card displays key metrics such as the percentage of data covered by policies, the number of risky sharing incidents, and improvements over time. Within each outcome, DSPM surfaces suggested prioritized actions—applying sensitivity labels, configuring DLP policies, or investigating alerts—all tailored to the organization's data. Administrators can take action directly from the workflow, including remediating oversharing, configuring one-click policies, or launching investigations into suspicious activity.

DLP Integration for AI Interactions

DLP is one of the core solutions integrated into DSPM's unified approach. The Activity Explorer's AI activities tab captures events where DLP rules were matched during AI interactions—including prompts, responses, and browsing to generative AI sites. DSPM can automate remediation steps such as removing public sharing links or applying data loss prevention policies to help prevent incidents before they happen.

AI Observability and Agent Governance

Dedicated dashboards and metrics monitor risks associated with AI apps and agents. AI observability enables tracking of agent-specific activities—oversharing, exfiltration, and unusual access patterns—across both Microsoft and third-party environments. Enhanced reporting provides advanced filtering and customizable views, supporting granular analysis of sensitive data usage, DLP activity, and posture trends. Audit logs and activity explorer features help track interactions with AI apps and agents, supporting compliance investigations and incident response.

AI-Powered Security Operations

DSPM not only secures and governs AI apps and agents but also uses Microsoft Security Copilot and AI agents to help secure and govern data. AI analyzes access patterns, sharing behaviors, and policy gaps to surface actionable risks and can detect unusual activity such as excessive sharing or suspicious downloads. Under administrator guidance, AI agents can take direct action on detected risks—removing public sharing links, applying DLP policies, or revoking permissions. These actions are always audited. To streamline investigations, AI-driven triage agents review alerts from DLP and Insider Risk Management solutions, filtering out noise and highlighting the most critical threats.

Three Practical Starting Points

For many organizations adopting generative AI, the biggest hurdle isn't recognizing new risks—it's figuring out where to begin. A "boil the ocean" approach can stall progress, while tackling a few targeted areas delivers quicker wins.

The best early moves are those that reduce exposure quickly, improve visibility, and build a foundation for stronger governance over time.

Starting Point 1: Enable prompt-level protection for Microsoft 365 Copilot

An effective first step is to put guardrails on the prompts users enter into AI. Microsoft Purview DLP allows administrators to restrict Microsoft 365 Copilot and Copilot Chat from processing prompts that contain sensitive information. In practice, users are often more comfortable pasting data into a chat prompt than attaching it to an email, which means a well-meaning employee could inadvertently feed a confidential file or personal data into Copilot.

Enabling prompt-level DLP creates an immediate safety net: if a user's prompt includes, say, a credit card number or a customer's national ID, Copilot will detect it and refuse to process or share that content. DSPM provides suggested prioritized actions—including configuring DLP policies—that can be activated directly from the workflow, and recommended policies can start in simulation mode. Simulation mode lets you see what would have been blocked or flagged, without actually interrupting users, so you can fine-tune the policy and prepare your helpdesk for any questions. Once you're comfortable with the results, switching to enforcement mode will actively block disallowed prompts and log those events for review.

By activating this one control, you've significantly reduced the most immediate oversharing risk—the "oops, I pasted the wrong data" scenario—within hours of starting your AI governance program.

Tradeoff: Simulation mode provides safety but delays enforcement. For organizations with imminent regulatory exposure, consider shortening the simulation window and monitoring alert volumes closely.

Starting Point 2: Gain visibility into shadow AI usage before broad enforcement

The second step is to illuminate what's happening in the shadows. Before rushing into blocking every unsanctioned AI tool, it's crucial to understand how and where AI is being used across the organization. In most enterprises, there's an official layer of AI usage and an often larger, unofficial layer—employees experimenting with free online AI chatbots, writing assistants, or code generators.

DSPM provides this visibility. The Discover > Apps and agents dashboard shows AI apps used across the organization, including the top 20 most recently used agents, with details about sensitive data they accessed and how they are protected by Purview policies.

The AI observability page provides a broader inventory of all AI apps and agents with activity in the last 30 days, including how many are high risk and the total with sensitive interactions. The Activity Explorer's AI activities tab shows when users browsed to generative AI sites, the prompts and responses involved, whether sensitive information was present, and whether DLP rules were matched. Armed with this insight, you can make informed decisions. If you discover that the majority of "AI consumption" comes from just two external apps, you might focus your immediate controls on those two. Conversely, if the data shows most unsanctioned usage is low-risk, you might decide to monitor rather than block it.

The key is visibility first, enforcement second—letting real data guide where to tighten controls versus where to offer secure alternatives.

Tradeoff: Visibility without timely follow-through can create a false sense of security. Set a defined window (e.g., 30 days) after which findings must translate into at least one concrete policy action.

Starting Point 3: Operationalize DSPM objectives for Copilot

A stronger third starting point is to use DSPM as your operational guide, not just a dashboard of charts. DPSM introduces data security objectives—each one a focused end-to-end workflow for a specific outcome. Rather than configuring individual features in isolation, you select an objective and let Purview navigate you through achieving that outcome with the relevant tools.

For generative AI, the key objective to leverage early is "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions". By selecting this objective in the Purview portal, you're effectively telling Purview, "help me implement whatever is needed to make Copilot safe with our data." The DSPM interface then groups together the critical pieces: it may prompt you to enable a DLP policy, suggest applying or refining sensitivity labels on content, or surface an Insider Risk Management policy template for detecting AI-related risky behavior. It also surfaces metrics so you can track progress—for example, the percentage of data covered by policies, or the number of risky sharing incidents that have been remediated.

Using DSPM objectives keeps your team aligned on a clear goal from day one. It shifts the conversation from "what knobs do we turn on?" to "how do we achieve this outcome?" You follow a guided plan curated by the platform's intelligence rather than navigating five different admin pages and hoping it adds up to protection.

Tradeoff: Objectives streamline the path but can obscure the underlying complexity. Teams should periodically step outside the guided workflow to review the full policy landscape and ensure no coverage gaps exist between objectives.

From Visibility to Remediation: Turning Insights into Action

Automated Remediation at Scale

DSPM can automate remediation steps such as removing public sharing links or applying data loss prevention policies to prevent incidents before they happen. Under administrator guidance, AI agents within DSPM can take direct action on detected risks—removing sharing links, applying DLP policies, or revoking permissions—and these actions are always audited. This moves the operating model from manual, one-at-a-time fixes to systematic, policy-driven remediation.

Closing the Loop: From Risk to Standing Policy

DSPM's data security objectives surface suggested prioritized actions such as applying sensitivity labels, configuring DLP policies, or investigating alerts, all tailored to the organization's data. Reporting and analytics are organized by outcome, making it easier to identify and report improvements, compliance, and risk reduction. This turns recurring findings into standing preventive controls. Instead of re-running assessments and manually fixing the same patterns, administrators create durable policies that enforce the desired state going forward.

Alert-Driven Investigation and Tuning

Audit logs and activity explorer features help track interactions with AI apps and agents, supporting compliance investigations and incident response. Integrated investigation and forensics tools support rapid incident response and root cause analysis for data security events. Impact prediction visuals and progress tracking for remediation steps are surfaced throughout DSPM, enabling administrators to quantify the effect of their actions and adjust course.

The closed-loop process is: Discover (DSPM scans and risk assessments) → Remediate (automated actions and bulk fixes) → Prevent (create or tighten DLP and auto-labeling policies) → Monitor (alert review, investigation, and policy tuning).

What "Good" Looks Like in a Regulated or Risk-Aware Organization

A mature AI governance posture is defined by measurable outcomes and sustainable operating rhythms—not feature count:

Clear, communicated AI usage policies. Users know what is and is not acceptable in AI interactions because the tools reinforce the rules. DLP policy tips delivered at the moment of a violation are a primary training mechanism—they remind users in context why their prompt was blocked and what to do instead.
Measured enablement over blanket bans. Leading organizations allow Copilot with appropriate controls and restrict only truly unacceptable scenarios. Policies deployed initially in simulation mode provide data to calibrate enforcement thresholds before blocking. This avoids productivity backlash while preserving security posture.

High data hygiene and classification rates. Purview's AI protections depend heavily on sensitivity labels. If everything is unlabeled or "General," label-based controls have nothing to act on. Mature organizations invest in auto-labeling and mandatory labeling to close this gap before deploying AI at scale. DSPM's data security objectives include suggested actions such as applying sensitivity labels, directly tying classification to governance outcomes.

Quantifiable risk reduction. Security leadership can produce metrics from Purview that show trend lines: DSPM Outcome cards display the percentage of data covered by policies, the number of risky sharing incidents, and improvements over time. These figures feed directly into compliance reporting and audit evidence. Key metrics are tracked over time, supporting continuous improvement of the organization's data security posture.

Cross-functional governance. AI governance is not a solo IT Security effort. Stakeholders from security, compliance, legal, and business units review AI usage patterns, discuss policy tuning, and evaluate new Purview capabilities as they release. Role-based access controls within DSPM provide granular access to features and AI content for delegated administration and compliance, enabling this cross-functional model without overexposing sensitive data to every participant.

Tradeoff: Strict enforcement can frustrate power users and slow AI adoption. Organizations should explicitly define escalation paths—if a legitimate use case is blocked by DLP, there must be a fast process to review and adjust, rather than a permanent "no."

A Phased Adoption Model

Phase	Focus	Key Activities
Phase 1 — Quick Wins (weeks)	Visibility and baseline safeguards	Enable prompt-level DLP for Copilot in simulation mode. Run first DSPM data risk assessment for oversharing. Enable shadow AI discovery via DSPM's Apps and agents dashboard and AI observability page. Start from the DSPM objective "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions."
Phase 2 — Broad Enforcement (months)	Acting on findings	Switch DLP policies from simulation to enforcement. Use automated remediation actions (removing sharing links, applying DLP policies, revoking permissions). Expand sensitive information type definitions and add custom types. Rollout user communications explaining new controls and escalation paths.
Phase 3 — Mature Governance (ongoing)	Continuous improvement and AI-powered operations	Leverage AI-driven triage agents to filter alert noise and highlight critical threats. Conduct periodic DSPM posture reviews using Outcome card metrics. Tune policies based on impact prediction visuals and progress tracking. Extend protections to new AI apps and agents as they are adopted—DSPM's AI observability tracks agent-specific activities across Microsoft and third-party environments. Formalize cross-functional AI governance cadence.

*Phase 1 should take weeks, not months—the objective is to establish a baseline before risk accumulates.

*Phase 2 is where enforcement generates measurable risk reduction.

*Phase 3 is ongoing: as Microsoft continues extending Purview to additional AI apps and agent types, the governance framework must evolve in tandem.

The DSPM preview's integration with third-party SaaS and IaaS platforms (Google Cloud Platform, Snowflake, Databricks) and partner solutions (Cyera, BigID, OneTrust) means the governance perimeter can expand alongside the organization's AI footprint.

Conclusion

AI adoption and data protection are not opposing forces. Microsoft Purview now provides the visibility, policy controls, and remediation workflows to move from discovering AI risk to actively governing Copilot, third-party AI apps, and agents at scale. DSPM surfaces oversharing and AI usage patterns through unified dashboards, data risk assessments, and AI observability. DLP blocks sensitive data in prompts and restricts AI access to labeled content. Insider Risk Management detects adversarial AI behavior. AI-driven triage and remediation agents close the gap between identifying a problem and fixing it—with every automated action audited.

The path forward starts with practical actions: enable prompt-level DLP, illuminate shadow AI usage, and operationalize DSPM's "Prevent data exposure in Microsoft 365 Copilot and Microsoft Copilot interactions" objective. From there, enforce what you find, measure the results using DSPM's outcome-based metrics, and progressively mature your governance posture.

Organizations that operationalize this loop will be in a strong position: able to say, "We use AI to work smarter—and we have the safeguards in place to do it safely."

Purview : comment filtrer les résultats “Data products” par termes du glossaire ?

Miriane — Thu, 23 Apr 2026 13:39:12 GMT

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; }

Bonjour,

Je teste Microsoft Purview (Unified Catalog) avec des produits de données auxquels j’ai associé des termes de glossaire.

Les termes de glossaire sont publiés et visibles dans l’onglet Découverte → Glossaire d’entreprise.
Les produits de données sont également publiés et retrouvables via la recherche.

Cependant, je ne vois pas d’option (ou elle ne retourne aucun résultat) pour filtrer les résultats de recherche des produits de données par termes de glossaire, contrairement à d’autres filtres disponibles (ex. Propriétaire, Type de produit)

Est-ce que le filtrage des produits de données par termes de glossaire est supporté dans l’onglet Découverte ?
Si oui, y a-t-il des pré-requis ou conditions particulières (ex. type de glossaire, indexation/délai, association au niveau data product vs assets, etc.) ?

Filtrer les résultats de la recherche des produits de données à l'aide des termes de glossaire

Miriane — Thu, 23 Apr 2026 13:34:22 GMT

Bonjour,

Je teste Microsoft Purview (Unified Catalog) avec des produits de données auxquels j’ai associé des termes de glossaire.

Les termes de glossaire sont publiés et visibles dans l’onglet Découverte → Glossaire d’entreprise.
Les produits de données sont également publiés et retrouvables via la recherche.

Métadonnées personnalisées sous Purview avec une relation un à plusieurs

Miriane — Thu, 23 Apr 2026 13:21:31 GMT

Bonjour,

Je souhaite créé une métadonnée sous Purview, en l'associant à une métadonnée parent, Comment est-ce possible

Merci de votre retour,

Unified Catalog Self-serve analytics integration

JBNFM — Tue, 21 Apr 2026 18:52:14 GMT

I'm hoping someone has gone through the process of setting up the Self-serve analytics in the Unified Catalog settings to push the Unified Catalog information down to a Fabric Lakehouse.

I created a Workspace, and then created a lakehouse in this workspace, and created a folder under the files section in the lakehouse. I used the MSI that is shown in Purview when you configure the storage for the connection and granted it contriubutor access to the Workspace.

I then went into Purview, settings for Unified Catalog, and in the solution integrations, set up Fabric storage and provided the URL to the File folder I set up on the lakehouse.

I tested the connection and it tested successfully.

When I set up the scheduler to run, I received the following:

The blacked out is the Workspace ID.

I'm trying to understand what I'm missing, I'm assuming write permissions are missing somewhere, but I'm not sure. Any assistance is appreciated.

Shared capabilities

RalfBauer1 — Mon, 20 Apr 2026 08:53:04 GMT

I am writing my thesis about Microsoft Purview. And something is not very clear to me about the shared capabilities. So I know Microsoft has the platform and the product shared capabilities. The platform shared capabilities are the foundation for Purview. Like audit logs and retention labels etc. The product shared capabilities are products as Adaptive Protection and OCR. There is a lot information about the product shared capabilities on learn.microsoft.com. But is there anything I can find about the platform shared capabilities like a blogpost or a webinar?

How to identify users handling SITs before purchasing Microsoft Purview licenses?

elangamban — Mon, 20 Apr 2026 06:59:38 GMT

Posting this on behalf of a customer we are currently advising as a Microsoft Partner.

The customer is in the evaluation stage of Microsoft Purview and has raised a licensing concern that we would like the community's guidance on.

CUSTOMER'S CONCERN

Purview licenses are user-based, meaning every user who directly or indirectly benefits from the service needs to be licensed. However, to determine which users actually handle sensitive data (and therefore require a license), tools like Content Explorer and Activity Explorer are needed — both of which require an E5 or equivalent license to access in the first place.

This creates a chicken-and-egg problem for the customer:

They need Purview to identify who handles sensitive data, but they need to know who handles sensitive data to decide how many Purview licenses to buy.

QUESTIONS ON BEHALF OF THE CUSTOMER

1. Is there an official Microsoft-supported mechanism or tool that allows customers to assess their SIT exposure and identify affected users before committing to a full Purview license purchase?

2. Is it viable for the customer to purchase a single license (1 qty) assigned to an admin account to perform a tenant-wide scoping and discovery exercise — and would that single license provide sufficient access to identify all users handling SITs across the tenant?

3. If the 90-day Purview E5 trial is the recommended path, does Content Explorer automatically scan and surface SIT matches across all users in the tenant without requiring any pre-configured DLP policies or sensitivity labels to be set up first?

As a partner, we want to ensure we are guiding our customer toward the correct pre-purchase assessment approach before recommending a licensing SKU and quantity.

Any guidance from the community or Microsoft would be greatly appreciated.

Microsoft Purview PowerShell: Interactive Sign-In Basics + Fixing Common Connect-IPPSSession Errors

Prathista Ilango — Sat, 18 Apr 2026 17:17:03 GMT

If you’re new to Microsoft Purview PowerShell and your interactive sign-in fails when you run Connect-IPPSSession, you’re not alone.

In this post, I’ll walk through the quick setup (module install + connection) and then cover practical fixes for a common authentication failure: “A window handle must be configured” (WAM / MSAL window handle error).

Once connected, you can run Purview-related cmdlets for tasks like working with sensitivity labels, DLP policies, eDiscovery, and other compliance operations (depending on your permissions).

Step 1: Install the Exchange Online PowerShell module

Install-Module ExchangeOnlineManagement Import-Module ExchangeOnlineManagement

Step 2: Connect to Microsoft Purview (Security & Compliance) PowerShell

For interactive sign-in, you can start with the standard connection pattern below (replace the placeholder with your User Principal Name)

Common issue: Interactive sign-in fails with a WAM “window handle” error

The ExchangeOnlineManagement module uses modern authentication. In some hosts/environments, the sign-in UI can’t attach to a parent window, so token acquisition fails and you may see the error below. This is commonly associated with WAM (Web Account Manager) / MSAL interactive sign-in.

Error Acquiring Token:

A window handle must be configured. See https://aka.ms/msal-net-wam#parent-window-handles

A window handle must be configured. See https://aka.ms/msal-net-wam#parent-window-handles

At C:\Program Files\WindowsPowerShell\Modules\ExchangeOnlineManagement\3.9.2\netFramework\ExchangeOnlineManagement.psm1:591 char:21

+                     throw $_.Exception.InnerException;

+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : OperationStopped: (:) [], MsalClientException

    + FullyQualifiedErrorId : A window handle must be configured. See https://aka.ms/msal-net-wam#parent-window-handles

You’ll often hit this on secured devices, PowerShell ISE, or hardened corporate images. Below are two solutions to bypass this error. Start with the recommended option first.

1. Recommended workaround: Use Get-Credential without disabling WAM

This approach avoids the WAM-based interactive prompt. You’ll be asked for credentials via a standard PowerShell credential dialog, and the module will complete modern authentication.

$cred = Get-Credential Connect-IPPSSession -Credential $cred

A credential prompt appears: Enter your username and password.

After authentication, you should be connected to the Security & Compliance (Microsoft Purview) PowerShell session.
As a quick validation, try a lightweight cmdlet such as Get-Label or Get-DlpCompliancePolicy (availability depends on permissions).

If this works in your environment, it’s a simple way to proceed without changing system-wide WAM behavior.

2. Alternative workaround: Disable WAM for the session (use with caution)

If the interactive UI is failing, you can try disabling WAM. Newer versions of the ExchangeOnlineManagement module support a -DisableWAM switch on the connection cmdlets, which bypasses the WAM broker and can avoid the “window handle” failure.

Connect-IPPSSession -UserPrincipalName <yourUPN> -DisableWAM

If you can’t use -DisableWAM or if it is not working as expected (or you’re troubleshooting a specific host issue), some admins set an environment variable to disable WAM for MSAL using the commands below. Treat this as a temporary troubleshooting step and follow your organization’s security guidance.

$env:MSAL_DISABLE_WAM = "1" setx MSAL_DISABLE_WAM 1

Important warning!

Changing authentication/broker behavior can have security and supportability implications.
Use this only for troubleshooting and revert when you’re done using the following commands.

$env:MSAL_DISABLE_WAM = "0" setx MSAL_DISABLE_WAM 0

Quick summary

If you’re scripting for Microsoft Purview and interactive sign-in fails due to the WAM “window handle” error, try the sequence below.

Install-Module ExchangeOnlineManagement Import-Module ExchangeOnlineManagement $cred = Get-Credential Connect-IPPSSession -Credential $cred

Hope this helps!

If you’ve hit this in a specific host (PowerShell ISE vs Windows PowerShell vs PowerShell 7, RDP/jump box, etc.), share what worked for you in the comments.

Thanks for reading. Happy Scripting!

Reference: Connect to Security & Compliance PowerShell | Microsoft Learn

Deploy scalable ring‑fenced Purview operations with Administrative Units

MaximeBombardier — Sat, 18 Apr 2026 01:22:01 GMT

As Microsoft Purview deployments mature, many organisations encounter the same scaling challenge: how do you decentralize operations without fragmenting governance or losing visibility? Administrative Units (AUs) provide a native way to solve this by enabling ring‑fenced operations—allowing teams to operate independently within clearly defined boundaries, while preserving central oversight.

This post focuses on the why behind using Administrative Units in Microsoft Purview, with a particular emphasis on scalable, ring‑fenced operations. We’ll walk through three reference architectures that illustrate how Administrative Units support real‑world operating models—without requiring multiple tenants or separate DLP platforms.

note: this article and visuals will focus on Administrative Units support in Purview Data Loss Prevention. However, Administrative Units are supported in additional solutions of Microsoft Purview. Refer to Administrative units in Microsoft Purview | Microsoft Learn for more details and support.

Why Administrative Units matter for scalable operations

Many large organisations operate with decentralized compliance and DLP teams, often aligned to regions, business units, or regulated functions. Historically, this led to one of two sub‑optimal patterns:

Multiple, disconnected DLP solutions or tenants
Centralized teams managing policies and alerts for parts of the business they don’t own

Administrative Units change this model by allowing organisations to:

Partition users (and supported resources) into logical units
Assign restricted administrators who can only see and act within their unit
Apply both global and AU‑scoped policies together, with predictable behavior

From a Purview perspective, this enables true business function autonomy, enforced through RBAC and data visibility boundaries, while keeping global services—such as classification—centralized.

Reference architecture 1: Layered governance with ring‑fenced operations

Scenario

An organisation wants to migrate from multiple legacy DLP solutions into Microsoft Purview while preserving independent operations for each business function or region.

Architecture highlights

This model introduces three distinct layers:

Central governance (Global)
- Global administrators define baseline policies applicable across the tenant
- Shared services such as classifiers and reusable components remain central
- Central teams retain cross‑tenant monitoring and reporting capabilities
Administrative Units (per business function)
- Each business function or region is mapped to an Administrative Unit
- RBAC, policy visibility, and alert management are strictly scoped to the AU
- Policies created here only affect users within that unit
Business function‑level operations
- Scoped DLP admins manage local policies
- Alerts and incidents are handled by the owning team
- Controls can be tuned to meet specific regulatory or operational needs

Why this matters

This architecture enables a phased migration:

Start with a single entity
Gradually scale across additional business functions
Avoid policy sprawl by consolidating and retiring legacy configurations

Crucially, tenant‑wide limits and global services remain unchanged, ensuring consistent performance as scale increases.

Reference architecture 2: Ring‑fencing user activity visibility to sub‑business functions

Scenario

“We have dedicated DLP analysts for executives. DLP alerts and activities for these users must only be visible to that team.”

Architecture highlights

This model refines the first architecture and allowing to have DLP analysts for a subset of users only.
Executive users are placed into a dedicated Administrative Unit representing a subset of users of a business unit.
Policies can be published to multiple Administrative Units (ex: Americas + Americas - Execs)

In this model:

Some DLP administrators may be assigned to multiple AUs so they can publish policies across them
Users must belong to a single AU to ensure clean visibility boundaries

Why this matters

This pattern is particularly effective for:

Executive monitoring
HR or Legal teams
Highly sensitive populations

It delivers strict separation of duties without duplicating policies or creating isolated tenants, and aligns with how Purview scopes alerts, activity explorer, and audit data when Administrative Units are used.

Reference architecture 3: User activity visibility for multi‑AU users

Scenario

Some users operate across multiple business functions—for example, executives or shared service leaders—while still requiring controlled visibility for analysts.

Architecture highlights

User activities are stamped with the sum of all Administrative Units the user belonged to at the time of the activity
Scoped DLP administrators:
- Can only create policies affecting users within their assigned AU. However the sum of their policies will be applicable.
Scoped DLP analysts:
- See all activities for users in their AU, even if those activities were generated by policies scoped to a different AU.

Why this matters

This model ensures:

No loss of investigative context for analysts
Predictable visibility when users span multiple organizational boundaries
Continued enforcement of AU‑based separation of duties

It also reinforces a key principle: Administrative Units control visibility and management scope — not the existence of the underlying activity data. Once a user's in scope of a policy, its related activities/alerts are visible to DLP analysts allowed to review this user's activities.

When not to use Administrative Units

Administrative Units are a powerful enabler for decentralized, ring‑fenced operations—but they are not required in every Purview deployment.

You may choose not to introduce Administrative Units in the following situations:

Single, centralized compliance team. If one team owns all policy creation, alert triage, and investigations across the organisation—and there is no requirement to restrict visibility—Administrative Units add limited value. In this model, global role groups already provide sufficient control.

No need for visibility or management separation. Administrative Units are primarily about scoping visibility and permissions. If all administrators are expected to see all users, alerts, and activities, AU‑based scoping may introduce unnecessary complexity without operational benefit.

Early or small‑scale Purview deployments. Organisations at an early stage of Purview adoption—running a small number of global policies—may find it simpler to start without AUs and introduce them later as operating models mature. Administrative Units do not change tenant limits or global services, so adoption can be phased over time.

Requirements driven purely by policy targeting. If the primary requirement is targeting users dynamically for policy application (rather than restricting administrator access or visibility), adaptive scopes alone may be sufficient. Administrative Units become relevant when who can see and manage data is as important as which users are in scope.

In short, Administrative Units are best introduced when organisations need to scale operations with clear ownership boundaries, not simply to organise users.

Centralized vs. Decentralized Functions in a Ring‑Fenced Operating Model

A scalable Microsoft Purview operating model relies on a deliberate split between functions that remain centralized at the tenant level and those that are decentralized to business functions or regions via Administrative Units (AUs). This balance enables autonomy without fragmentation, preserving global consistency while allowing teams to operate independently within defined boundaries.

Functions that Remain Centralized

Certain capabilities are intentionally retained at the global (tenant) level to ensure consistency, performance, and governance across the organisation. These functions are not delegated to Administrative Units:

Global governance and baseline policy definition
Central teams define tenant‑wide baseline policies that apply consistently across all users, regardless of AU membership. This ensures minimum protection standards and avoids divergent interpretations of risk.
Shared services and reusable components
Core services such as classifiers and other reusable components remain centralized to prevent duplication, reduce administrative overhead, and maintain consistent detection behavior across the tenant.
Cross‑tenant monitoring and reporting
Central teams retain visibility across Administrative Units for monitoring, reporting, and oversight purposes, ensuring that decentralization does not result in blind spots at the organizational level.
Tenant‑wide limits and platform behavior
Administrative Units do not alter tenant‑wide service limits or global platform characteristics. Keeping these aspects centralized ensures predictable performance and scalability as additional business functions are onboarded.

Functions that Are Decentralized via Administrative Units

Operational responsibility is decentralized to business functions or regions by mapping them to Administrative Units, with strict scoping enforced through RBAC and data visibility boundaries:

Policy creation and management scoped to the AU
Business function teams can create and manage policies that only affect users within their Administrative Unit, allowing controls to be tailored to local regulatory or operational requirements without impacting other parts of the organisation.
Scoped visibility of alerts, activities, and incidents
Administrators and analysts assigned to an AU can only see alerts, activities, and incidents for users in that unit. This enforces separation of duties and prevents unintended access to sensitive data belonging to other functions.
Local alert handling and incident response
Decentralized teams own the investigation and remediation of alerts generated within their AU, enabling faster response times and clearer accountability.
Operational tuning per business function
Controls can be adjusted within an AU to reflect specific risk tolerances, regulatory obligations, or operational realities, without creating policy sprawl or requiring separate tenants.

Why This Split Matters

By clearly separating centralized governance and shared services from decentralized, AU‑scoped operations, organisations can scale Purview deployments in a phased and controlled manner—starting with a single business function and expanding over time—while maintaining consistent governance, visibility, and performance across the tenant.

Key takeaways

Administrative Units in Microsoft Purview are not just a permissions feature—they are an operating model enabler. Used correctly, they allow organisations to:

Scale decentralized operations with confidence
Enforce ring‑fenced visibility and management boundaries
Combine global consistency with local autonomy

For organisations planning large‑scale Purview deployments or consolidating legacy compliance tooling, Administrative Units provide a foundational architecture for sustainable growth.

Learn more

Purview Integration during Merger and Acquisitions

arunsekaran — Thu, 16 Apr 2026 17:33:54 GMT

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; }

Hello,

We are currently in the process of merging with two other organizations and are looking to integrate our Microsoft Purview environments.

All three organizations have different sensitivity labeling schemes, and we would like guidance on the best approach to achieve a unified labeling strategy across the merged organization.

Specifically, should we create a new, common set of sensitivity labels for the combined organization and plan a phased transition for users? One of the organizations already has the majority of its documents labeled, so maintaining those existing labels during the merger is a key concern.

We are also looking for best practices to ensure that existing labels are preserved when the two additional organizations are onboarded into Purview, while still moving toward a consistent, unified labeling framework.

Any suggestions or if any one had already been a part of such a merger, please share your experience

Purview DLP Behaviours in SharePoint and OneDrive

manojviduranga — Wed, 15 Apr 2026 14:53:11 GMT

We are currently testing Microsoft Purview DLP policies for user awareness across SharePoint Online, and OneDrive. The policy is configured such that sensitive information (based on a sensitivity label-OFFICIAL Sensitive) shared externally triggers a policy tip, with override allowed (justification options enabled) and no blocking action configured.

In SharePoint Online and OneDrive, users are not experiencing any DLP-related behaviour. When attempting to share labelled content externally:

No policy tips are displayed
No override prompts are presented
No indication of DLP enforcement is shown

Users are able to share content externally without any awareness prompt or restriction.

Sharing in OneDrive/SharePoint

Expected behaviour:

Users should receive a policy tip during the sharing process
Users should be prompted for justification when overriding, aligned with the DLP configuration

Has anyone observed similar behaviour with DLP in SharePoint Online and OneDrive, particularly in scenarios where no blocking action is configured? Keen to understand if this is expected behaviour, a known limitation, or if there are any configuration considerations or workarounds to achieve a consistent user experience across workloads.