Scaling classification and labeling: an interactive reference architecture update
In April, I published a set of referential architecture diagrams for Microsoft Purview — Microsoft Purview Referential Architecture Diagrams. They have been useful in workshops and training sessions for a simple reason: one picture is worth a thousand words - attempting to explain the complex in a single image. Today I'm publishing an update focused on classification and labeling — and on the wave of public previews that make auto-labeling something you can scale across the entire estate with ease. ➡️ Download the interactive architecture on GitHub here. It's a self-contained HTML file - and it's a lot more than this picture! Why now: auto-labeling scales to the whole estate The most consequential change is surprisingly small. An auto-labeling policy can now be kept on while you edit it, without re-triggering simulation. Anyone who has run auto-labeling at scale knows why that matters. Until now, tuning a policy meant turning enforcement off, re-simulating, waiting, and turning it back on — delays every time you refined a rule. That friction made it challenging for organizations from broadening scope as fast as they wanted to. Removing it changes the operating model: you can simulate once with your conditions and expand scope (sites) when you're ready, without hitting the simulation limit. It arrives alongside a set of previews that lift every ceiling that used to cap the motion: Capacity is up 5x. Auto-labeling for SharePoint and OneDrive moves from 100,000 to up to 500,000 files per tenant per day (Roadmap ID 567890). Simulation goes from 4M to 20M items, so you can model against a real estate rather than a sample. Policy scope gets much bigger. Select up to 1,000 individual SharePoint sites per policy, adaptive scopes support up to 50,000 sites, and you can filter sites by the SiteTemplate property when configuring a policy (Roadmap ID 570445, MC1469958). Reporting finally tells you what happened. Audit and reporting now summarize the sensitive information types detected when labels are applied, and a new 30-day chart shows files processed per day so you can watch policy throughput. A per-policy coverage report correlates files processed during enforcement to the latest simulation run — including the files that enforcement processed but simulation never saw (Roadmap ID 568935). SharePoint library default labels now reach data at rest, applying the library's default label to existing files instead of only new or edited ones (Roadmap ID 559105, MC1477181). Read together, these are one story: classify and label the whole estate — unblocking your Microsoft 365 Copilot deployment by securing the data that matters to you most. The scalability improvements are on by default, and existing policies continue to function unmodified with no end-user impact. What the architecture shows The diagram follows content through five stages, each framed as the question it answers: User input — where information originates: files, email, Teams messages, files on devices, files in transit, and prompts. Information is classified — what is it? SITs, Exact Data Match, named entities, document fingerprinting, trainable classifiers, and AI classifiers, with automatic (in-transit) and on-demand (at-rest) classification as the two entry paths. Labeling files — what is the default security posture, and what did the user intend? Five labeling methods — default label from policy, client-side, library default, service-side auto-labeling, and manual — all converging on one node: the label is applied. Protection — what do we do about it? DLP (including DLP for Copilot), encryption and usage rights, permissions, label inheritance on Copilot responses, Adaptive Protection, and retention. Insights — what did we learn? DSPM, Activity and Content Explorer, the unified audit log, DLP alerts, and Insider Risk alerts. How to use it - it's interactive! It's a single self-contained HTML file — no dependencies or API call — it works offline. Click any node to light up its full upstream and downstream path; everything unrelated dims. The detail panel then shows what it feeds from, what it feeds into, what it sees, what it can do, and — the section I'd argue matters most — what it can't do. Explain runs three guided walkthroughs: Classification vs labels, When is it classified?, and How is it protected? These are my go-to openers for a workshop. Isolate layer cuts the diagram by control plane — sensitivity label, SITs, classifiers, DLP, encryption, permissions, retention, audit. Licensing lens filters to Included in E3, E5 only — the delta over E3, or Pay-as-you-go. Use it to answer entitlement questions honestly: where Microsoft publishes no SKU, the node says so instead of guessing. Always confirm entitlements on a quote, not from a diagram. Overview only strips to titles for a clean read; Fit to width scales the whole thing to the window; light/dark follows your OS or the toggle; it prints cleanly to PDF. Keyboard: Tab between nodes, Enter to select, Esc to reset. Auto-labeling at scale If you're standing up auto-labeling at scale, confirm the prerequisites node first — sensitivity labels enabled for Office files in SharePoint and OneDrive, PDF support enabled separately via EnableSensitivityLabelForPDF, auditing on (simulation requires it), labels published to at least one user, and label scope covering Files and/or Emails. Simulate on your priority sites, review, enforce, then expand scope to more sites or all sites and keep going. Combine that with capabilities already GA — labeling files contextually by site + file types, and overriding manually applied labels — and you can finally clear the backlog of unlabeled files. note: more to come soon for a full deployment guide. Feedback welcome — if a node is wrong, missing a limitation, or missing a link, tell me in the comments and I'll fix it in the next revision.
Troubleshooting playbook for Auto labelling in SharePoint and OneDrive
Auto-labeling policies are how most organizations label the backlog of files at rest, and with the tenant ceiling now up to 500,000 files a day, more teams run them at scale. When a policy doesn't label what you expect, the cause is almost always a missing prerequisite, simulation behavior or the label-precedence rules. I've put the field fixes in one place: run the checklist, find your symptoms, apply the fix. Scope: SharePoint and OneDrive, with Exchange differences called out. How service-side auto-labeling works Auto-labeling policies run in the service, not in Office apps. A policy (label + rules + scope) must complete at least one simulation; once it's on, SharePoint and OneDrive label matching files at rest, up to the tenant's daily maximum. Figure 1. Service-side auto-labeling lifecycle and where to look when it stalls Pre-flight checklist Missing any one of these typically makes a policy run without labeling anything, and without an error. E5/P2-tier license (Microsoft 365 E5, E5 Compliance, E5 Information Protection & Governance, or AIP P2) PDF support enabled if PDFs are in scope (EnableSensitivityLabelforPDF = True) Compliance Administrator or Information protection or Compliance Data Administrator role (Data Classification Content Viewer to preview matches) Label published to at least one user, scoped to “Files & other data assets”, and not a parent label Auto-labeling available in your region (the page is visible in the Microsoft Purview portal) Encrypting labels use “Assign permissions now” and never expire; no S/MIME Unified audit log turned on (required for simulation) When files are created or edited with SIT, they are classified immediately. However, corner cases to check include Custom SIT created or edited after the file’s last change, and New SIT requiring old files to be checked again; these require on-demand classification. Sensitivity labels enabled for SharePoint/OneDrive files (EnableAIPIntegration = True) OneDrive accounts associated with their users (detached accounts aren’t supported) Limits that matter (October 2026) Setting or limit October 2026 value Auto-labeled files per tenant per day 500,000, shared by all SharePoint/OneDrive policies (was 100,000; rolling out, MC1461154) Auto-labeling policies per tenant Up to 100 policies Explicitly selected locations per policy 1,000 SharePoint sites (was 100) SharePoint adaptive scope Up to 50,000 sites (configure with PowerShell) Simulation size and duration Up to 20,000,000 matched files (was 4M; MC1469958); ~12 h target New policy provisioning ~24 h before Turn on / Edit / Delete are available View coverage report 30 days after the latest simulation completes Library defaults → existing files 1 policy per tenant, up to 10 sites Also rolling out: editing an active policy without returning to simulation, Site Template filtering, detected-SIT summaries and a 30-day files-processed chart (MC1469958), the per-policy coverage report (MC1456609), and library default labels for existing files (MC1477181). If your tenant still shows the older values, the rollout hasn't reached it yet. Symptom-to-fix triage Symptom Likely cause Check → fix Group 1 Setup and access 1. Auto-labeling page missing, or a policy can't be created or saved No E5/P2-tier license; legacy portal instead of the Microsoft Purview portal; no Compliance Administrator or Compliance Data Administrator role; region not supported (backend Azure dependency). Fix the license or role; check region availability. Get-Command New-AutoSensitivityLabelPolicy confirms the cmdlet exists. “No matching database is available” on save is transient: retry; open a case only if it persists 24 h. Group 2 Simulation 2. Simulation stuck “In progress”, no results, or expired It runs as a backend search job and finishes within 24 hours. 12 hour was the old typical time with 4M limit, however after upgrading to 20M, it may now take upto 24 hours. Editing the policy mid-run can leave the status stuck; a restart from an older PowerShell session can fail before any job is created. Check TestModeStatus and LastSimulationCompletionDate; restart from a search-only session (Toolkit A), one policy at a time, no portal edits during the run. Results usually start within 24 h; open a case if matches haven't moved 48–72 h after restart. 3. Simulation finishes with zero matches and no error Missing pre-flight item; scope misses the content; rule too strict (confidence, instance count, AND/OR logic, unpublished classifier); files unchanged since the SIT was created or edited; “Document property is” needs exact managed-property values (no regex; values with “&” may not match). Walk the checklist; confirm the SIT exists in Content explorer; test with a new sample file in an in-scope site; run on-demand classification for older files, then rerun. 4. Simulation results incomplete or different after turn-on (also alert storms, duplicates stuck in simulation, Items to review not loading) Simulation is per policy and point-in-time. It considers the file's existing label but no other policies. Files edited after the run are missed, and Matched items is a sample estimate. Duplicates start in simulation, and Items to review shares DLP's test-mode surface. List all policies on the same locations or labels and rerun after editing. Above 20,000,000 matches, narrow the scope and rerun. Pause alert policies during simulation, set a duplicate's mode explicitly, and retry Items to review a few hours later. 5. Turn on, Edit or Delete greyed out; no content preview Still provisioning (~24 h after creation); turn-on needs Compliance Administrator or Compliance Data Administrator; more than 20M matches. Preview needs Data Classification Content Viewer, which Global Admins don't have by default. Wait 24 h and refresh; assign the role (for preview, e.g. the Information Protection Investigators role group); narrow the policy and restimulate. Group 3 Turn-on and labeling 6. Policy on, but nothing labeled and no failures Mode isn't Enable yet (still TestWithoutNotifications, or a scheduled turn-on hasn't happened; a displayed date isn't confirmation); distribution incomplete; label unpublished; files open or checked out; content out of scope. Run Get-AutoSensitivityLabelPolicy … | fl Mode,DistributionStatus and -IncludeProgressFeedback; check the Insights tab and Activity explorer. Allow 24 h; open a case at 48 h if every check passes. 7. Matched files not labeled after turn-on SharePoint/OneDrive couldn't apply the label, so the file keeps its old label or none or user might have labelled manually. Overview > Labeling failures card (top 3 reasons, 30 days) > Labeling failures tab > file > Details > Failure reason. Many files, same code? Check service health first, then check the failure-code table. Another way is checking history of the file through activity explorer. 8. PDFs not labeled PDF support is off, so matching PDFs aren't sent for labeling: skipped silently, with no failure and no error. Check: Get-SPOTenant | fl EnableSensitivityLabelforPDF. Enable via the “Protect PDFs with Auto-labeling” banner or Set-SPOTenant -EnableSensitivityLabelforPDF $true (per geo in multi-Geo). Signed PDFs unsupported. Still unlabeled when enabled? Open a case. 9. Encrypting label fails, or output looks different SharePoint/OneDrive policies need “Assign permissions now” with no expiry; S/MIME labels can't be auto applied. By design: no headers, footers or watermarks on documents; the RMS issuer/owner is the last modifier. Run Get-Label -Identity <label> -IncludeDetailedLabelActions | fl; switch to a compliant label. Also, by design: removing an encrypting label removes the encryption. Set expectations before rollout. Group 4 Label outcomes 10. Library default label vs. SIT-based auto-labeling — which label wins? Two mechanisms target the same file, and label priority decides. A library default overrides a lower-priority automatically applied label, but never a manually applied one. An auto-labeling policy replaces a default label only with a higher-priority label. Compare priorities (Get-Label | ft Name,Guid,Priority) and check how the file's label was applied (Activity explorer). Contact Support only if the higher-priority label doesn't win. 11. Existing label not replaced, or replaced unexpectedly Manual labels stay unless “Replace manually applied labels with lower priority” is on. Automatic or default labels are replaced only by a higher-priority label. Within one parent, the highest-order sublabel wins. Check how the label was applied (Activity explorer); compare priorities (Get-Label | ft Name,Guid,Priority); review overlapping policies. Only a remove-label policy leaves files unlabeled. 12. Relabel files from an old label to a new one The policy UI has no “current label” condition, so use one policy per mapping with the advanced rule “Document property is” InformationProtectionLabelId = <source label GUID>. The target must outrank the source; also turn on the manual override if the old label was applied manually. Simulate on a small scope first; don't remove the old label first. 13. Too many wrong labels (false positives) The rule is broader than the data: low confidence or instance count, loose AND/OR logic, or a classifier that doesn't fit. Pause expansion; sample matches with their detected SITs. Raise confidence and counts, AND multiple SITs, tune a custom SIT, add location or file-type conditions, or split policies; then restimulate. Group 5 Scale and scope 14. New limits or preview features not showing yet; planning against old limits Limits rose in Sept–Oct 2026 (500K files/day, 20M simulation, 1,000 sites) and are rolling out tenant by tenant. Editing an active policy without re-simulating is also rolling out. Previews and limit increases reach tenants in waves, so check the prerequisites and the Message center rollout dates. Track progress with View coverage, a link on the policy that opens a Sankey chart of labeled, pending, failed and not-processed files. It's available for 30 days after the latest simulation completes (LastSimulationCompletionDate) and greys out after that until you rerun simulation. 15. Fewer files labeled per day than expected 500,000/day is a tenant maximum shared by all active SharePoint/OneDrive policies: not per policy, not guaranteed, and 100,000 until the rollout reaches you. Failures cut throughput. Check the 30-day files-processed chart and -IncludeProgressFeedback; fix dominant failure codes first; collect several days of evidence before opening a case. 16. Site in the adaptive scope, but existing files not labeled Scope membership doesn't backfill files unchanged since the SIT was created or edited. Confirm membership and that the scope is attached to the policy. Test a new, a modified and an unchanged file: only unchanged missed → on-demand classification; new or modified missed → open a case. 17. Library default label missing on pre-existing files Library defaults apply only to new and edited files. Existing files need the auto-labeling option that applies library default labels to existing files (no content inspection). Confirm the library has a default label and the site is in scope. Limit: one such policy per tenant, up to 10 sites; work in batches. Open, checked-out, locked, unsupported or unsupported-encrypted files are skipped; open a case only if none apply. 18. Some files are never labeled At rest, only .docx, .pptx, .xlsx and PDF are supported. Open files, list-item attachments and 0-byte files can't be labeled. Exchange labels the email, not the attachments. By design, no workaround; submit format requests as product feedback. Reading Labeling Failure Codes Group Codes What to do Retried automatically FileLocked, FileCheckOut, GetTagsFailure, RmsUnavailable, Conflict, Transient, UnauthorizedAccessException, TransientErrorStorageConnection, GenericException, SqlThrottled, Unknown_SPException No action; monitor “Spikes of SqlThrottled, TransientErrorStorageConnection or Unknown_SPException” often match a service incident; contact Support if Unknown_SPException repeats for the same files. Needs your action EncryptedFileNotSupported (remove password or non-Microsoft encryption) · DisabledOrUnsupportedLabel (publish or activate the label) · InvalidFileName (rename or shorten) · CancelledByEventHandler (review custom SharePoint event receivers) · QuotaExceeded (free space or raise the quota, then rerun) · UnsupportedFileType (enable PDF labeling; with PDF support off, PDFs may not appear here at all) Fix is let the policy retry. Until then, the file keeps its previous label or stays unlabeled. By design CannotOverrideCurrentLabel (equal or higher-priority label already present) FileNotSupported / FileExtensionNotSupported · ZeroByteFile · DirectoryNotFound / FileNotFound (deleted or moved after classification) Nothing to fix. PowerShell toolkit A · Restart a stuck simulation (ExchangeOnlineManagement 3.9.0+) Update-Module ExchangeOnlineManagement Connect-IPPSSession -EnableSearchOnlySession Get-AutoSensitivityLabelPolicy -Identity "<policy>" -IncludeTestModeResults $true | Format-List Set-AutoSensitivityLabelPolicy -Identity "<policy>" -StartSimulation $true B · Distribution and progress Get-AutoSensitivityLabelPolicy -Identity "<policy>" -DistributionDetail | Format-List Mode,DistributionStatus,DistributionResults Set-AutoSensitivityLabelPolicy -Identity "<policy>" -RetryDistribution # only if distribution failed; one policy at a time Get-AutoSensitivityLabelPolicy -Identity "<policy>" -IncludeProgressFeedback # to label / labeled in last 7 days / total C · Labels and tenant settings Get-Label | Format-Table Name,Guid,Priority Get-Label -Identity "<label>" -IncludeDetailedLabelActions | Format-List Get-SPOTenant | Format-List EnableAIPIntegration,EnableSensitivityLabelforPDF # SharePoint Online Management Shell Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled # Exchange Online PowerShell Error “Failed to create job. Please close the current PowerShell session and open a new session using Connect-IPPSSession with the -EnableSearchOnlySession flag. This requires using ExchangeOnlineManagement v3.9.0 or higher.” (it may appear only after a timeout) means this case. Before you open a support case Open it promptly, because diagnostic data is retained only for a limited time. Include: Tenant ID Labeled, pending and failed counts for the same window Policy name and GUID (shown in the portal URL), mode, and the UTC time it was turned on or last edited Failure codes with 3–5 example file URLs Label GUID, priority and encryption settings Output of the toolkit cmdlets Rule logic (SITs/classifiers, confidence, counts) and scope (sites or adaptive scope) Service health check result Latest simulation match count and LastSimulationCompletionDate Expected vs. observed behavior and business impact Good to know - Auto-labeling doesn't change existing Modified, Modified By or date values, in simulation or when labels are applied. Learn more Automatically apply a sensitivity label to Microsoft 365 data — https://learn.microsoft.com/en-us/purview/apply-sensitivity-label-automatically Resolve auto-labeling failures in SharePoint and OneDrive files — https://learn.microsoft.com/en-us/troubleshoot/microsoft-365/purview/sensitivity-labels/auto-labeling-failures-sharepoint-onedrive Review simulation results for auto-labeling policies — https://learn.microsoft.com/en-us/purview/auto-label-simulation-results Use the Insights tab to analyze auto-labeling policies — https://learn.microsoft.com/en-us/purview/auto-label-insights-tab Enable sensitivity labels for files in SharePoint and OneDrive — https://learn.microsoft.com/en-us/purview/sensitivity-labels-sharepoint-onedrive-files Configure a default sensitivity label for a SharePoint document library — https://learn.microsoft.com/en-us/purview/sensitivity-labels-sharepoint-default-label Set-AutoSensitivityLabelPolicy — https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-autosensitivitylabelpolicyMeet the New Microsoft Purview Classifiers Experience: Your Admin Playbook for Public Preview
Microsoft Purview Unified Classification Management Experience Feature overview and administrator playbook Overview The new Classifiers experience brings supported Microsoft Purview classification types into one place where administrators can discover, create, inspect, and manage classifiers. It adds practical visibility into classified-item counts and policy dependencies so administrators can make more informed, lower-risk changes. Why this experience is important Classification underpins data protection, data loss prevention, and data security. As classifier inventories grow, administrators need a consistent way to understand what exists, where it is used, and what could be affected by a change. Centralized visibility Search and filter supported classifiers from a unified inventory instead of navigating separate management locations. Safer change decisions Review classified-item counts and affected policies before editing or deleting a classifier. Stronger governance Establish clear ownership, testing, approval, validation, and review expectations. Better coverage analysis Use matched-item information and Data Explorer to understand where classifications occur and where gaps may exist. What administrators can do Discover supported classifier types and understand what the organization already uses. Create classifiers from a single entry point with type-specific preparation guidance. Review classified-item counts and inspect policies that depend on a classifier. Validate matched items across supported data sources and investigate unexpected coverage. Access Classifiers through Information Protection, Data Loss Prevention, or Data Security Posture Management, depending on tenant availability. Supported classification capabilities include sensitive information types, named entities, Exact Data Match, trainable classifiers, credentials, document fingerprinting, optical character recognition, and on-demand classification. How the experience can help Reduce context switching: Use one inventory to find and inspect supported classifiers. Understand impact earlier: Identify policy dependencies before a change reaches enforcement. Improve accountability: Connect classifiers to business owners, policy owners, and reviewers. Standardize operations: Apply the same lifecycle to routine maintenance, quality improvements, and retirement decisions. How the admin playbook helps The companion playbook turns the preview into a practical operating guide. It is designed to be the first place an administrator goes to understand the value of the experience and apply it safely. Explains the administrator value of unified classifier management. Provides a continuous Inventory Offers a decision guide for selecting an appropriate classification method. Shows how to review policy impact and validate matched items. Includes customer scenarios and answers to common licensing, permissions, and coexistence questions. INVENTORY → ASSESS → TEST → APPROVE → CHANGE → VALIDATE → REVIEW Resources Public documentation Current availability, permissions, supported classification capabilities, and product guidance. Administrator playbook A self-contained, interactive guide with workflows, screenshots, scenarios, and FAQs.Microsoft Purview Referential Architecture Diagrams
Microsoft Purview architecture diagrams provide a reference view of how classification, sensitivity labelling, Data Loss Prevention (DLP), Insider Risk Management, and Microsoft 365 Copilot protections work together across Microsoft 365 workloads. They illustrate how organisations can consistently identify, label, and protect sensitive data across endpoints, email, collaboration services, browsers, and AI‑assisted workflows—without prescribing a single deployment model. Classification generates sensitivity signals, labels express organizational protection intent, and DLP enforces that intent in real time across devices, apps, and services. Together, these patterns show how Copilot inherits existing security controls so AI‑generated content remains governed within the same compliance boundaries as organizational data.Close the gaps: layered data protection with Microsoft Purview across endpoint, browser, and network
Three layers that work like a good team and slides to show it Data Loss Prevention (DLP) is not new, many use it daily without ever even knowing it, but with AI bringing faster results for productivity so does the risk of data leakage. That is where we take a layered approach, meeting the end user exactly where they are working, on a device, or in a browser, or through that cute cat Office add-in that had to be installed. But don't think of layered protection as three products but more as three specialists who are each excellent at their own job and have the good sense not to try doing everyone else's. Endpoint DLP lives on the device. USB and removable media, clipboard, print, restricted apps. It carries the deepest classification support, EDM, fingerprinting, OCR, and it works offline, which turns out to be more useful than it sounds at 30,000 feet. Browser Data Security lives in the session, inline in Edge for Business, checking content before an upload or a form submission. It is the most precise layer for AI prompts and for activity happening inside a managed web app, where nothing else is standing close enough to help. Network Data Security lives on the wire, via Entra Global Secure Access or a third-party SASE. It handles traffic that never touches a browser at all, desktop apps, Office add-ins quietly phoning a friend, and it is the layer that supports inbound classification of content coming back from cloud and AI apps. Each one has natural technical boundaries, and those are a design decision rather than an oversight. A network proxy is never going to have strong opinions about a USB stick. An endpoint agent is not positioned to unwrap an encrypted API call from a third-party add-in. Ask any one of them to cover all three domains and you would end up with something slower and less capable at each. Deployed together, though, the edges line up rather nicely. That is the entire premise of layered protection, and it is what I built this asset to show. What is actually in the slides A coverage view across all three layers. Common activities — removable media, RDP sessions, add-in API calls, in-session copy and paste, inbound AI content, classification depth, inline prompt inspection — matched to the layer best positioned for each. Six scenario walkthroughs. Realistic situations traced attempt by attempt, including one determined individual who tries three separate routes to get the same file to a consumer AI service. A departing employee and a USB drive. A contractor on a personal laptop. Files headed to personal cloud storage. Each shows which layer engages, and why. Deployment flows you can follow. Prerequisites, permissions, policy names, conditions, actions. Both browser patterns (managed device with unmanaged apps, unmanaged device with managed apps) and both network paths (Entra GSA, and third-party SASE including Netskope and iBoss). Four reference architectures. Traffic flow diagrams for each browser and network model — what gets evaluated, where the Purview verdict comes from, where enforcement lands. Collection policies explained thoroughly. The unsung plumbing underneath all of it. Anatomy, the full flow from event source to Activity Explorer, Insider Risk Management, eDiscovery, and Data Security Posture Management (DSPM), plus the operational details that are much nicer to learn about in a deck than in production. The parts people keep coming back to The coverage view is usually where planning conversations start. It gives everyone a shared picture of what is deployed today and what a sensible next step looks like; adding the browser layer to an existing Endpoint DLP footprint, say, or bringing in the network layer to extend coverage to add-ins and desktop apps. The scenario walkthroughs are where it tends to click for a wider audience. Following one situation through several routes and watching a different layer step in at each turn, does more for the story than any static diagram I have drawn. And the deployment flows are genuinely meant to be executed. Everyone is written to run against a pilot group first, with Conditional Access in report-only mode in production until you have confirmed the behavior. Please do that part. Your future self will appreciate it. Who it is for Architects scoping a deployment. Partners running workshops. Admins with Endpoint DLP already humming along who are working out what comes next. Anyone who would like a single starting point instead of a browser window that has stopped showing page titles. Take whatever is useful. Pull individual slides into your own narrative or run the whole thing end to end it was built to be borrowed. Things to keep in mind Several capabilities in here are in preview or Pay-As-You-Go backed, and network-layer coverage depends on supported SASE/SSE integrations and how traffic is routed. The deck flags this as it goes. Check current availability on Microsoft Learn, and with your SASE provider for the network layer. Now the fun The full slide set is at https://aka.ms/purviewlayeredprotection. It is a living reference, and it will keep evolving with the product. If it helps you plan something, or if there is a scenario you would like to see in the next version, I would love to hear about it.Extend Microsoft Purview data protection to AWS Bedrock agents for cross-cloud AI governance
Organizations are moving fast with AI, and many of those AI workloads are not staying in one cloud. A team might use Microsoft 365 and Microsoft Purview for governance and in addition to Microsoft Foundry they may still choose to run an AI agent on AWS Bedrock or on the Google Cloud Platform. The technical challenge is straightforward: how do you keep one consistent set of data security, governance, and compliance controls when the agent itself runs outside Microsoft Azure? This is where Microsoft Purview becomes the central policy engine for your data estate. In this post, we show why that matters and then walk through a practical example: an expense approval agent running on Amazon Bedrock, protected by Microsoft Purview Data Loss Prevention (DLP) policies. ExpenseApprovalAgent" details of the Agent blade Why Purview should be the central policy engine Most organizations do not want separate policy stacks for every cloud, every model endpoint, and every app team. That leads to duplicated controls, inconsistent enforcement, and audit gaps. The better model is to separate where workloads run from where policy decisions are made. That is the value proposition for Microsoft Purview in cross-cloud AI scenarios. Purview gives you: A consistent policy layer for sensitive information types such as credit card numbers, Social Security numbers, financial data, and other regulated content. A governance plane that can extend beyond Microsoft-hosted workloads into multi-cloud environments. A compliance framework with auditability, policy traceability, and a familiar operational model for security and compliance teams. A way to apply data-aware controls to AI interactions, not just to storage locations. In practical terms, that means the same organization that already trusts Purview to govern Exchange, SharePoint, Teams, and Copilot can use Purview to govern prompts and responses in a Bedrock-based agent as well. The key architectural shift is this: your app does not need to invent its own data policy engine. It can call Purview at the points where risk exists. What this Bedrock agent demonstrates The sample solution in this blog is a cross-cloud AI pattern: The frontend is a single-page browser-based chat app. Users authenticate with Microsoft Entra ID via MSAL. The backend runs in AWS Lambda. The model is Amazon Bedrock using Nova 2 Lite. Microsoft Purview evaluates prompts and model responses for DLP policy violations. This matters because it proves a broader point: Microsoft Purview can govern AI interactions even when the model and compute are not running in Azure. The core architecture As shown above the end-to-end flow follows this pattern: A user signs in through Microsoft Entra ID from the frontend. The frontend sends the user's access token and prompt to an API endpoint in AWS. The Lambda function exchanges that token using the On-Behalf-Of flow so Purview can evaluate under the signed-in user's identity. Purview scans the full prompt for sensitive information before the model is called. If the prompt is allowed, the Lambda function sends the request to Amazon Bedrock. Purview scans the model response before it is returned to the user. The frontend shows the result along with a Purview evaluation badge. That gives you two strong governance controls: In-line data loss prevention enforcement, which can block risky requests before they ever reach the model. Response-time enforcement, which can stop sensitive data from being returned even if a model generates it. The implementation also uses the user's identity for policy evaluation. That is important because governance decisions should reflect who is asking, not just what application is running. Why this pattern is useful for security, governance, and compliance teams There are three reasons this pattern is worth paying attention to. First, it aligns policy with risk rather than with hosting location. The compute might run in Lambda and the model might be in Bedrock, but Purview still remains the policy decision point. Second, it improves operational clarity. Security teams do not have to learn a different governance toolchain for each AI stack. They can keep using Purview concepts, policy models, and audit workflows. Third, it supports real-world adoption. Most large enterprises are hybrid and multi-cloud already. A governance pattern that only works for one vendor's runtime is not enough. Policy definition in Purview Two polices are needed to enforce DLP-a collection policy for Enterprise AI Apps and a DLP policy Collection policy 2. DLP policy Follow the steps outlined here to create the DLP policy for Enterprise AI Apps. Sample provided: purview-api-samples/DLPforCustomAIApps at main · microsoft/purview-api-samples To replicate this scenario, follow this link to the official GitHub repo: purview-api-samples/AWSBedrock at main · microsoft/purview-api-samples Once deployed, you will have: An AWS Lambda function that calls Amazon Bedrock. A browser frontend that authenticates with Microsoft Entra ID. Microsoft Purview evaluating both prompts and responses. A demo flow where safe prompts succeed and sensitive prompts are blocked. With the App and agent deployed, now comes the moment when the architectural value becomes clear. The model runtime is AWS Bedrock, but the policy decision is still coming from Microsoft Purview. Below screenshot shows the prompt containing sensitive information being blocked based on the policy evaluation by Purview. Minimal code integration requirements using the SDK Below is the code needed to perform the integration between Purview and Bedrock to perform the in and outbound inspection of content destined to and from the Bedrock model. Results of Purview’s verdict presented to user in the App UI Review governance evidence in Purview Data Security Posture Management Summary The bigger story here is not just that Microsoft Purview can protect an Amazon Bedrock agent. It is that organizations can centralize data security, governance, and compliance policy even while their AI architecture becomes more distributed across multiple clouds. That is the operational win. Developers keep the freedom to choose the best runtime and model platform. Security and compliance teams keep a central policy engine they already understand and trust. AI applications can be multi-cloud, but your data protection model does not have to be fragmented. Additional resources Configure Microsoft Purview - purview-sdk | Microsoft Learn Microsoft Purview Developer Platform Documentation - purview-sdk | Microsoft LearnEnhancements to Device Status API & Logged-In User Email in Endpoint DLP
1. The Real‑World Problem Endpoint DLP analyst Faced (What Was Missing Earlier) Before the introduction of the Device Status API enhancements and logged‑in user visibility, Endpoint DLP teams consistently struggled in below discussed areas: Device Visibility Was Fragmented and Manual - Customers repeatedly told us: We know some devices are unhealthy, but we don’t know who owns them. We export the onboarding table to Excel every week just to understand drift. By the time we detect a policy issue, the user is already blocked or impacted. In practice, this meant: Device onboarding views were static snapshots, not operationally actionable. Admins relied on manual Excel exports to track onboarding, drift, and health. Reporting pipelines were brittle and always out of date. 2. Device Status API: Why Customers Asked for This (Beyond “Reporting”) The Hidden Cost of Excel‑Driven Operations as earlier, customers had to: Export device onboarding data manually. Rebuild dashboards every time they needed updated insight. Repeat this process weekly or even daily for compliance and SOC reviews. This approach failed at scale and created blind spots during incidents. When a device policy sync failed or appeared unhealthy, admins had no real‑time, view to answer basic questions like: Is this device configured correctly? Is the OS or Defender version lagging? Is the issue widespread or isolated? 3. What the Improvement Unlocks (New Operational Reality) From Static Views to Continuous Monitoring with the Device Status API: Device health, configuration status, policy sync state, OS version, and Defender version become query able signals Customers can power custom reporting and Advanced Hunting queries that are always current SOC and Endpoint teams finally share a single source of device truth This fundamentally changes how customers monitor Endpoint DLP not as a setup task, but as a living control plane. The Device Status API directly addresses this gap by making device‑level status continuously available through Advanced Hunting, allowing customers to build living dashboards instead of static reports. 4. The Old Workflow (Customer Pain) Historically, when a device showed: Policy Sync Failed Unhealthy Configuration mismatch Admins had to: Leave the Purview console Open Microsoft Defender for Endpoint or Intune Correlate device IDs or names Identify the user Start remediation This context‑switching cost time, accuracy, and confidence. 5. The New Reality: User Context Where It Matters Admins can now see who is logged in directly on the device onboarding page, aligning Windows with the macOS experience like: Immediate user context during device issues. Faster outreach and remediation. One unified investigative surface. What used to require three portals and multiple teams now happens in One Place. 6. When Customers Actually Needed This Data (But Didn’t Have It) This improvement wasn’t driven by curiosity it was driven by failure points in production. Some of the common customer scenarios listed below: Scenario Before Now / After Improvement Scenario 1: Quarterly Compliance Reviews Teams exported Excel files days before audits, resulting in stale data. Auditors questioned the reliability of reports. Advanced Hunting queries power live compliance dashboards. Reports are defensible because the data is always current. Scenario 2: Incident Post‑Mortems Teams struggled to answer whether devices were healthy at the time of the incident or if policies were enforced versus just configured. Reviews relied on assumptions. Device status, policy sync state, and OS/Defender versions are query able facts. Incident reviews shift from guesswork to evidence‑based analysis. Scenario 3: Silent Policy Drift Devices drifted due to OS updates, sensor lag, or configuration changes. Issues surfaced only after a DLP violation occurred. Policy drift becomes detectable before enforcement failures. Endpoint DLP acts as a reliability signal rather than a last‑line alarm. 7. New enhancement on Device Status API Device status API provides admins with access to device level information to integrate onboarded device information to custom reporting or use in advanced hunting queries. It has helped admins track down users associated with devices instead reaching out to Entra, on-premises Active Directory, or Intune team. During troubleshooting, if a device is not receiving policies on time, the device API allows quick identification of the device owner and assists in enabling always-on diagnostics or collecting logs directly from the device via Purview console. 8. Steps to capture User UPN Admin can find the device status by login to Security.microsoft.com as security admin. Click on Investigation and responses > Hunting > Advanced hunting. Device data can be found under DLPInfo JSON Column in the Deviceinfo table 3. Once we run above or any custom query as per requirement, you would see below as response. 4. Click on the loggedonuser field and expand the right-side information and look for DLPUPN under inspect record. 9. User login details on the Purview onboarding page Admins now can see who is currently logged in on the device onboarding page. This update aligns the Windows experience with macOS, allowing admins to respond quickly if necessary. In the past, when a device displayed a "Policy Sync Failed" or "Unhealthy" status, it was necessary to switch to Microsoft Defender for Endpoint (MDE) or Intune to identify the affected user. With this update, all relevant information is now accessible in a single view, streamlining the process. Benefits - Admins gain faster confirmation of device ownership and user context without extra investigation. It simplifies troubleshooting onboarding or policy issues by surfacing the user alongside other device insights like status and IP. No impact on users or DLP policies occurs, and it's enabled by default with no action required. 10.Steps to find User UPN on Purview admin console Login to Purview.microsoft.com with compliance admin > Select settings > Device onboarding > Select device Final Takeaway: Why This Matters More Than It First Appears "These enhancements evolve Endpoint DLP from a static, deployment‑centric control into a continuously observable, user‑context aware security signal, significantly reducing investigation time, operational overhead, and trust gaps at scale"
Set Up Endpoint DLP Evidence Collection on your Azure Blob Storage
Endpoint Data Loss Prevention (Endpoint DLP) is part of the Microsoft Purview Data Loss Prevention (DLP) suite of features you can use to discover and protect sensitive items across Microsoft 365 services. Microsoft Endpoint DLP allows you to detect and protect sensitive content across onboarded Windows 10, Windows 11 and macOS devices. Learn more about all of Microsoft's DLP offerings. Before you start setting up the storage, you should review Get started with collecting files that match data loss prevention policies from devices | Microsoft Learn to understand the licensing, permissions, device onboarding and your requirements. Prerequisites Before you begin, ensure the following prerequisites are met: You have an active Azure subscription. You have the necessary permissions to create and configure resources in Azure. You have setup endpoint Data Loss Prevention policy on your devices Configure the Azure Blob Storage You can follow these steps to create an Azure Blob Storage using the Azure portal. For other methods refer to Create a storage account - Azure Storage | Microsoft Learn Sign in to the Azure Storage Accounts with your account credentials. Click on + Create On the Basics tab, provide the essential information for your storage account. After you complete the Basics tab, you can choose to further customize your new storage account, or you accept the default options and proceed. Learn more about azure storage account properties Once you have provided all the information click on the Networking tab. In network access, select Enable public access from all networks while creating the storage account. Click on Review + create to validate the settings. Once the validation passes, click on Create to create the storage Wait for deployment of the resource to be completed and then click on Go to resource. Once the newly created Blob Storage is opened, on the left panel click on Data Storage -> Containers Click on + Containers. Provide the name and other details and then click on Create Once your container is successfully created, click on it. Assign relevant permissions to the Azure Blob Storage Once the container is created, using Microsoft Entra authorization, you must configure two sets of permissions (role groups) on it: One for the administrators and investigators so they can view and manage evidence One for users who need to upload items to Azure from their devices Best practice is to enforce least privilege for all users, regardless of role. By enforcing least privilege, you ensure that user permissions are limited to only those permissions necessary for their role. We will use portal to create these custom roles. Learn more about custom roles in Azure RBAC Open the container and in the left panel click on Access Control (IAM) Click on the Roles tab. It will open a list of all available roles. Open context menu of Owner role using ellipsis button (…) and click on Clone. Now you can create a custom role. Click on Start from scratch. We have to create two new custom roles. Based on the role you are creating enter basic details like name and description and then click on JSON tab. JSON tab gives you the details of the custom role including the permissions added to that role. For owner role JSON looks like this: Now edit these permissions and replace them with permissions required based on the role: Investigator Role: Copy the permissions available at Permissions on Azure blob for administrators and investigators and paste it in the JSON section. User Role: Copy the permissions available at Permissions on Azure blob for usersand paste it in the JSON section. Once you have created these two new roles, we will assign these roles to relevant users. Click on Role Assignments tab, then on Add + and on Add role assignment. Search for the role and click on it. Then click on Members tab Click on + Select Members. Add the users or user groups you want to add for that role and click on Select Investigator role – Assign this role to users who are administrators and investigators so they can view and manage evidence User role – Assign this role to users who will be under the scope of the DLP policy and from whose devices items will be uploaded to the storage Once you have added the users click on Review+Assign to save the changes. Now we can add this storage to DLP policy. For more information on configuring the Azure Blob Storage access, refer to these articles: How to authorize access to blob data in the Azure portal Assign share-level permissions. Configure storage in your DLP policy Once you have configured the required permissions on the Azure Blob Storage, we will add the storage to DLP endpoint settings. Learn more about configuring DLP policy Open the storage you want to use. In left panel click on Data Storage -> Containers. Then select the container you want to add to DLP settings. Click on the Context Menu (… button) and then Container Properties. Copy the URL Open the Data Loss Prevention Settings. Click on Endpoint Settings and then on Setup evidence collection for file activities on devices. Select Customer Managed Storage option and then click on Add Storage Give the storage name and copy the container URL we copied. Then click on Save. Storage will be added to the list. Storage will be added to the list for use in the policy configuration. You can add up to 10 URLs Now open the DLP endpoint policy configuration for which you want to collect the evidence. Configure your policy using these settings: Make sure that Devices is selected in the location. In Incident reports, toggle Send an alert to admins when a rule match occurs to On. In Incident reports, select Collect original file as evidence for all selected file activities on Endpoint. Select the storage account you want to collect the evidence in for that rule using the dropdown menu. The dropdown menu shows the list of storages configured in the endpoint DLP settings. Select the activities for which you want to copy matched items to Azure storage Save the changes Please reach out to the support team if you face any issues. We hope this guide is helpful and we look forward to your feedback. Thank you, Microsoft Purview Data Loss Prevention TeamDeploy scalable ring‑fenced Purview operations with Administrative Units
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 Administrative units in Microsoft Purview (presentation) Administrative units in Microsoft Purview | Microsoft Learn
Priority Cleanup V2: Faster, Simpler Data Purging for Exchange Online
Enhancements Achieved with Exchange Priority Cleanup V2 Priority Cleanup (Use priority cleanup to expedite the permanent deletion of sensitive information from mailboxes | Microsoft Learn) was introduced to provide administrators with a powerful tool for permanently deleting mailbox content, even when under retention or eDiscovery hold, to address scenarios such as data spillage and urgent removals. Priority Cleanup addressed a key need in Exchange Online by allowing hold overrides. Through real-world use, we received valuable insights regarding the approval process, deletion speed, and reviewer experience. These learnings have guided our ongoing enhancements, ensuring that the solution evolves to better meet customer needs for efficiency and ease of use while maintaining robust security and compliance standards. What's New in Priority Cleanup V2 Priority Cleanup V2 is currently in the planning stage. We’re sharing the proposed updates early to gather feedback before we begin implementation. The goal is to address the core limitations of V1 with enhancements focused on speed and simplicity. Faster Data Deletion & Simplified Approval Workflow: We’re proposing to streamline the process to two key checkpoints: Policy enforcement approval when moving from simulation to active mode (requires approval from a different Priority Cleanup admin). We’re proposing to minimize approval overhead by removing unnecessary review stages. Disposition review by eDiscovery admins will be required only for mailboxes under eDiscovery hold. For other mailboxes, items will be permanently deleted soon after the Priority Cleanup policy is applied to speed up processing from days to hours. This would reduce the number of required users with admin privileges from four to two. Controlled Purge Limits: Administrators will be able to efficiently manage substantial purges by securely processing deletions in batches, with a configurable limit of up to 100 items per mailbox per ELC run. A default limit of 100 items is applied, with the ability to adjust this value through an organization‑level configuration. This configurable limit provides an additional safeguard for system operations while offering flexibility to meet varying organizational needs. Note: A default limit of 100 items will apply, with the ability to adjust this value via an organization-level configuration. V1 vs V2 Feature Comparison Feature V1 Behavior V2 Improvement Deletion Speed Multi-stage process taking 6+ days for small purges Significantly faster with immediate deletion for non-hold mailboxes Approval Workflow 3-stage approval (Priority Cleanup Admin, Retention Admin, eDiscovery Admin) 2-stage approval (policy enforcement + eDiscovery review only when needed) Proposed Improvements in Admin Experience and Control Streamlined Policy Management: We are considering making policies easier to enable or disable directly from the main list view, potentially through a simple toggle, so administrators would no longer need to use the setup wizard for this task. Enhanced Review Interface: Proposed updates include adding new, informative columns to the interface, such as a dedicated Mailbox/Site column to help identify the source location. We are also looking at providing clearly labeled date fields to indicate when items were received or created, which would replace the potentially confusing ExpiryDate label. Comprehensive Audit Trails: It is proposed that every action would be thoroughly documented with a unique Cleanup ID. This ID could then be used in Audit Search to locate all events related to a specific cleanup operation, helping to simplify verification and post-incident analysis. Note: Priority Cleanup V2 enhancements are specific to Exchange Online. These changes do not affect Priority Cleanup for OneDrive and SharePoint (PC ODSP), including its rollout timelines or behavior. Key Benefits for Administrators Priority Cleanup V2 delivers tangible improvements across the entire data purging workflow. Accelerated Deletion: Requests for data removal are fulfilled much faster, enabling urgent incidents to be resolved within hours rather than days, and minimizing risk exposure. Reduced Administrative Overhead: Coordination requirements are simplified, decreasing the number of users involved from four to two in most cases, which makes Priority Cleanup V2 more practical for smaller teams. Enhanced Transparency: Improved user interface labels and robust audit logs help administrators clearly understand what data is being deleted and who authorized the action. Maintained Security and Compliance: Segregation of duties is preserved so that no single individual can delete protected content alone, supporting security and compliance requirements. Availability and Rollout Priority Cleanup V2 is currently in development with rollout planned for the end of 2026. As with all Exchange Online features, we will publish a Microsoft 365 Roadmap item and send Message Center notifications to affected tenants before general availability We Want Your Feedback Priority Cleanup V2 represents a significant evolution based on customer feedback from V1 users who emphasized the need for faster, simpler data purging without compromising security. We've addressed the core pain points around speed, approval complexity, and admin experience, but we know there's always room for improvement. We'd love to hear your thoughts: Does the simplified approval workflow meet your security requirements? What visibility or reporting capabilities would make you more confident in using Priority Cleanup for urgent data removal scenarios? Your feedback directly shapes how we prioritize future enhancements. Please share your experiences and suggestions through your regular Microsoft support channels or customer success contacts. Together, we can continue refining Priority Cleanup to better serve your data governance needs. Aniket Gupta, Mehul Kaushik, Victor Legat & Purview Data Lifecycle Management Team
