admin
6456 TopicsDisabling Tenant-Wide Auto-Archiving in Exchange Online
Hello, I need to disable auto-archiving for Exchange Online mailboxes at the tenant level. Before I pull the trigger, I would like to make sure I’m looking at the right knobs and understanding the downstream effects. Where is the definitive On/Off switch for auto-archiving at the tenant level (Admin Center vs. PowerShell)? What is the actual functional difference between the Archive settings in Org Settings and a standard Retention Policy? If I disable the tenant-wide auto-archiving, what happens to the mail that is already sitting in users' archive mailboxes? Does it stay put, or does it try to merge back? Thank you in advance.Solved100Views0likes3CommentsOutlook for Mac enterprise toolbar customization
I'm a Mac systems administrator in an organization that uses a third-party plugin for reporting phishing/spam emails. We are looking for a way to ensure that our reporting button is in the toolbar by default (while still allowing end-user customization) and the default Microsoft one is not in the toolbar by default. I've checked the administrator's guide info here: https://learn.microsoft.com/en-us/microsoft-365-apps/mac/preferences-outlook and while there are ways to customize a LOT of Outlook's features for enterprise purposes, there doesn't seem to be a way to specify a toolbar entry be present or not.24Views0likes1CommentIssue with certificate renewal for exchange Edge Transport Server
Hello team, I have come across a very particular problem I deployed 2 exchange server 2019 with one edge transport server When we are renewing the Certificates with wildcard certificate on both mailbox server ,and on edge transport server ,it is impossible for me to renew the edge subscription It says the cerificate is in "doublon" (repetitive) on one of the Exchange servers.I have always been using same certificate on exchange server be it edge or mailbox I tested a bogus different certificate on mailbox and on edge,only then th e edge sync works Did anybody come across this issue. Thanks6Views0likes0CommentsKerberos and the End of RC4: Protocol Hardening and Preparing for CVE‑2026‑20833
CVE-2026-20833 addresses the continued use of the RC4‑HMAC algorithm within the Kerberos protocol in Active Directory environments. Although RC4 has been retained for many years for compatibility with legacy systems, it is now considered cryptographically weak and unsuitable for modern authentication scenarios. As part of the security evolution of Kerberos, Microsoft has initiated a process of progressive protocol hardening, whose objective is to eliminate RC4 as an implicit fallback, establishing AES128 and AES256 as the default and recommended algorithms. This change should not be treated as optional or merely preventive. It represents a structural change in Kerberos behavior that will be progressively enforced through Windows security updates, culminating in a model where RC4 will no longer be implicitly accepted by the KDC. If Active Directory environments maintain service accounts, applications, or systems dependent on RC4, authentication failures may occur after the application of the updates planned for 2026, especially during the enforcement phases introduced starting in April and finalized in July 2026. For this reason, it is essential that organizations proactively identify and eliminate RC4 dependencies, ensuring that accounts, services, and applications are properly configured to use AES128 or AES256 before the definitive changes to Kerberos protocol behavior take effect. Official Microsoft References CVE-2026-25177 - Security Update Guide - Microsoft - Active Directory Domain Services Elevation of Privilege Vulnerability Microsoft Support – How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 (KB 5073381) Microsoft Learn – Detect and Remediate RC4 Usage in Kerberos AskDS – What is going on with RC4 in Kerberos? Beyond RC4 for Windows authentication | Microsoft Windows Server Blog So, you think you’re ready for enforcing AES for Kerberos? | Microsoft Community Hub Risk Associated with the Vulnerability When RC4 is used in Kerberos tickets, an authenticated attacker can request Service Tickets (TGS) for valid SPNs, capture these tickets, and perform offline brute-force attacks, particularly Kerberoasting scenarios, with the goal of recovering service account passwords. Compared to AES, RC4 allows significantly faster cracking, especially for older accounts or accounts with weak passwords. Technical Overview of the Exploitation In simplified terms, the exploitation flow occurs as follows: The attacker requests a TGS for a valid SPN. The KDC issues the ticket using RC4, when that algorithm is still accepted. The ticket is captured and analyzed offline. The service account password is recovered. The compromised account is used for lateral movement or privilege escalation. Official Timeline Defined by Microsoft Important clarification on enforcement behavior Explicit account encryption type configurations continue to be honored even during enforcement mode. The Kerberos hardening associated with CVE‑2026‑20833 focuses on changing the default behavior of the KDC, enforcing AES-only encryption for TGS ticket issuance when no explicit configuration exists. This approach follows the same enforcement model previously applied to Kerberos session keys in earlier security updates (for example, KB5021131 related to CVE‑2022‑37966), representing another step in the progressive removal of RC4 as an implicit fallback. January 2026 – Audit Phase Starting in January 2026, Microsoft initiated the Audit Phase related to changes in RC4 usage within Kerberos, as described in the official guidance associated with CVE-2026-20833. The primary objective of this phase is to allow organizations to identify existing RC4 dependencies before enforcement changes are applied in later phases. During this phase, no functional breakage is expected, as RC4 is still permitted by the KDC. However, additional auditing mechanisms were introduced, providing greater visibility into how Kerberos tickets are issued in the environment. Analysis is primarily based on the following events recorded in the Security Log of Domain Controllers: Event ID 4768 – Kerberos Authentication Service (AS request / Ticket Granting Ticket) Event ID 4769 – Kerberos Service Ticket Operations (Ticket Granting Service – TGS) Additional events related to the KDCSVC service These events allow identification of: the account that requested authentication the requested service or SPN the source host of the request the encryption algorithm used for the ticket and session key This information is critical for detecting scenarios where RC4 is still being implicitly used, enabling operations teams to plan remediation ahead of the enforcement phase. If these events are not being logged on Domain Controllers, it is necessary to verify whether Kerberos auditing is properly enabled. For Kerberos authentication events to be recorded in the Security Log, the corresponding audit policies must be configured. The minimum recommended configuration is to enable Success auditing for the following subcategories: Kerberos Authentication Service Kerberos Service Ticket Operations Verification can be performed directly on a Domain Controller using the following commands: auditpol /get /subcategory:"Kerberos Service Ticket Operations" auditpol /get /subcategory:"Kerberos Authentication Service" In enterprise environments, the recommended approach is to apply this configuration via Group Policy, ensuring consistency across all Domain Controllers. The corresponding policy can be found at: Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Account Logon Once enabled, these audits record events 4768 and 4769 in the Domain Controllers’ Security Log, allowing analysis tools—such as inventory scripts or SIEM/Log Analytics queries—to accurately identify where RC4 is still present in the Kerberos authentication flow. April 2026 – Enforcement with Manual Rollback With the April 2026 update, the KDC begins operating in AES-only mode (0x18) when the msDS-SupportedEncryptionTypes attribute is not defined. This means RC4 is no longer accepted as an implicit fallback. During this phase, applications, accounts, or computers that still implicitly depend on RC4 may start failing. Manual rollback remains possible via explicit configuration of the attribute in Active Directory. July 2026 – Final Enforcement Starting in July 2026, audit mode and rollback options are removed. RC4 will only function if explicitly configured—a practice that is strongly discouraged. This represents the point of no return in the hardening process. Official Monitoring Approach Microsoft provides official scripts in the repository: https://github.com/microsoft/Kerberos-Crypto/tree/main/scripts The two primary scripts used in this analysis are: Get-KerbEncryptionUsage.ps1 The Get-KerbEncryptionUsage.ps1 script, provided by Microsoft in the Kerberos‑Crypto repository, is designed to identify how Kerberos tickets are issued in the environment by analyzing authentication events recorded on Domain Controllers. Data collection is primarily based on: Event ID 4768 – Kerberos Authentication Service (AS‑REQ / TGT issuance) Event ID 4769 – Kerberos Service Ticket Operations (TGS issuance) From these events, the script extracts and consolidates several relevant fields for authentication flow analysis: Time – when the authentication occurred Requestor – IP address or host that initiated the request Source – account that requested the ticket Target – requested service or SPN Type – operation type (AS or TGS) Ticket – algorithm used to encrypt the ticket SessionKey – algorithm used to protect the session key Based on these fields, it becomes possible to objectively identify which algorithms are being used in the environment, both for ticket issuance and session establishment. This visibility is essential for detecting RC4 dependencies in the Kerberos authentication flow, enabling precise identification of which clients, services, or accounts still rely on this legacy algorithm. Example usage: .\Get-KerbEncryptionUsage.ps1 -Encryption RC4 -Searchscope AllKdcs | Export-Csv -Path .\KerbUsage_RC4_All_ThisDC.csv -NoTypeInformation -Encoding UTF8 Data Consolidation and Analysis In enterprise environments, where event volumes may be high, it is recommended to consolidate script results into analytical tools such as Power BI to facilitate visualization and investigation. The presented image illustrates an example dashboard built from collected results, enabling visibility into: Total events analyzed Number of Domain Controllers involved Number of requesting clients (Requestors) Most frequently involved services or SPNs (Targets) Temporal distribution of events RC4 usage scenarios (Ticket, SessionKey, or both) This type of visualization enables rapid identification of RC4 usage patterns, remediation prioritization, and progress tracking as dependencies are eliminated. Additionally, dashboards help answer key operational questions, such as: Which services still depend on RC4 Which clients are negotiating RC4 for sessions Which Domain Controllers are issuing these tickets Whether RC4 usage is decreasing over time This combined automated collection + analytical visualization approach is the recommended strategy to prepare environments for the Microsoft changes related to CVE‑2026‑20833 and the progressive removal of RC4 in Kerberos. Visualizing Results with Power BI To facilitate analysis and monitoring of RC4 usage in Kerberos, it is recommended to consolidate script results into a Power BI analytical dashboard. 1. Install Power BI Desktop Download and install Power BI Desktop from the official Microsoft website 2. Execute data collection After running the Get-KerbEncryptionUsage.ps1 script, save the generated CSV file to the following directory: C:\Temp\Kerberos_KDC_usage_of_RC4_Logs\KerbEncryptionUsage_RC4.csv 3. Open the dashboard in Power BI Open the file RC4-KerbEncryptionUsage-Dashboards.pbix using Power BI Desktop. If you are interested, please leave a comment on this post with your email address, and I will be happy to share with you. 4. Update the data source If the CSV file is located in a different directory, it will be necessary to adjust the data source path in Power BI. As illustrated, the dashboard uses a parameter named CsvFilePath, which defines the path to the collected CSV file. To adjust it: Open Transform Data in Power BI. Locate the CsvFilePath parameter in the list of Queries. Update the value to the directory where the CSV file was saved. Click Refresh Preview or Refresh to update the data. Click Home → Close & Apply. This approach allows rapid identification of RC4 dependencies, prioritization of remediation actions, and tracking of progress throughout the elimination process. List-AccountKeys.ps1 This script is used to identify which long-term keys are present on user, computer, and service accounts, enabling verification of whether RC4 is still required or whether AES128/AES256 keys are already available. Interpreting Observed Scenarios Microsoft recommends analyzing RC4 usage by jointly considering two key fields present in Kerberos events: Ticket Encryption Type Session Encryption Type Each combination represents a distinct Kerberos behavior, indicating the source of the issue, risk level, and remediation point in the environment. In addition to events 4768 and 4769, updates released starting January 13, 2026, introduce new Kdcsvc events in the System Event Log that assist in identifying RC4 dependencies ahead of enforcement. These events include: Event ID 201 – RC4 usage detected because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined. Event ID 202 – RC4 usage detected because the service account does not have AES keys and the msDS-SupportedEncryptionTypes attribute is not defined. Event ID 203 – RC4 usage blocked (enforcement phase) because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined. Event ID 204 – RC4 usage blocked (enforcement phase) because the service account does not have AES keys and msDS-SupportedEncryptionTypes is not defined. Event ID 205 – Detection of explicit enablement of insecure algorithms (such as RC4) in the domain policy DefaultDomainSupportedEncTypes. Event ID 206 – RC4 usage detected because the service accepts only AES, but the client does not advertise AES support. Event ID 207 – RC4 usage detected because the service is configured for AES, but the service account does not have AES keys. Event ID 208 – RC4 usage blocked (enforcement phase) because the service accepts only AES and the client does not advertise AES support. Event ID 209 – RC4 usage blocked (enforcement phase) because the service accepts only AES, but the service account does not have AES keys. https://support.microsoft.com/en-gb/topic/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc They indicate situations where RC4 usage will be blocked in future phases, allowing early detection of configuration issues in clients, services, or accounts. These events are logged under: Log: System Source: Kdcsvc Below are the primary scenarios observed during the analysis of Kerberos authentication behavior, highlighting how RC4 usage manifests across different ticket and session encryption combinations. Each scenario represents a distinct risk profile and indicates specific remediation actions required to ensure compliance with the upcoming enforcement phases. Scenario A – RC4 / RC4 In this scenario, both the Kerberos ticket and the session key are issued using RC4. This is the worst possible scenario from a security and compatibility perspective, as it indicates full and explicit dependence on RC4 in the authentication flow. This condition significantly increases exposure to Kerberoasting attacks, since RC4‑encrypted tickets can be subjected to offline brute-force attacks to recover service account passwords. In addition, environments remaining in this state have a high probability of authentication failure after the April 2026 updates, when RC4 will no longer be accepted as an implicit fallback by the KDC. Events Associated with This Scenario During the Audit Phase, this scenario is typically associated with: Event ID 201 – Kdcsvc Indicates that: the client advertises only RC4 the service does not have msDS-SupportedEncryptionTypes defined the Domain Controller does not have DefaultDomainSupportedEncTypes defined This means RC4 is being used implicitly. This event indicates that the authentication will fail during the enforcement phase. Event ID 202 – Kdcsvc Indicates that: the service account does not have AES keys the service does not have msDS-SupportedEncryptionTypes defined This typically occurs when: legacy accounts have never had their passwords reset only RC4 keys exist in Active Directory Possible Causes Common causes include: the originating client (Requestor) advertises only RC4 the target service (Target) is not explicitly configured to support AES the account has only legacy RC4 keys the msDS-SupportedEncryptionTypes attribute is not defined Recommended Actions To remediate this scenario: Correctly identify the object involved in the authentication flow, typically: a service account (SPN) a computer account or a Domain Controller computer object Verify whether the object has AES keys available using analysis tools or scripts such as List-AccountKeys.ps1. If AES keys are not present, reset the account password, forcing generation of modern cryptographic keys (AES128 and AES256). Explicitly define the msDS-SupportedEncryptionTypes attribute to enable AES support. Recommended value for modern environments: 0x18 (AES128 + AES256) = 24 As illustrated below, this configuration can be applied directly to the msDS-SupportedEncryptionTypes attribute in Active Directory. AES can also be enabled via Active Directory Users and Computers by explicitly selecting: This account supports Kerberos AES 128 bit encryption This account supports Kerberos AES 256 bit encryption These options ensure that new Kerberos tickets are issued using AES algorithms instead of RC4. Temporary RC4 Usage (Controlled Rollback) In transitional scenarios—during migration or troubleshooting—it may be acceptable to temporarily use: 0x1C (RC4 + AES) = 28 This configuration allows the object to accept both RC4 and AES simultaneously, functioning as a controlled rollback while legacy dependencies are identified and corrected. However, the final objective must be to fully eliminate RC4 before the final enforcement phase in July 2026, ensuring the environment operates exclusively with AES128 and AES256. Scenario B – AES / RC4 In this case, the ticket is protected with AES, but the session is still negotiated using RC4. This typically indicates a client limitation, legacy configuration, or restricted advertisement of supported algorithms. Events Associated with This Scenario During the Audit Phase, this scenario may generate: Event ID 206 Indicates that: the service accepts only AES the client does not advertise AES in the Advertised Etypes In this case, the client is the issue. Recommended Action Investigate the Requestor Validate operating system, client type, and advertised algorithms Review legacy GPOs, hardening configurations, or settings that still force RC4 For Linux clients or third‑party applications, review krb5.conf, keytabs, and Kerberos libraries Scenario C – RC4 / AES Here, the session already uses AES, but the ticket is still issued using RC4. This indicates an implicit RC4 dependency on the Target or KDC side, and the environment may fail once enforcement begins. Events Associated with This Scenario This scenario may generate: Event ID 205 Indicates that the domain has explicit insecure algorithm configuration in: DefaultDomainSupportedEncTypes This means RC4 is explicitly allowed at the domain level. Recommended Action Correct the Target object Explicitly define msDS-SupportedEncryptionTypes with 0x18 = 24 Revalidate new ticket issuance to confirm full migration to AES / AES Conclusion CVE‑2026‑20833 represents a structural change in Kerberos behavior within Active Directory environments. Proper monitoring is essential before April 2026, and the msDS-SupportedEncryptionTypes attribute becomes the primary control point for service accounts, computer accounts, and Domain Controllers. July 2026 represents the final enforcement point, after which there will be no implicit rollback to RC4.918Views3likes3CommentsAnnouncing the 2026 Microsoft 365 Community Conference Keynotes
The Microsoft 365 Community Conference returns to Orlando this April, bringing together thousands of builders, innovators, creators, communicators, admins, architects, MVPs, and product makers for three unforgettable days of learning and community. This year’s theme, “A Beacon for Builders, Innovators & Icons of Intelligent Work,” celebrates the people shaping the AI‑powered future — and the keynote lineup reflects exactly that. These leaders will set the tone for our biggest, boldest M365 Community Conference. Below is your first look at the official 2026 keynote order and what to expect from each session. Opening Keynote Jeff Teper — President, Microsoft 365 Collaborative Apps & Platforms Building for the future: Microsoft 365, Agents and AI, what's new and what's next Join Jeff Teper, to discover how AI-powered innovation across Copilot, Teams, and SharePoint is reshaping how people communicate, create, and work together. This session highlights what’s new, what’s fundamentally different, and why thoughtful design continues to matter. See the latest advances in AI and agents, gain insight into where collaboration is headed, and learn why Microsoft is the company to continue to bet on when it comes to building what’s next. Expect: New breakthroughs in collaboration powered by AI and agents Fresh innovations across Teams, Copilot, and SharePoint Practical guidance on how design continues to shape effective teamwork Real world demos that show how AI is transforming communication and content Insight into what is new, what is changing, and what is coming next Business Apps & Agents Keynote Charles Lamanna — President, Business Apps & Agents In this keynote, Charles Lamanna will share how Microsoft 365 Copilot, Copilot Studio, Power Apps, and Agent 365 come together to help makers build powerful agents and help IT teams deploy and govern them at scale. We’ll share how organizations can design, extend, and govern a new model for the intelligent workplace – connecting data, workflows, and systems into intelligent agents that move work forward. Copilot, apps, and agents: the next platform shift for Microsoft 365 Microsoft 365 Copilot has changed how we interact with software. Now AI agents are changing how work gets done – moving from responding to prompts to taking action, across the tools and data your organization already relies on. Expect: A clear explanation of how to leverage and build with Copilot and agents How agents access data, use tools, and complete multi-step work A deeper look at the latest capabilities across Microsoft 365 Copilot, Copilot Studio, and Power Apps End-to-end demos of agents in action Security, Trust & Responsible AI Keynote Vasu Jakkal — Corporate Vice President, Microsoft Security & Rohan Kumar — Corporate Vice President, Microsoft Security, Purview & Trust In our third keynote, Vasu Jakkal and Rohan Kumar join forces to address one of the most urgent topics of the AI era: trust and security at scale. As organizations accelerate into AI‑powered work, safeguarding identities, data, compliance, and governance is mission‑critical. Securing AI: Building Trust in the Era of AI Join Vasu Jakkal and Rohan Kumar as they unveil Microsoft’s vision for securing the new frontier of AI—showing how frontier firms are protecting their data, identities, and models amid rapid AI adoption. This session highlights how Microsoft is embedding security and governance into every layer of our AI platforms and unifying Purview, Defender, Entra, and Security Copilot to defend against threats like prompt injection, model tampering, and shadow AI. You’ll see how built-in protections across Microsoft 365 enable responsible, compliant AI innovation, and gain practical guidance to strengthen your own security posture as AI transforms the way everyone works. Expect: Microsoft's unified approach to secure AI transformation Forward‑looking insights across Security, Purview & Trust Guidance for building safe, responsible AI environments How to protect innovation without slowing momentum Future of Work Fireside Keynote Dr. Jaime Teevan — Chief Scientist & Technical Fellow, Microsoft Dr. Jaime Teevan, one of the foremost thought leaders on AI, productivity, and how work is evolving. In this intimate fireside‑style session, she’ll share research, real‑world insights, and Microsoft’s learnings from being both the maker and the first customer of the AI‑powered workplace. Expect: Insights from decades of workplace research The human side of AI transformation Practical guidance for leaders, creators, and practitioners Why collaboration is essential to unlock the true potential of AI. Community Closer Keynote Karuana Gatimu - Director, Microsoft Customer Advocacy Group & Heather Cook - Principal PM, MIcrosoft Customer Advocacy Group From Momentum to Movement: Where Community Goes Next As the final moments of Microsoft 365 Community Conference come to a close, Heather Cook and Karuana Gatimu invite the community to pause, reflect, and look forward together. This Community Closer keynote connects the breakthroughs, conversations, and shared experiences of the week into a bigger story—one about people, purpose, and progress. Together, they’ll explore how community transforms technology into impact, how advocates and builders shape what’s next across Microsoft 365, and why this moment matters more than ever. More than a recap, this session is a call to action—challenging attendees to take the energy of the conference back to their teams, regions, and communities, and turn inspiration into sustained momentum. You’ll leave not just with ideas, but with clarity, confidence, and a renewed sense of belonging—because community doesn’t end when the conference does. It’s where the real work begins. More Than Keynotes: Why You’ll Want to Be in Orlando The M365 Community Conference brings together: 200+ sessions and breakouts 21 hands‑on workshops 200+ Microsoft engineers and product leaders onsite The Microsoft Innovation Hub Ask the Experts, Meet & Greets, and Community Studio Women in Tech & Allies Luncheon SharePoint’s 25th Anniversary Celebration And an epic attendee party at Universal’s Islands of Adventure Whether you create, deploy, secure, govern, design, or lead with Microsoft 365 — this is your community, and this is your moment. Join Us for the Microsoft 365 Community Conference April 21–23, 2026 Loews Sapphire Falls & Loews Royal Pacific 👉 Register now: https://aka.ms/M365Con26 Use the SAVE150 code for $150USD off current pricing Come be part of the global community building the future of intelligent work.2.3KViews3likes2CommentsCopilot Pages & Notebooks, Microsoft Loop: IT Admin Update – December 2025
For background, check out last year's Nov 2024 IT Admin update. Here's this year's progress and summary: Many key governance, lifecycle, and compliance features for Loop workspaces and Copilot Pages & Notebooks are now available. Learn more here Key deliverables remaining: M365 Group enforcement for shared Loop workspaces Departed User workflows for Copilot Pages, Notebooks, and the My workspace in Loop Multi-Geo Create in user's PDL for shared Loop workspaces Read the rest for details What’s Delivered (since Nov 2024) Sensitivity Labels for Loop workspaces Learn more here Guest Sharing for Loop (Entra B2B: Jul 2024 | for orgs with Sensitivity Labels: Mar 2025) Learn more here Retention Labels for Loop pages and components Learn more here Admin Management: Membership, ownership, deletion, restoration, search, filter, in SharePoint Embedded Admin Center and PowerShell for containers Learn more here Promote Members to Owners for Loop workspaces Learn more here M365 Group owned workspaces: managed by M365 Groups for workspaces created within Teams channels Learn more here Also, check out the latest from Ignite 2025 on Unlocking Productivity with Copilot Pages. What’s In Progress / Coming Soon Feature / Scenario Status Target Date Notes Enforce Microsoft 365 group-owned Loop workspaces In development Q1 CY'26 - 422725 IT policy to require Microsoft 365 groups for lifecycle management of shared Loop workspaces Multi-Geo Create In development Q4 CY'25 - 421616 All new Loop workspaces saved in creator’s PDL geo Departed User Workflow In development Q1 CY’26 - 421612 Temporary or permanent reassignment of existing user-owned containers, copy capability for data URL to Open Containers in app In development Q1 CY'26 - 421612 Application Redirect URL that opens in app when clicked if user has permissions User-Accessible Recycle Bin In development H1 CY’26 - 421615 Restore deleted Copilot Pages, Notebooks from Microsoft 365 Copilot app, restore deleted workspaces from Loop app Groups as Members (tenant-owned) In development H1 CY’26 Invite Microsoft 365 groups as members to Notebooks and workspaces Graph APIs for management In development H1 CY'26 For organizations with dev teams and in house management tools Read-only members Paused Due to lower overall feedback volumes, this work is paused Target date disclaimer: dates and features are estimates and may change. For the latest status, see the Microsoft 365 Public Roadmap links. Instead of creating and repeating content directly in the post this year, our IT Admin documentation on learn.microsoft.com and the Microsoft 365 Public Roadmap has been updated based on the above. We recognize that lack of some of these capabilities may still block your rollout. Please drop questions in the comments or reach out to us through your account team. We're excited to be enabling the rollouts of Copilot Pages, Notebooks, and Loop workspaces in your organization.2.6KViews1like5CommentsNew Microsoft Purview innovations for Fabric to safely accelerate your AI transformation
As organizations adopt AI, security and governance remain core primitives for safe AI transformation and acceleration. After all, data leaders are aware of the notion that: Your AI is only as good as your data. Organizations are skeptical about AI transformation due to concerns of sensitive data oversharing and poor data quality. In fact, 86% of organizations lack visibility into AI data flows, operating in darkness about what information employees share with AI systems [1]. Compounding on this challenge, about 67% of executives are uncomfortable using data for AI due to quality concerns [2]. The challenges of data oversharing and poor data quality requires organizations to solve these issues seamlessly for the safe usage of AI. Microsoft Purview offers a modern, unified approach to help organizations secure and govern data across their entire data estate, in particular best in class integrations with M365, Microsoft Fabric, and Azure data estates, streamlining oversight and reducing complexity across the estate. At FabCon Atlanta, we’re announcing new Microsoft Purview innovations for Fabric to help seamlessly secure and confidently activate your data for AI transformation. These updates span data security and data governance, granting Fabric users to both Discover risks and prevent data oversharing in Fabric Improve governance processes and data quality across their data estate 1. Discover risks and prevent data oversharing in Fabric As data volume increases with AI usage, Microsoft Purview secures your data with capabilities such as Information Protection, Data Loss Prevention (DLP), Insider Risk Management (IRM), and Data Security Posture Management (DSPM). These capabilities work together to secure data throughout its lifecycle and now specifically for your Fabric data estate. Here are a few new Purview innovations for your Fabric estate: Microsoft Purview DLP policies to prevent data leakage for Fabric Warehouse and KQL/SQL DBs Now generally available, Microsoft Purview DLP policies allow Fabric admins to prevent data oversharing in Fabric through policy tip triggering when sensitive data is detected in assets uploaded to Warehouses. Additionally, in preview, Purview DLP enables Fabric admins to restrict access to assets with sensitive data in KQL/SQL DBs and Fabric Warehouses to prevent data oversharing. This helps admins limit access to sensitive data detected in these data sources and data stores to just asset owners and allowed collaborators. These DLP innovations expand upon the depth and breadth of existing DLP policies to ensure sensitive data in Fabric is protected. Figure 1. DLP restrict access preventing data oversharing of customer information stored in a KQL database. Microsoft Purview Insider Risk Management (IRM) indicators for Lakehouse, IRM data theft quick policy for Fabric, and IRM pay-as-you-go usage report for Fabric Microsoft Purview Insider Risk Management is now generally available for Microsoft Fabric extending its risk-detection capabilities to Microsoft Fabric lakehouses (in addition to Power BI which is supported today) by offering ready-to-use risk indicators based on risky user activities in Fabric lakehouses, such as sharing data from a Fabric lakehouse with people outside the organization . Additionally, IRM data theft policy is now generally available for security admins to create a data theft policy to detect Fabric data exfiltration, such as exporting Power BI reports. Also, organizations now have visibility into how much they are billed with the IRM pay-as-you-go usage report for Fabric, providing customers with an easy-to-use dashboard to track their consumption and predictability on costs. Figure 2. IRM identifying risky user behavior when handling data in a Fabric Lakehouse. Figure 3. Security admins can create a data theft policy to detect Fabric data exfiltration. Figure 4. Security admins can check the pay-as-you-go usage (processing units) across different workloads and activities such as the downgrading of sensitivity labels of a lakehouse through the usage report. Microsoft Purview for all Fabric Copilots and Agents Microsoft Purview currently provides capabilities in preview for all Copilots and Agents in Fabric. Organizations can: Discover data risks such as sensitive data in user prompts and responses and receive recommended actions to reduce these risks. Detect and remediate oversharing risks with Data Risk Assessments on DSPM, that identify potentially overshared, unprotected, or sensitive Fabric assets, giving teams clear visibility into where data exposure exists and enabling targeted actions—like applying labels or policies—to reduce risk and ensure Fabric data is AI‑ready and governed by design. Identify risky AI usage with Microsoft Purview Insider Risk Management to investigate risky AI usage, such as an inadvertent user who has neglected security best practices and shared sensitive data in AI. Govern AI usage with Microsoft Purview Audit, Microsoft Purview eDiscovery, retention policies, and non-compliant usage detection. Figure 5. Purview DSPM provides admins with the ability to discover data risks such as a user’s attempt to obtain historical data within a data agent in the Data Science workload in Fabric. DSPM subsequently provides actions to solve this risk. Now that we’ve covered how Purview helps secure Fabric data and AI, the next focus is ensuring Fabric users can use that data responsibly. 2. Improve governance processes and data quality across their data estate Once an organization’s data is secured for AI, the next challenge is ensuring consumers can easily find and trust the data needed for AI. This is where the Purview Unified Catalog comes in, serving as the foundation for enterprise data governance. Estate-wide data discovery provides a holistic view of the data landscape, helping prevent valuable data from being underutilized. Built-in data quality tools enable teams to measure, monitor, and remediate issues such as incomplete records, inconsistencies, and redundancies, ensuring decisions and AI outcomes are based on trusted, reliable data. Purview provides additional governance capabilities for all data consumers and governance teams and supplement those who utilize the Fabric OneLake catalog. Here are a few new innovations within the Purview Unified Catalog: Publication workflows for data products and glossary terms Now generally available, data owners can leverage Workflows in the Purview Unified Catalog to manage how data products and glossary terms are published. Customizable workflows enable governance teams to work faster to create a well curated catalog, specifically by ensuring that data products and glossary terms are published and governed responsibly. Data consumers can request access to data products and be reassured that the data is held to a certain governance standard by governance teams. Figure 6. Customizing a Workflow for publishing a glossary term in your catalog. Data quality for ungoverned assets in the Unified Catalog, including Fabric data In the Unified Catalog, Data Quality for ungoverned data assets allows organizations to run data quality on data assets, including Fabric assets, without linking them to data products. This approach enables data quality stewards to run data quality at a faster speed and on greater scale, ensuring that their organizations can democratize high quality data for AI use cases. Figure 7. Running data quality on data assets without it being associated with a data product. Looking Forward As organizations accelerate their AI ambitions, data security and governance become essential. Microsoft Purview and Microsoft Fabric deliver an integrated and unified foundation that enables organizations to innovate with confidence, ensuring data is protected, governed, and trusted for responsible AI activation. We’re committed to helping you stay ahead of evolving challenges and opportunities as you unlock more value from your data. Explore these new capabilities and join us on the journey toward a more secure, governed, and AI‑ready data future. [1] 2025 AI Security Gap: 83% of Organizations Flying Blind [2] The Importance Of Data Quality: Metrics That Drive Business SuccessIn a PnP search how long does the crawl take
In an Education tenant using SharePoint online if you add a new mapping into the PnP search because the crawled property was unpopulated how long do you have to wait before it is fully populated? Copilot chat suggested 30 minutes to 48 hours. At 48 hours and it managed to find about 45 items. I was anticipating about 900 items. 10 hours later it is still showing 45 items. How do I know if it finished the crawl or just abandoned it, whether it is actually still going or it can genuinely only find 45 items. Thank you.113Views1like3Comments