Issue Using Built in Trainable Classifiers in Auto Labelling Policies - Purview
Over the last few days, I have run into issue while configuring Auto labelling policies in Purview specifically when using built in classifiers for eg: Budget, Agreements These classifiers are parr of ready to use. They have been working well for us until recently but now saving an auto labelling rule that includes any of Trainable classifiers getting client side error: 'Could not find rule pack associated with sensitive information type' this is unexpected because: same classifiers eg: Budget worked perfectly just few weeks ago. No changes have made to roll, permissions on our side. Still not sure why showing issue now. Kindly request you, help me with root cause of the cause. Please feel free to post it comments if someone faced same issue in using trainable classifiers in auto labelling policies. Thanks in advance. Regards, BanuMurali
Can´t Sign confidential documents
Hello, I have a problem. I want to send confidential contracts to customers for signing with Adobe DocuSign. This contracts have a label "confidential" from purview and are encrypted. But now the customer cant sign the contract with DocuSign because of the encryption. Is there a way that they can sign the document? We must encrypt the documents because compliance reasons and ISMS. Thank you.
Lifecycle using Custom Protection with Purview Sensitivity Labels
Organizations using Purview Sensitivity Labels with custom protection face a fundamental governance challenge: there is no lifecycle‑ready way to maintain, audit, or update per‑document user rights as teams evolve. This affects compliance, need‑to‑know enforcement, and operational security. Document lifecycle challenges Team growth: new members do not inherit document‑specific rights. Team shrinkage: departing members retain access unless manually removed. Employee offboarding: accounts are disabled, but compliance may require explicit removal from protected documents. Audit requirements: organizations need to answer “Who has what rights on document X?” — and today, no native tool provides this for custom‑protected files. Existing method Limitation Purview PowerShell Overwrites all existing assignments; no granular updates MIP Client Not yet capable of bulk lifecycle operations OlaProeis/FileLabeler Great tool, but limited by the same PowerShell constraints What the tool enables Rights audit trail per document Controlled lifecycle updates (add/remove/transfer rights) Preservation of original files for rollback Multi‑action batch processing Admin‑only delegated workflow with MIP superuser role Full logging for compliance Supported operations ListRightAssignments – extract all rights from each document under a given label GUID SetOwner / AddOwner – assign or add owners AddEditor / AddRestrictedEditor / AddViewer – role‑based additions RemoveAccess – remove any user from all roles AddAccessAs – map one user’s role to one or more new users Multi‑action execution – combine operations in a single run Safe mode – original files preserved; updated copies created with a trailer Because this tool can modify access to highly sensitive content, it must be embedded in a controlled workflow: ticket‑based approval, delegated admin, MIP superuser assignment, and retention of all logs as part of the audit trail. This ensures compliance with need‑to‑know, separation of duties, and legal requirements. I would appreciate feedback from the community and Microsoft product teams on: whether similar lifecycle capabilities are planned for Purview whether the MIP SDK is the right long‑term approach how others handle custom‑protected document lifecycle today interest in collaborating on a more robust open‑source version MaxDefault Sensitivity Label to be added to migrated files (from Local Network Server)
Hi Experts, We are migrating our file-sharing services from a local network file server to MS Teams/SPO. The requirement is to enable and give default sensitivity labels from the migrated files. Manually assigning sensitivity labels in over a TB of files is hectic and could be prone to error as well. MS Purview MIP labels and label policies are configured, however, at present, only new documents and/or revised files are only having the sensitivity labels assigned. Any suggestions, guide, and tips will be highly appreciated. Thanks, Rhey
Justification not triggered when downgrading between sublabels under same parent label
Hi all, I am looking for confirmation of expected behaviour with Microsoft Purview sensitivity labels and justification. We have justification enabled in our sensitivity label policy. When a user changes a label between labels that belong to the same label group, no justification prompt appears. When a user changes from a label in one label group to a label in a different label group, the justification prompt does appear as expected. Is this behavior by design? Specifically, does Microsoft treat the label group as the enforcement boundary for downgrade justification, meaning justification is not evaluated when moving between labels within the same group, even if effective protection is reduced? If this is expected, is there any supported way to require justification when downgrading between labels in the same label group? Thank you!Encryption disappears in Outlook - Sensitivity Label not working
Hello everyone, we implemented Sensitivity Labels at our client and have iconsistent and unexpected behavior, we cannot explain. Maybe some of you can help or have ideas on whats going on: Scenario / Use Case A customer is using Sensitivity Labels to encrypt emails in Exchange Online. Label configuration: The sensitivity label applies encryption The label is scoped (published) to a Microsoft 365 group User A and User B are members of this Microsoft 365 group and therefore can apply the label User are licensed with M365 Business Premium The label is published and available to User A and User B (member of above M365 group) User C is an external recipient and not included in the label’s publishing scope Observed Behaviors Scenario 1 – Encryption Lost When Forwarded Externally User A (internal) sends an email to User B (internal) using a sensitivity label that applies encryption. User B receives the email correctly: The lock icon in Outlook is displayed, the message is encrypted as expected User B forwards the email to User C (external) User C receives the forwarded email unencrypted: No lock icon is shown, User C can read the entire conversation history, including content that was previously encrypted Scenario 2 – Encryption Disappears Within an Internal Email Conversation In addition to the external forwarding scenario, we are also observing the following behavior within an internal email thread: User A sends an encrypted email to User B using the sensitivity label. User B replies to User A: The reply remains encrypted User A replies again within the same conversation Suddenly, the encryption disappears: The lock icon is no longer shown The message and the full conversation history is no longer protected This happens without any user action to remove or change the sensitivity label. Key Observation Both scenarios occur intermittently: Sometimes encryption behaves as expected Sometimes encryption disappears “out of nowhere” The behavior is not reliably reproducible, which makes troubleshooting very difficult. Any help is appreciated!Test DLP Policy: On-Prem
We have DLP policies based on SIT and it is working well for various locations such as Sharepoint, Exchange and Endpoint devices. But the DLP policy for On-Prem Nas shares is not matching when used with Microsoft Information Protection Scanner. DLP Rule: Conditions Content contains any of these sensitive info types: Credit Card Number U.S. Bank Account Number U.S. Driver's License Number U.S. Individual Taxpayer Identification Number (ITIN) U.S. Social Security Number (SSN) The policy is visible to the Scanner and it is being logged as being executed MSIP.Lib MSIP.Scanner (30548) Executing policy: Data Discovery On-Prem, policyId: 85........................ and the MIP reports are listing files with these SITs The results Information Type Name - Credit Card Number U.S. Social Security Number (SSN) U.S. Bank Account Number Action - Classified Dlp Mode -- Test Dlp Status -- Skipped Dlp Comment -- No match There is no other information in logs. Why is the DLP policy not matching and how can I test the policy ? thanksLabel group migration - existing files labelled with former parent labels
Hi, I have a question about behavior during migration from legacy parent labels to label groups. Historically, we were allowed to apply parent labels directly to content. In our environment, we have an existing parent label called PUBLIC which has sublabels. PUBLIC itself has content encryption configured, so during migration it will be recreated as a sublabel within a label group. As a result, there are existing files that are currently labelled simply as PUBLIC (applied back when parent labels could be used directly). Post-migration, we plan to de-publish this newly created PUBLIC sublabel from user-facing policies. My question is about what happens to those existing files during and after the migration. Will files that are already labelled as PUBLIC automatically be updated to a specific label within the label group, such as PUBLIC/PUBLIC, or will they remain labelled as PUBLIC with no automatic relabelling? In other words, does the label group migration perform any automatic relabelling of existing content, or does it only affect label structure and publication going forward?Guidance: Sensitivity Labels during Mergers & Acquisitions (separate tenants, non-M365, etc.)
We’re building an internal playbook for how to handle Microsoft Purview sensitivity labels during mergers and acquisitions, and I’d really appreciate any lessons learned or best practices. Specifically, I’m interested in how others have handled: Acquired organizations on a separate Microsoft 365/O365 tenant for an extended period (pre- and post-close): How did you handle “Internal Only” content when the two tenants couldn’t fully trust each other yet? Any tips to reduce friction for collaboration between tenants during the transition? Existing label structures, such as: We use labels like “All Internal Only” and labels with user-defined permissions — has anyone found good patterns for mapping or reconciling these with another company’s labels? What if the acquired company is already using sensitivity labels with a different taxonomy? How did you rationalize or migrate them? Acquisitions where the target does not use Microsoft 365 (for example, Google Workspace, on-prem, or other platforms): Any strategies for protecting imported content with labels during or after migration? Gotchas around legacy permissions versus label-based protections? General pitfalls or watch-outs between deal close and full migration: Anything you wish you had known before your first M&A with Purview labels in play? Policies or configurations you’d recommend setting (or avoiding) during the interim period? Any examples, war stories, or template approaches you’re willing to share would be incredibly helpful as we shape our playbook. Thanks in advance for any insights!
C# MIP SDK v1.17.x - AccessViolationException on creation of MIPContext in 64-bit console app
I first logged this on https://stackoverflow.com/questions/79746967/accessviolationexception-when-creating-mipcontext-after-upgrade-to-v1-17 and the responses there have indicated I should raise with Microsoft a a likely bug, but I don't see a clear route to reporting other than here so any response would be appreciated, even if just to direct me to the appropriate reporting location. I've built a simple console app that demonstrates this issue that I'm happy to provide but we're seeing an issue with the 1.17.x version of the C# MIP SDK where an AccessViolationException is being thrown when trying to create an MIP context object. This is for a .Net Framework 4.8 console app built in 64-bit configuration, deployed to a Windows Server 2016 with the latest VC++ redistributable (14.44.35211) installed (both x86 and x64 versions), though we've seen the same on Windows Server 2019 and 2022. When the same app is built in 32-bit and deployed to the same environment the exception doesn't occur. The following code is what I've used to repro the issue: MIP.Initialize(MipComponent.File); var appInfo = new ApplicationInfo { ApplicationId = string.Empty, ApplicationName = string.Empty, ApplicationVersion = string.Empty }; var diagnosticConfiguration = new DiagnosticConfiguration { IsMinimalTelemetryEnabled = true }; var mipConfiguration = new MipConfiguration(appInfo, "mip_data", LogLevel.Info, false, CacheStorageType.InMemory) { DiagnosticOverride = diagnosticConfiguration }; //Expect BadInputException here due to empty properties of appInfo //When built as part of a 64-bit console app this causes AccessViolationException instead MIP.CreateMipContext(mipConfiguration); The AccessViolationException crashes the console app, with the following logged in the Windows Event Log: Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException at Microsoft.InformationProtection.Internal.SdkWrapperPINVOKE.MipContext_Create__SWIG_1(System.Runtime.InteropServices.HandleRef) at Microsoft.InformationProtection.Internal.MipContext.Create(Microsoft.InformationProtection.Internal.MipConfiguration) at Microsoft.InformationProtection.Utils.MIPHelper.CreateMipContext(Microsoft.InformationProtection.MipConfiguration) The issue doesn't occur with the latest 1.16 version (1.16.149) of the SDK but does appear to be in all versions of the 1.17 release. Library: C# MIP SDK v1.17.x Target App: .Net Framework 4.8 console app Deployed OS: Windows Server 2016, 2019 and 2022 (With .Net Framework 4.8 and latest VC++ redist installed)
