Pinned Posts
Forum Widgets
Latest Discussions
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!
Filter Fabric objects
On one side I can understand point a connector at Fabric and let it run and ingest into Purview. However, I would like to manage what does get pulled into Purview from Fabric. There are Dev/Test workspaces with reports and dashboards that are not preferred to be ingested, as well as Lakehouses and Warehouses with the same concept of Dev/Test/Prod. Is there a way to control the objects that are ingested via the Fabric connector? The other thought I had was maybe individual connectors like SQL and PBI, but there isn't anything that I can see. Thoughts or direction?Information Scanner - SQL connection fails
Hello everyone, we are currently deploying the information scanner. The issue appeared after the scanner was already installed successfully SQL Server is running on a custom TCP port (49999), encrypted connection, and the scanner database is existing with the correct owner (service account). We also acquired the Entra token Error Failed to access scanner database. Verify the database is up and running and can be accessed by scanner service account and by the currently logged in user that executes the command. Troubleshooting steps taken: Diag show: Invalid database schema or cannot access the scanner DB. To update the database schema, run Update-ScannerDatabase. Make sure all nodes run the same MIP client version. SQL error: Message Could not obtain information about Windows NT group/user 'Domain\scanaccount', error code 0x5. Update-ScannerDatabase executed - same error Login to SQL Servers are successful SQL CMD: sqlcmd -S SQL.company.de,4321 -E -N -Q "SELECT @@VERSION" ## Worked Other configs: Tried to reregister database multiple times / service account is sysadmin at SQL server (shared) SQL DB Alias used instead of Port / SQL Browser did not work Allowed everything through firewall on SQL server - still fail 4h of troubleshooting gone by - and i am stuck - what can i do next? BR Stephan
Service Domain restrictions
I’m currently implementing an Endpoint DLP policy to enforce service domain restrictions. The goal is to prevent users from uploading documents to non-corporate domains and only allow uploads to a specific allow-list (authorized domains), we only use Microsoft Edge I have the basic configuration working, but I have a few questions about behaviors I’m seeing: Dynamic Groups: Is it supported to use Microsoft 365 Dynamic Groups for the policy scope/assignment? File Types: How can I make the policy target all file types? Currently, I'm managing this via a defined list of extensions, but I'd like to cover everything. Copy/Paste vs. Upload (The main issue): When I drag and drop or use the "Upload" button from File Explorer to a blocked domain, the action is blocked as expected. However, if I copy and paste the file (or content) directly into the website, it bypasses the block and uploads successfully. Why does this happen? Policy Activation: It seems documents only pick up the policy restrictions after they are modified. Is this the expected behavior? Any recommendations or insights on what I might be missing would be appreciated. Thanks!
Microsoft Purview Unified Catalog – Draft Data Product Visibility (RBAC)
I have three Entra ID security groups that must be able to see all data products across the estate, including Draft, Unpublished, Published, and Retired: Purview.Admin.Team Purview.Data.Governance Purview.Data.Architecture.Team What I tested I tested assigning these groups to the available Microsoft Purview Unified Catalog roles at both application and governance‑domain scope, including Global Catalog Reader / domain reader roles Governance Domain Owner Data Governance Administrator Data Product Owner Data Steward Observed results Reader roles and Data Governance Administrator allowed users to see the list of data products but not Draft / Unpublished items. Governance Domain Owner and Data Product Owner allowed draft visibility but grant ownership/control. Only assigning the groups as Data Steward on each governance domain consistently allowed visibility of all data product lifecycle states (Draft, Unpublished, Published, Retired) without granting ownership. Current understanding Draft and Unpublished data products are only visible to users assigned domain‑level governance roles Data Steward is the least‑privileged role that provides draft visibility To achieve estate‑wide draft visibility, the groups must be assigned as Data Steward on every governance domain Application‑level roles alone (including Data Governance Administrator) are insufficient Question (seeking confirmation) Is this understanding and solution correct and aligned with Microsoft’s intended Purview Unified Catalog RBAC design, or is there an alternative supported way to provide read‑only draft data product visibility without assigning Data Steward per governance domain?Request for Advice on Managing Shared Glossary Terms in Microsoft Purview
Hi everyone, I'm looking for guidance from others who are working with Microsoft Purview (Unified Catalog), especially around glossary and governance domain design. Scenario; I have multiple governance domains, all within the same Purview tenant. We have some core business concepts from the conceptual data models for example, a term like “PARTY” that are needed in every governance domain. However, based on Microsoft’s documentation: Glossary terms can only be created inside a specific governance domain, not at a tenant‑wide or global level. The Enterprise Glossary is only a consolidated view, not a place to create global terms or maintain a single shared version. It simply displays all terms from all domains in one list. If the same term is needed across domains, Purview requires separate term objects in each domain. Consistency must therefore be managed manually (by re‑creating the term in each domain) or by importing/exporting via CSV or automation (API/PyApacheAtlas)? This leads to questions about maintainability; especially when we want one consistent definition across all domains. What I'm hoping to understand from others: How are you handling shared enterprise concepts – enterprise and conceptual data models that need to appear in multiple governance domains? Are you duplicating terms in each domain and synchronising them manually or via automation? Have you adopted a “central domain” for hosting enterprise‑standard terms and then linking or referencing them in other domains? Is there any better pattern you’ve found to avoid fragmentation and to ensure consistent definitions across domains? Any advice, lessons learned, or examples of how you’ve structured glossary governance in Purview would be really helpful. this is be a primary ORKS - Establish a unified method to consistently link individual entities (e.g., PARTY) to their associated PII‑classified column‑level data assets in Microsoft Purview, ensuring sensitive data is accurately identified, governed, and monitored across all domains. – I.e CDE to Glossary terms Thanks in advance!Purview Data Map – Proposed Domain & Collection Structure
Microsoft Purview Data Map – Proposed Domain & Collection Structure This proposed Microsoft Purview Data Map domain and collection structure ensures that users responsible for specific data assets can be granted precisely scoped permissions—particularly for updating metadata—by mapping Business Units, Departments, Teams, and environments in a clear hierarchy that allows RBAC inheritance to assign the right level of access to the right people. Domain Name Data Catalogue (Short, clear, governance-aligned name to avoid UI truncation and scripting issues.) Collection Path Data Catalogue → Business Units → Departments → Teams → [Prod | Non-Prod] Level 1: Business Units Level 2: Departments (within each Business Unit) Level 3: Teams (within each Department) Optional: Environment segregation under Teams (Prod / Non-Prod) Reasons & Requirements 1. Domain Naming Short, clear name avoids UI truncation and scripting issues. Detailed descriptions stored in metadata; name remains simple for automation and future-proofing. 2. Structure Alignment Alignment with organisational charts and unified governance hierarchy: Business Units → Departments → Teams Provides intuitive navigation and meaningful context for users. 3. Hierarchy Depth Limited to 4–5 levels for usability and RBAC inheritance. Avoids unnecessary complexity while maintaining clarity. 4. Environment Handling Prod / Non-Prod split under Teams for simplicity. Additional environments only if governance differs significantly. 5. RBAC & Ownership Permissions align with organisational roles. Supports the principle of least privilege. 6. Scanning & Policy Scans assigned at Team level for precise governance. Policies inherit from higher levels for consistency. Selective scanning preferred for cost efficiency. 7. Best Practice Compliance Matches Microsoft guidance: short names, shallow hierarchy, environment segregation. Clear distinction between governance path and technical hierarchy. Role Assignment in Collections Data Curator Role Designed for users who: Edit and update metadata. Manage business context for assets within the collection. Assign to: Data Owners (Directorate level). Data Stewards (Team level). Data Product Owners / Asset Managers (for their own assets). Why at Collection Level? RBAC in Purview inherits down the collection hierarchy: Assign at Team collection → edit metadata for all assets in that Team. Assign at Group or Directorate level → edit metadata for all child collections. Ensures least privilege and ownership-based editing. Best Practice Read-only roles (Data Reader) applied broadly for transparency. Data Curator scoped to the lowest level where the user has responsibility (usually Team). Avoid assigning Data Curator at the root unless absolutely necessary.Secure your data—Microsoft Purview at Ignite 2025
Security is a core focus at Microsoft Ignite this year, with the Security Forum on November 17, deep dive technical sessions, theater talks, and hands-on labs designed for security leaders and practitioners. Join us in San Francisco, November 17–21, or online, November 18–20, to learn what’s new and what’s next across data security, compliance, and AI. This year’s sessions and labs will help you prevent data exfiltration, manage insider risks, and enable responsible AI adoption across your organization. Featured sessions: BRK250: Preventing data exfiltration with a layered protection strategy Learn how Microsoft Purview enables a layered approach to data protection, including AI and non-AI apps, devices, browsers, and networks. BRK257: Drive secure Microsoft 365 Copilot adoption using Microsoft Purview Discover built-in safeguards to prevent data loss and insider risks as you scale Copilot and agentic AI. LAB548: Prevent data exposure in Copilot and AI apps with DLP Configure DLP policies to protect sensitive data across Microsoft 365 services and AI scenarios. Explore and filter the full security catalog by topic, format, and role: aka.ms/Ignite/SecuritySessions. Why attend: Ignite is your chance to see the latest Purview features, connect with product experts, and get hands-on with new compliance and data protection tools. Microsoft will also preview future enhancements for agentic AI and unified data governance. Security Forum (November 17): Kick off with an immersive, in‑person pre‑day focused on strategic security discussions and real‑world guidance from Microsoft leaders and industry experts. Select Security Forum during registration. Connect with peers and security leaders through these signature security experiences: Security Leaders Dinner—CISOs and VPs connect with Microsoft leaders. CISO Roundtable—Gain practical insights on secure AI adoption. Secure the Night Party—Network in a relaxed, fun setting. Register for Microsoft Ignite >October 16 | What’s New in Copilot in Microsoft Purview
Speaker: Patrick David, Principal Product Manager, CxE CAT Compliance Join us for an insider’s look at the latest innovations in Microsoft Purview —where alert triage agents for DLP and IRM are transforming how we respond to sensitive data risks and improve investigation depth and speed. We’ll also dive into powerful new capabilities in Data Security Posture Management (DSPM) with Security Copilot, designed to supercharge your security insights and automation. Whether you're driving compliance or defending data, this session will give you the edge. Register now. Check out the rest of the Security Copilot Skilling Series here.Purview YouTube Show and Podcast
I am a Microsoft MVP who co-hosts All Things M365 Compliance with Ryan John Murphy from Microsoft. The show focuses on Microsoft 365 compliance, data security, and governance. Our episodes cover: Microsoft Purview features and updates Practical guidance for improving compliance posture Real-world scenarios and expert discussions Recent episodes include: Mastering Records Management in Microsoft Purview: A Practical Guide for AI-Ready Governance Teams Private Channel Messages: Compliance Action Required by 20 Sept 2025 Microsoft Purview DLP: Best Practices for Successful Implementation Shadow AI, Culture Change, and Compliance: Securing the Future with Rafah Knight 📺 Watch on YouTube: All Things M365 Compliance - YouTube 🎧 Listen on your favourite podcast platform: All Things M365 Compliance | Podcast on Spotify If you’re responsible for compliance, governance, or security in Microsoft 365, this is for you. 👉 Subscribe to stay up to date – and let us know in the comments what topics you’d like us to cover in future episodes!
