Pinned Posts
Forum Widgets
Latest Discussions
Microsoft Purview PowerShell: Interactive Sign-In Basics + Fixing Common Connect-IPPSSession Errors
If you’re new to Microsoft Purview PowerShell and your interactive sign-in fails when you run Connect-IPPSSession, you’re not alone. In this post, I’ll walk through the quick setup (module install + connection) and then cover practical fixes for a common authentication failure: “A window handle must be configured” (WAM / MSAL window handle error). Once connected, you can run Purview-related cmdlets for tasks like working with sensitivity labels, DLP policies, eDiscovery, and other compliance operations (depending on your permissions). Step 1: Install the Exchange Online PowerShell module Install-Module ExchangeOnlineManagement Import-Module ExchangeOnlineManagement Step 2: Connect to Microsoft Purview (Security & Compliance) PowerShell For interactive sign-in, you can start with the standard connection pattern below (replace the placeholder with your User Principal Name) Common issue: Interactive sign-in fails with a WAM “window handle” error The ExchangeOnlineManagement module uses modern authentication. In some hosts/environments, the sign-in UI can’t attach to a parent window, so token acquisition fails and you may see the error below. This is commonly associated with WAM (Web Account Manager) / MSAL interactive sign-in. Error Acquiring Token: A window handle must be configured. See https://aka.ms/msal-net-wam#parent-window-handles A window handle must be configured. See https://aka.ms/msal-net-wam#parent-window-handles At C:\Program Files\WindowsPowerShell\Modules\ExchangeOnlineManagement\3.9.2\netFramework\ExchangeOnlineManagement.psm1:591 char:21 + throw $_.Exception.InnerException; + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (:) [], MsalClientException + FullyQualifiedErrorId : A window handle must be configured. See https://aka.ms/msal-net-wam#parent-window-handles You’ll often hit this on secured devices, PowerShell ISE, or hardened corporate images. Below are two solutions to bypass this error. Start with the recommended option first. 1. Recommended workaround: Use Get-Credential without disabling WAM This approach avoids the WAM-based interactive prompt. You’ll be asked for credentials via a standard PowerShell credential dialog, and the module will complete modern authentication. $cred = Get-Credential Connect-IPPSSession -Credential $cred A credential prompt appears: Enter your username and password. After authentication, you should be connected to the Security & Compliance (Microsoft Purview) PowerShell session. As a quick validation, try a lightweight cmdlet such as Get-Label or Get-DlpCompliancePolicy (availability depends on permissions). If this works in your environment, it’s a simple way to proceed without changing system-wide WAM behavior. 2. Alternative workaround: Disable WAM for the session (use with caution) If the interactive UI is failing, you can try disabling WAM. Newer versions of the ExchangeOnlineManagement module support a -DisableWAM switch on the connection cmdlets, which bypasses the WAM broker and can avoid the “window handle” failure. Connect-IPPSSession -UserPrincipalName <yourUPN> -DisableWAM If you can’t use -DisableWAM or if it is not working as expected (or you’re troubleshooting a specific host issue), some admins set an environment variable to disable WAM for MSAL using the commands below. Treat this as a temporary troubleshooting step and follow your organization’s security guidance. $env:MSAL_DISABLE_WAM = "1" setx MSAL_DISABLE_WAM 1 Important warning! Changing authentication/broker behavior can have security and supportability implications. Use this only for troubleshooting and revert when you’re done using the following commands. $env:MSAL_DISABLE_WAM = "0" setx MSAL_DISABLE_WAM 0 Quick summary If you’re scripting for Microsoft Purview and interactive sign-in fails due to the WAM “window handle” error, try the sequence below. Install-Module ExchangeOnlineManagement Import-Module ExchangeOnlineManagement $cred = Get-Credential Connect-IPPSSession -Credential $cred Hope this helps! If you’ve hit this in a specific host (PowerShell ISE vs Windows PowerShell vs PowerShell 7, RDP/jump box, etc.), share what worked for you in the comments. Thanks for reading. Happy Scripting! Reference: Connect to Security & Compliance PowerShell | Microsoft Learn
DLP Policy - DSPM Block sensitive info from AI sites
Having issues with this DLP policy not being triggered to block specific SITs from being pasted into ChatGPT, Google Gemine, etc. Spent several hours troubleshooting this issue on Windows 11 VM running in Parallels Desktop. Testing was done in Edge. Troubleshooting\testing done: Built Endpoint DLP policy scoped to Devices and confirmed device is onboarded/visible in Activity Explorer. Created/edited DLP rule to remove sensitivity label dependency and use SIT-based conditions (Credit Card, ABA, SSN, etc.). Set Paste to supported browsers = Block and Upload to restricted cloud service domains = Block in the same rule. Configured Sensitive service domain restrictions and tested priority/order (moved policy/rule to top). Created Sensitive service domain group for AI sites; corrected entries to hostname + prefix wildcard a format (e.g., chatgpt.com + *.chatgpt.com) after wildcard/URL-format constraints were discovered. Validated Target domain = chatgpt.com in Activity Explorer for paste events. Tested multiple SIT payloads (credit card numbers with/without context) and confirmed detection occurs. Confirmed paste events consistently show: Policy = Default Policy, Rule = JIT Fallback Allow Rule, Other matches = 0, Enforcement = Allow (meaning configured rules are not matching the PastedToBrowser activity). Verified Upload enforcement works: “DLP rule matched” events show Block for file upload to ChatGPT/LLM site group—proves domain scoping and endpoint enforcement works for upload. Disabled JIT and retested; paste events still fall back to JIT Fallback Allow Rule with JIT triggered = false. Verified Defender platform prerequisites: AMServiceVersion (Antimalware Client) = 4.18.26020.6 (meets/exceeds requirements).Purview Integration during Merger and Acquisitions
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Hello, We are currently in the process of merging with two other organizations and are looking to integrate our Microsoft Purview environments. All three organizations have different sensitivity labeling schemes, and we would like guidance on the best approach to achieve a unified labeling strategy across the merged organization. Specifically, should we create a new, common set of sensitivity labels for the combined organization and plan a phased transition for users? One of the organizations already has the majority of its documents labeled, so maintaining those existing labels during the merger is a key concern. We are also looking for best practices to ensure that existing labels are preserved when the two additional organizations are onboarded into Purview, while still moving toward a consistent, unified labeling framework. Any suggestions or if any one had already been a part of such a merger, please share your experiencePurview DLP Behaviours in SharePoint and OneDrive
We are currently testing Microsoft Purview DLP policies for user awareness across SharePoint Online, and OneDrive. The policy is configured such that sensitive information (based on a sensitivity label-OFFICIAL Sensitive) shared externally triggers a policy tip, with override allowed (justification options enabled) and no blocking action configured. In SharePoint Online and OneDrive, users are not experiencing any DLP-related behaviour. When attempting to share labelled content externally: No policy tips are displayed No override prompts are presented No indication of DLP enforcement is shown Users are able to share content externally without any awareness prompt or restriction. Expected behaviour: Users should receive a policy tip during the sharing process Users should be prompted for justification when overriding, aligned with the DLP configuration Has anyone observed similar behaviour with DLP in SharePoint Online and OneDrive, particularly in scenarios where no blocking action is configured? Keen to understand if this is expected behaviour, a known limitation, or if there are any configuration considerations or workarounds to achieve a consistent user experience across workloads.Purview DLP Behaviours in Outlook Desktop
We are currently testing Microsoft Purview DLP policies for user awareness, where sensitive information shared externally triggers a policy tip, with override allowed (justification options enabled) and no blocking action configured. We are observing the following behaviours in Outlook Desktop: Inconsistent policy tip display (across Outlook Desktop Windows clients) – For some users, the policy tip renders correctly, while for others it appears with duplicated/stacked lines of text. This is occurring across users with similar configurations. Override without justification – Users are able to click “Send Anyway/Confirm and send” without selecting any justification option (e.g. business justification, manager approval, etc.), which bypasses the intended control. New Outlook: Classic Outlook: This has been observed on Outlook Desktop (Microsoft 365 Apps), including: Version 2602 (Build 19725.20170 Click-to-Run) Version 2602 (Build 16.0.19725.20126 MSO) Has anyone experienced similar behaviour with DLP policy tips or override enforcement in Outlook Desktop? Keen to understand if this is a known issue or if there are any recommended fixes or workarounds.
Leveraging Microsoft Graph to Automate Compliance Workflows MS Purview
Background Microsoft Purview provides organizations with capabilities to discover, classify, protect, and govern sensitive information across Microsoft 365 workloads. As organizations increasingly rely on Purview for compliance operations such as auditing, investigations, and regulatory response, there is a growing need to automate these processes beyond the Microsoft Purview portal. Microsoft exposes key compliance capabilities through Microsoft Graph APIs, enabling organizations to integrate Purview operations directly into automation workflows. The Microsoft Purview APIs in Microsoft Graph allow applications to align with data governance, security, and compliance policies defined within the Purview portal, helping ensure that applications handling sensitive information respect organizational controls. Automating eDiscovery Operations with Microsoft Graph The Microsoft Purview eDiscovery APIs available through Microsoft Graph enable organizations to automate repetitive compliance tasks and integrate with existing investigation or legal workflows. These APIs are intended to support litigation, investigation, and regulatory scenarios by allowing administrators to programmatically manage key eDiscovery components such as cases, custodians, searches, review sets, and exports. This capability allows organizations to move from manual portal‑based workflows toward repeatable, policy‑aligned processes integrated into automation platforms or downstream compliance tooling. Programmatic Access to Audit Logs Microsoft Purview Audit captures thousands of operations across Microsoft 365 services and retains them in the unified audit log for security investigations and compliance obligations. Through Microsoft Graph, administrators can now programmatically search and retrieve audit logs using the Purview Audit Search API. This API enables administrators and applications to query and retrieve relevant audit activity logs across workloads such as Exchange, Entra ID, OneDrive, SharePoint, and Intune, providing visibility into user activity and administrative operations performed across the organization. This provides a programmatic alternative to legacy PowerShell‑based audit search methods, improving reliability and enabling automation of compliance monitoring workflows. Supporting Policy‑Aware Applications Applications that integrate with Microsoft Purview APIs through Microsoft Graph can interpret and enforce compliance policies such as sensitivity labels or data loss prevention (DLP) rules. Microsoft documents that apps built using these APIs can prevent data misuse by aligning with compliance and security requirements defined within the organization’s governance framework. This integration also allows enterprise applications to respect sensitivity labels and policy‑driven controls, ensuring that interactions with organizational data remain compliant with regulatory requirements and internal governance policies. Conclusion Microsoft Purview governs organizational data through classification, retention, auditing, and investigation capabilities. Microsoft Graph provides the automation layer that allows these governance controls to be accessed programmatically. By integrating Microsoft Graph with Microsoft Purview APIs, organizations can automate eDiscovery workflows, retrieve audit logs programmatically, and ensure that applications interacting with sensitive data respect compliance policies defined within their Microsoft 365 environment. Learning Resources Use the Microsoft Purview eDiscovery API in Microsoft Graph Use Microsoft Purview APIs for eDiscovery Overview of Microsoft Purview APIs in Microsoft Graph Introducing the Microsoft Purview Audit Search Graph API
DLP policy stops working when device is joined to the local domain
i have deployed purview in the client environment (M365 E5 lic) the DLP rule presents copy to USB for fils with a certain sensitivity label. DLP agent is deployed on all devices and all devices are in sync. when i test the DLP policy on an Entra joind device it works as intended and prevents copy to USB but when i join the device to the local domain the DLP policy stops working how do i debug this?
Different uses of the classic portal and the new portal
Hi everyone, I explain my problem, but without expecting a solution, as I understand that is no bug/issue there. My problem is that I had all the glossary terms in the Classic glossary, with some workflows. Then when they released the new version, more oriented to data products and data mesh, I started to migrate the glossary terms to each business domain, but 1) workflows cannot be applied to new portal items (glossary terms from a business domain) and 2) the terms cannot be linked to data assets in the data map, only to data products (a container for data assets) FYI, the Enterprise Glossary is made up of all the "Approved" glossary terms in each Business Domain, and this confused me a bit at first. In other hand, if you go for the classic portal you loose all data quality functionalities inside data products. The classic one don't have data quality tracking. I think Microsoft should explain well what each portal is for and how to use it and simplify life for everyone. For example, I think they should make it clear that we should reserve the new portal only if you use Fabric and a Datamesh approach and for the rest of the architectures/uses, it is better to use the classic one. Or eventually unify the glossaries and data asset's data quality to have better experience. Thanks! DavidPurview Graph API
Hello. I'm trying to find information on the Purview Graph API and it's endpoints. It looks like the endpoints aren't posted publicly and are listed within an admin console. Can someone help me with how to view the endpoints? Also, are the graph API endpoints capable of reading and creating assets into Purview?
