MS Purview DLP: Web search blocking also blocks Copilot response
Hello everyone, I am currently testing a Microsoft Purview DLP policy for Microsoft 365 Copilot that is intended to prevent personal or sensitive information contained in a Copilot prompt from being used for a web search. When a user enters a prompt containing specific Sensitive Information Types (SITs), only the web search should be blocked. Copilot should still process the prompt and, if possible, provide a response without using web search or sending the detected sensitive information to the web search service. Configuration In Microsoft Purview, I only have the following actions available: Processing of prompts → Block Performing web searches → Block I tested both options separately. Behavior with “Processing prompts → Block” This works as expected: As soon as a configured SIT is detected in the prompt, processing is blocked immediately and Copilot displays a corresponding policy notification. Behavior with “Performing web searches → Block” I observe the following behavior: I send a prompt to Copilot that contains a SIT covered by the DLP policy. Copilot initially generates a normal response. In this response, Copilot indicates that the personal information was not used for the web search. However, the actual question is still answered. This response remains visible for approximately 1–2 seconds. The entire Copilot response then disappears. Instead, the following message is displayed: “Due to your organization’s policies, none of the requested files or resources are available.” The previously generated response, which was briefly visible, can no longer be accessed afterwards. Expected behavior Since I would like to use “Performing web searches → Block” in the DLP policy, I would expect that: the web search is blocked, sensitive information is not used for the web search, Copilot can still process the prompt, and the response generated by Copilot remains visible. Question Is this behavior expected when using the DLP action “Performing web searches → Block”? In particular, I would like to understand why Copilot initially generates and displays a response without using the sensitive information for the web search, but then completely removes this response a few seconds later and replaces it with the policy notification. Is it possible to configure additional actions in the DLP policy, or to select an option other than “Block”? I only have the two actions mentioned above available. I have attached the relevant screenshots. Please note that the attached screenshots are in German. Thank you in advance!
DLP Controls Not Enforced for Outlook Attachments Opened in Protected View
Good day, We are experiencing an inconsistency with Microsoft Purview Endpoint DLP enforcement and would appreciate guidance from the community. Environment Sensitivity labels: Confidential and Secret DLP policy configured to block copy and print activities Policy scope includes both Devices and Exchange Online Observed Behaviour When a labeled document is received via Outlook and opened directly from the email: The document initially opens in Protected View. If the user selects "Enable Editing" and/or "Enable Printing", the DLP controls are not enforced. The user is able to print or copy content despite the DLP policy being configured to block these actions. However, if the exact same document is first saved locally to the device and then opened from the local file system, the DLP policy is enforced correctly and the copy/print restrictions work as expected. Troubleshooting Performed As part of troubleshooting, we disabled the recommended Endpoint DLP file path exclusions for: %AppData% %LocalAppData% These locations are commonly used by Office Protected View and Outlook temporary files. Despite removing these exclusions, the behaviour remains unchanged. Question Has anyone encountered a similar issue where Endpoint DLP controls are not applied to Outlook attachments opened directly from Protected View but work correctly once the file is saved locally? Could this be related to: How Office Protected View handles temporary files? The file's classification state while opened from Outlook? Endpoint DLP monitoring limitations for transient Outlook/Office cache locations? Another known product limitation or configuration requirement? Any insights, known limitations, or recommended diagnostic steps would be greatly appreciated. Thank you.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-autosensitivitylabelpolicyScaling 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.Meet 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.
Updating Purview DLP Sensitive Service Domain Groups with PowerShell
Introduction Microsoft Purview Data Loss Prevention (DLP) can use Sensitive Service Domain Groups to organize websites and other network destinations that are referenced by endpoint DLP rules. Administrators can manage these settings in the Purview portal, while PowerShell is useful when changes must be repeatable, reviewed, and validated before they are committed. This article demonstrates how to retrieve the tenant policy configuration, identify an existing group, add new URL entries only when they are not already present, validate the change, commit it, and verify the final configuration. Important The SiteGroupsPsws object contains tenant-wide endpoint restriction settings. Test the script in a non-production tenant first, export the original configuration, and use change control. Microsoft documents Get-PolicyConfig and Set-PolicyConfig for viewing and modifying endpoint restrictions, but the internal shape of individual hashtable entries can evolve. Prerequisites Requirement Guidance Permissions Use an account assigned the required Microsoft Purview permissions for the configuration being changed. Microsoft states that Get-PolicyConfig and Set-PolicyConfig require permissions in Security & Compliance PowerShell. PowerShell module Install or update the ExchangeOnlineManagement module. Security & Compliance PowerShell uses this module for connectivity. Connection Connect to Security & Compliance PowerShell by using Connect-IPPSSession before running the policy configuration cmdlets. Existing group The target Sensitive Service Domain Group must already exist. This script updates a group named Claude; it does not create the group. Change controls Run the discovery and backup commands first, use -WhatIf before commit, and retain the exported JSON for rollback analysis. Step 1: Install the module and connect Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser Import-Module ExchangeOnlineManagement Connect-IPPSSession Confirm that the policy configuration can be retrieved: Get-PolicyConfig | Format-List Step 2: Discover available group names List the names exposed in SiteGroupsPsws and confirm that the target group exists before making any change. (Get-PolicyConfig).SiteGroupsPsws | Where-Object { $_.ContainsKey("Name") } | ForEach-Object { $_.Name } Step 3: Back up the current configuration Export the current SiteGroupsPsws representation before modifying the in-memory object. $BackupPath = ".\SiteGroupsPsws-backup-{0}.json" -f (Get-Date -Format "yyyyMMdd-HHmmss") (Get-PolicyConfig).SiteGroupsPsws | ConvertTo-Json -Depth 20 | Set-Content -Path $BackupPath -Encoding UTF8 Write-Host "Backup written to $BackupPath" -ForegroundColor Cyan Step 4: Define the target group and URLs $GroupName = "Claude" $NewUrls = @( "claude1.com", "chatgpt2.com", "claude3.com" ) Replace the sample values with the approved production URLs. Use only the domain or wildcard format supported by your DLP design. Step 5: Retrieve and validate the target group $PolicyConfig = Get-PolicyConfig $Groups = $PolicyConfig.SiteGroupsPsws $TargetGroup = $Groups | Where-Object { $_["Name"] -eq $GroupName } if (-not $TargetGroup) { $AvailableGroups = $Groups | Where-Object { $_.ContainsKey("Name") } | ForEach-Object { $_.Name } throw "Sensitive Service Domain Group '$GroupName' was not found. Available groups: $($AvailableGroups -join ', ')" } Complete script # Target Sensitive Service Domain Group $GroupName = "Claude" # URLs to add $NewUrls = @( "claude1.com", "chatgpt2.com", "claude3.com" ) $PolicyConfig = Get-PolicyConfig $Groups = $PolicyConfig.SiteGroupsPsws $TargetGroup = $Groups | Where-Object { $_["Name"] -eq $GroupName } $Addresses = $TargetGroup["Addresses"] | ConvertFrom-Json foreach ($Url in $NewUrls) { if ($Addresses.Url -notcontains $Url) { $Addresses += [pscustomobject]@{ Url = $Url MatchType = "UrlMatch" } } } $TargetGroup["Addresses"] = $Addresses | ConvertTo-Json -Compress # Validate Set-PolicyConfig -SiteGroupsPsws $Groups -WhatIf # Commit Set-PolicyConfig -SiteGroupsPsws $Groups Step 6: Verify the change Retrieve a fresh copy from the service rather than validating only the modified local object. $VerifiedGroups = (Get-PolicyConfig).SiteGroupsPsws $VerifiedTarget = $VerifiedGroups | Where-Object { $_["Name"] -eq $GroupName } $VerifiedAddresses = @($VerifiedTarget["Addresses"] | ConvertFrom-Json) $Verification = foreach ($Url in $NormalizedNewUrls) { [pscustomobject]@{ Group = $GroupName Url = $Url Present = ($VerifiedAddresses.Url -contains $Url) } } $Verification | Format-Table -AutoSize if ($Verification.Present -contains $false) { throw "Verification failed: one or more URLs were not found after the update." } Write-Host "Verification passed for all requested URLs." -ForegroundColor Green Step 7: Optional full configuration views # Writable PowerShell representation (Get-PolicyConfig).SiteGroupsPsws | ConvertTo-Json -Depth 20 # Service view (Get-PolicyConfig).SiteGroups Sample output The sample is illustrative. Actual service output and formatting can vary by module version and tenant configuration. Troubleshooting Symptom Recommended check Get-PolicyConfig or Set-PolicyConfig is not recognized Confirm that the ExchangeOnlineManagement module is installed and that the session was connected with Connect-IPPSSession. Access denied or authorization error Verify the administrator account has the required Purview role-group permissions, then reconnect after role propagation. Target group not found Run the discovery command and use the exact group name returned by SiteGroupsPsws. Addresses cannot be parsed Inspect the raw Addresses property before changing anything. Restore from the exported JSON if the object shape is unexpected. -WhatIf succeeds but verification fails Retrieve Get-PolicyConfig again, check for service-side errors, and confirm no competing administrator update overwrote the configuration. Summary PowerShell provides a controlled way to update Microsoft Purview DLP Sensitive Service Domain Groups at scale. The safest pattern is to discover the exact group name, export the current configuration, validate the target object, normalize and de-duplicate input, run Set-PolicyConfig with -WhatIf, commit the change, and then verify it through a fresh Get-PolicyConfig call. This validation-first workflow improves repeatability and reduces the risk of unintended tenant-wide configuration changes. References Get-PolicyConfig cmdlet reference https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/get-policyconfig?view=exchange-ps Set-PolicyConfig cmdlet reference https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-policyconfig?view=exchange-ps Security & Compliance PowerShell overview https://learn.microsoft.com/en-us/powershell/exchange/scc-powershell?view=exchange-ps Configure Endpoint DLP settings https://learn.microsoft.com/en-us/purview/dlp-configure-endpoint-settings
Anthropic Claude Purview Data Connector showing all users as Guests..
It appears this connector is not mapping fields properly causing internal users to be mapped as "guests", and since prompts/data isn't maintained for guest users the connector is effectively not gathering anything but noise. Unlike the other data connectors, one cannot create field mappings. Also the app being named using the guid of Microsoft's own "dataassessments" service principal I don't think is intended either. Has anybody else experienced this? See below for an example.Using Copilot in Sensitive Healthcare Teams Meetings - Without Recording or Transcription
Healthcare organizations want the productivity benefits of Microsoft 365 Copilot, but those benefits must be balanced with privacy, security, and compliance requirements. I recently worked with a healthcare customer whose compliance team was concerned about persistent meeting artifacts. They wanted users to benefit from Copilot during Microsoft Teams meetings, but they did not want every conversation recorded or a transcript available afterward—especially for meetings involving sensitive operational, workforce, legal, compliance, or patient-related discussions. Microsoft Teams provides an option that can help with this scenario: allowing Copilot only during the meeting while disabling recording and transcription. Important: This article describes a technical configuration and customer scenario. It is not legal or compliance advice. Your privacy, security, compliance, records-management, and legal teams should determine whether this configuration is appropriate for your organization and specific meeting types. Why This Matters in Healthcare Healthcare organizations conduct many meetings where the discussion may include sensitive information: Patient care coordination Quality and safety reviews Compliance investigations Workforce and employee matters Security incidents Legal or risk-management discussions Research and clinical program planning A recording or transcript can become an additional persistent information asset that must be appropriately protected, retained, governed, and eventually disposed of. The HIPAA Security Rule requires covered entities and business associates to implement reasonable and appropriate administrative, physical, and technical safeguards for electronic protected health information. This includes evaluating risk, controlling access, implementing audit controls, and periodically reviewing security measures. The U.S. Department of Health and Human Services provides an overview of these requirements here. HIPAA’s minimum necessary standard also generally calls for organizations to limit unnecessary access to protected health information, although important exceptions apply—including certain disclosures for treatment. HHS provides additional guidance on the minimum necessary requirement. Turning off recording and transcription does not automatically make a meeting compliant. However, reducing the creation of unnecessary meeting artifacts can be one useful part of a broader, risk-based healthcare data-governance strategy. Copilot Without a Persistent Transcript When a Teams meeting is configured for Only during the meeting, Copilot can use temporary speech-to-text data to understand the active conversation. A traditional meeting transcript does not need to be started. Users can ask Copilot to: Summarize what has been discussed Identify decisions List open questions Capture action items Explain areas of disagreement Help someone catch up after joining late Microsoft explains that Copilot must be manually started by a participant in this configuration. Copilot can then provide insights based on the conversation taking place while it is active. See Microsoft’s guidance for using Copilot without recording or transcribing a Teams meeting. There are two important limitations users must understand. First, Copilot does not automatically start when the meeting begins. If someone activates it five minutes into the meeting, it will not have the same context it would have had if it had been started at the beginning. Second, users should capture anything they need before leaving the meeting. Without transcription, they will not have the same post-meeting Copilot conversation history or transcript-based recap. Microsoft recommends copying any Copilot content users want to keep before the meeting ends. Watch the Complete Walkthrough In the following video, I demonstrate the user experience, the corresponding Teams administrative policies, the Facilitator consideration, and several lessons I learned while implementing this for a healthcare customer. How to Use Copilot in Teams Without Recording or Transcription: Admin Setup & Gotchas The Administrative Configuration For this scenario, the goal was to create a scoped Teams meeting policy that: Prevented users from recording meetings Prevented users from starting transcription Allowed Copilot to operate during the meeting Avoided enabling a transcript-dependent post-meeting Copilot experience The settings are managed through Teams meeting policies in the Teams admin center. In the video, I walk through the relevant recording, transcription, and Copilot controls and show the resulting experience from a user’s perspective. For a healthcare organization, I would normally begin with a limited population instead of immediately applying a new policy globally. A pilot group gives the organization an opportunity to test the technical behavior and evaluate it with stakeholders from: Privacy and compliance Information security Legal and risk management Records management Clinical or operational leadership Microsoft 365 administration End-user training and adoption The appropriate configuration may differ between clinical, administrative, research, legal, HR, and general collaboration scenarios. A single organization-wide meeting policy may not be the right answer for every healthcare meeting. “No Transcript” Does Not Mean “No Compliance Data” This distinction is critical. Although participants may not receive a traditional meeting recording or transcript, Copilot prompts and responses can still be subject to Microsoft Purview retention policies. Depending on the organization’s configuration, those interactions may also be discoverable through Microsoft Purview eDiscovery. Microsoft explicitly notes that Copilot prompts and responses may be retained for compliance purposes even when recording and transcription are disabled. Microsoft’s Purview training covers auditing, retention, eDiscovery, and compliance controls for Copilot interactions. Healthcare organizations should therefore evaluate more than the visible Teams recap. The governance review should include: Copilot interaction retention Microsoft Purview Audit eDiscovery requirements Data Loss Prevention policies Sensitivity labels Records-management obligations Access to saved notes or exported Copilot responses Organizational policies governing the entry of PHI into AI-assisted experiences The user experience may feel temporary, but the organization’s compliance controls can still operate behind the scenes. The Lesson We Almost Missed: Facilitator Still Creates Loop Artifacts This was one of the most important lessons from my recent engagement. While working to Copilot to operate only during the meeting. Recording was disabled, transcription was disabled, and users did not receive the traditional transcript-based recap we were trying to avoid. But Loop files were still appearing. That initially seemed inconsistent with the policy design. After investigating, we discovered that the files were not being created by the personal Copilot experience—they were being generated because Microsoft Facilitator was enabled. This distinction is easy to miss: Copilot only during the meeting gives an individual user private, real-time assistance without requiring a persistent transcript. Facilitator is a shared meeting agent that can generate collaborative notes and other meeting artifacts. Microsoft documents that Facilitator’s meeting data is stored as a .loop file in the Meetings folder of the OneDrive account belonging to the user who initiated Facilitator. The data is treated as meeting transcript data for governance purposes. Facilitator notes may also be available to meeting participants through Notes and the meeting recap. Microsoft documents Facilitator’s behavior, storage, and administrative controls here. For a healthcare organization, that Loop file is not simply a convenient set of notes. Depending on what was discussed, it could contain sensitive operational information, workforce information, security details, or protected health information. It becomes another persistent artifact that must be considered in the organization’s access, sharing, retention, eDiscovery, lifecycle-management, and data-protection strategy. Copilot and Facilitator Require Separate Governance Decisions Disabling recording and transcription while allowing Copilot during the meeting does not automatically prevent Facilitator from producing shared meeting content. Healthcare organizations should make separate decisions about: Whether users should have access to Copilot during meetings. Whether users should be allowed to initiate Facilitator. Which meeting types are appropriate for shared AI-generated notes. Which users or groups should be allowed to use Facilitator. How the resulting Loop files should be stored, accessed, retained, labeled, and disposed of. Facilitator can be extremely useful for approved operational meetings where collaborative notes, decisions, and follow-up actions are valuable. However, it may not be appropriate for every sensitive clinical, compliance, legal, HR, or incident-response meeting. Microsoft allows administrators to control whether Facilitator is available across the organization or only to selected groups of users through Teams app policies and app-centric management. One important administrative nuance is that access to Facilitator can be scoped, while Microsoft’s control for turning off AI-generated meeting notes is currently tenant-wide rather than user-specific. That makes intentional scoping particularly important. Instead of assuming every Copilot-licensed user should also be able to initiate Facilitator, organizations can identify the populations and meeting scenarios where persistent collaborative notes have a defined business purpose and an approved governance model. The practical lesson is simple: If your goal is to use Copilot without creating persistent meeting artifacts, do not stop after validating the recording, transcription, and Copilot policies. Verify whether Facilitator is enabled and inspect the resulting Loop behavior as part of your testing. The Meeting Option That Can Cause Confusion and Broke Things For Us One of the most important lessons from this implementation involved the meeting organizer’s Copilot setting. If an organizer changes the meeting from Only during the meeting to During and after the meeting, Copilot expects transcription to be available. If the organization’s policy prevents transcription, the user may receive an error indicating that Copilot cannot access the meeting. From the user’s perspective, that can look like a licensing problem or a broken Copilot deployment. In reality, it may simply be a mismatch between: The organization’s transcription policy The Copilot meeting option selected by the organizer The type of Copilot experience the user is attempting to start Microsoft’s meeting guidance confirms that During and after the meeting requires transcription, while Only during the meeting can operate without it. Review the current Copilot behavior in Microsoft Teams meetings. This is why user education is just as important as the policy itself. A Healthcare Deployment Checklist Before introducing this configuration more broadly, consider the following: Classify the meeting scenarios. Determine where in-meeting Copilot is appropriate and where AI assistance should be restricted entirely. Engage compliance early. Validate the design with privacy, security, legal, records-management, and compliance stakeholders. Use scoped policies. Pilot with specific users or groups before considering a broader rollout. Review more than recordings and transcripts. Evaluate Purview retention, auditing, eDiscovery, DLP, sensitivity labels, and exported Copilot content. Evaluate and scope Facilitator separately. Determine which users should be able to initiate Facilitator and which meeting scenarios justify shared AI-generated notes. Test where the resulting Loop files are stored, who can access them, and how retention, sensitivity labels, eDiscovery, sharing, and lifecycle controls apply. Test for unexpected artifacts. After a pilot meeting, inspect the organizer’s and initiator’s OneDrive, the meeting chat, Notes, Recap, Loop, and relevant Purview experiences. Confirm that the meeting produces only the artifacts your governance team expects. Train meeting organizers. Explain the difference between Only during the meeting and During and after the meeting. Prepare users for the temporary experience. Users should capture approved action items or summaries before the meeting ends. Test the complete workflow. Validate the experience using representative accounts, policies, licenses, meeting types, and organizational controls. Review the configuration periodically. Microsoft Teams and Copilot capabilities continue to evolve, and healthcare organizations should reassess their controls as features change. Finding the Right Balance Healthcare organizations do not necessarily have to choose between disabling Copilot completely and generating a recording and transcript for every meeting. The Only during the meeting option provides another path: users can receive real-time assistance while the organization limits the creation of traditional post-meeting artifacts. It is not a substitute for a complete healthcare compliance strategy. It is a technical control that can support a broader strategy built around risk assessment, appropriate access, retention, auditing, training, and clearly defined meeting scenarios. The Facilitator lesson also demonstrates why organizations must test the entire meeting experience—not just the most visible policy settings. Copilot may be operating as expected while another enabled capability is still creating shared, persistent content. For the healthcare customer that inspired this video, the technical settings were only part of the solution. The real success came from understanding the user experience, finding the unexpected Loop artifacts, separating Copilot governance from Facilitator governance, and teaching organizers how the different options behave. That is the lesson I hope this walkthrough helps other healthcare organizations apply.
