Welcome to the Microsoft Security Community!
Protect it all with Microsoft Security Eliminate gaps and get the simplified, comprehensive protection, expertise, and AI-powered solutions you need to innovate and grow in a changing world. The Microsoft Security Community is your gateway to connect, learn, and collaborate with peers, experts, and product teams. Gain access to technical discussions, webinars, and help shape Microsoft’s security products. Get there fast To stay up to date on upcoming opportunities and the latest Microsoft Security Community news, make sure to subscribe to our email list. Find the latest skilling content and on-demand videos – subscribe to the Microsoft Security Community YouTube channel. Catch the latest announcements and connect with us on LinkedIn – Microsoft Security Community and Microsoft Entra Community. Index Community Calls: January 2026 | February 2026 | March 2026 Upcoming Community Calls February 2026 RESCHEDULED FROM FEB 10 | Feb. 25 | 8:00am | Microsoft Security Store | From Alert to Resolution: Using Security Agents to Power Real‑World SOC Workflows In this webinar, we’ll show how SOC analysts can harness security agents from Microsoft Security Store to strengthen every stage of the incident lifecycle. Through realistic SOC workflows based on everyday analyst tasks, we will follow each scenario end to end, beginning with the initial alert and moving through triage, investigation, and remediation. Along the way, we’ll demonstrate how agents in Security Store streamline signal correlation, reduce manual investigation steps, and accelerate decision‑making when dealing with three of the most common incident types: phishing attacks, credential compromise, and business email compromise (BEC), helping analysts work faster and more confidently by automating key tasks, surfacing relevant insights, and improving consistency in response actions. Feb. 26 | 9:00am | Azure Network Security | Azure Firewall Integration with Microsoft Sentinel Learn how Azure Firewall integrates with Microsoft Sentinel to enhance threat visibility and streamline security investigations. This webinar will demonstrate how firewall logs and insights can be ingested into Sentinel to correlate network activity with broader security signals, enabling faster detection, deeper context, and more effective incident response. March 2026 Mar. 4 | 8:00am | Microsoft Security Store | A Day in the Life of an Identity Security Manager Powered by Security Agents In this session, you’ll see how security agents from the Microsoft Security Store help security teams amplify capacity, accelerate detection‑to‑remediation, and strengthen identity security posture. Co‑presented with identity security experts from the Microsoft Most Valuable Professionals (MVPs) community, we’ll walk through a day‑in‑the‑life of an identity protection manager—covering scenarios like password spray attacks, privileged account compromise, and dormant account exploitation. You’ll then see how security agents can take on the heavy lifting, while you remain firmly in control. Mar. 5 | 8:00am | Security Copilot Skilling Series | Conditional Access Optimization Agent: What It Is & Why It Matters Get a clear, practical look at the Conditional Access Optimization Agent—how it automates policy upkeep, simplifies operations, and uses new post‑Ignite updates like Agent Identity and dashboards to deliver smarter, standards‑aligned recommendations. Mar. 11 | 8:00am | Microsoft Security Store | A Day in the Life of an Identity Governance Manager Powered by Security Agents In this session, you’ll see how agents from the Microsoft Security Store help governance teams streamline reviews, reduce standing privilege, and close lifecycle gaps. Co‑presented with identity governance experts from the Microsoft MVP community, we’ll walk through a day‑in‑the‑life of an identity governance manager—covering scenarios like excessive access accumulation, offboarding gaps, and privileged role sprawl. You’ll see how agents can automate governance workflows while keeping you in control. Mar. 11 | 8:00am | Microsoft Entra | QR code authentication: Fast, simple sign‑in designed for Frontline Workers Frontline teams often work on shared mobile devices where typing long usernames and passwords slows everyone down. In this session, we’ll introduce the QR code authentication method in Microsoft Entra ID—a streamlined way for workers to sign in by scanning their unique QR code and entering a PIN on shared iOS/iPadOS or Android devices. No personal phones or complex credentials required. We’ll walk through the end‑to‑end experience, from enabling the method in your tenant and issuing codes to workers (via the Entra admin center or My Staff), to the on‑device sign‑in flow that gets your teams productive quickly. We’ll also cover best‑practice controls—like using Conditional Access and Shared device mode—to help you deploy with confidence. Bring your questions—we’ll host Q&A and collect product feedback to help prioritize upcoming investments. Mar. 11 | 5:00pm | Microsoft Entra | Building MCP on Entra: Design Choices for Enterprise Agents Explore approaches for integrating MCP with Microsoft Entra Agent ID. We’ll outline key considerations for identity, consent, and authorization, discuss patterns for scalable and auditable agent architectures, and share insights on interoperability. Expect practical guidance, common pitfalls, and an open forum for questions and feedback. Mar. 12 | 12:00pm (BRT) | Microsoft Intune | Novidades do Microsoft Intune - Últimos lançamentos Junte-se a nós para explorar as novidades do Microsoft Intune, incluindo os lançamentos mais recentes anunciados no Microsoft Ignite e a integração do Microsoft Security Copilot no Intune. A sessão contará com demonstrações ao vivo e um espaço interativo de perguntas e respostas, onde você poderá tirar suas dúvidas com especialistas. Mar. 18 | 1:00pm (AEDT) | Microsoft Entra | From Lockouts to Logins: Modern Account Recovery and Passkeys Lost phone, no backup? In a passwordless world, users can face total lockouts and risky helpdesk recovery. This session shows how Entra ID Account Recovery uses strong identity verification and passkey profiles to help users safely regain access. Mar. 19 | 8:00am | Microsoft Purview | Insider Risk Data Risk Graph We’re excited to share a new capability that brings Microsoft Purview Insider Risk Management (IRM) together with Microsoft Sentinel through the data risk graph (public preview) What it is: The data risk graph gives you an interactive, visual map of user activity, data movement, and risk signals—all in one place. Why it matters: Quickly investigate insider risk alerts with clear context, understand the impact of risky activities on sensitive data, accelerate response with intuitive, graph-based insights Getting started: Requires onboarding to the Sentinel data lake & graph. Needs appropriate admin/security roles and at least one IRM policy configured This session will provide practical guidance on onboarding, setup requirements, and best practices for data risk graph. Mar. 26 | 8:00am | Azure Network Security | What's New in Azure Web Application Firewall Azure Web Application Firewall (WAF) continues to evolve to help you protect your web applications against ever-changing threats. In this session, we’ll explore the latest enhancements across Azure WAF, including improvements in ruleset accuracy, threat detection, and configuration flexibility. Whether you use Application Gateway WAF or Azure Front Door WAF, this session will help you understand what’s new, what’s improved, and how to get the most from your WAF deployments. Looking for more? Join the Security Advisors! As a Security Advisor, you’ll gain early visibility into product roadmaps, participate in focus groups, and access private preview features before public release. You’ll have a direct channel to share feedback with engineering teams, influencing the direction of Microsoft Security products. The program also offers opportunities to collaborate and network with fellow end users and Microsoft product teams. Join the Security Advisors program that best fits your interests: www.aka.ms/joincommunity. Additional resources Microsoft Security Hub on Tech Community Virtual Ninja Training Courses Microsoft Security Documentation Azure Network Security GitHub Microsoft Defender for Cloud GitHub Microsoft Sentinel GitHub Microsoft Defender XDR GitHub Microsoft Defender for Cloud Apps GitHub Microsoft Defender for Identity GitHub Microsoft Purview GitHubSecurity baseline for Windows Server 2025, version 2602
Microsoft is pleased to announce the February 2026 Revision (v2602) of the security baseline package for Windows Server 2025! You can download the baseline package from the Microsoft Security Compliance Toolkit, test the recommended configurations in your environment, and customize / implement them as appropriate. Summary of Changes in This Release This release includes several changes made since the Security baseline for Windows Server 2025, version 2506 to further assist in the security of enterprise customers along with better aligning with the latest capabilities and standards. The changes include what is now depicted in the table below. Security Policy Change Summary Configure the behavior of the sudo command Configured as Enabled: Disabled on both MS and DC Configure Validation of ROCA-vulnerable WHfB keys during authentication Configured as Enabled: Block on DC to block Windows Hello for Business (WHfB) keys that are vulnerable to the Return of Coppersmith's attack (ROCA) Disable Internet Explorer 11 Launch Via COM Automation Configured as Enabled to prevent legacy scripts and applications from programmatically launching Internet Explorer 11 using COM automation interfaces Do not apply the Mark of the Web tag to files copied from insecure sources Configured as Disabled on both MS and DC Network security: Restrict NTLM: Audit Incoming NTLM Traffic Configured as Enable auditing for all accounts on both MS and DC Network security: Restrict NTLM: Audit NTLM authentication in this domain Configured as Enable all on DC Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers Configured as Audit all on both MS and DC NTLM Auditing Enhancements Already enabled by default to improve visibility into NTLM usage within your environment Prevent downloading of enclosures Remove from the baseline as it is not applicable for Windows Server 2025. It depends on IE – RSS feed Printer: Configure RPC connection settings Enforce the default, RPC over TCP with Authentication Enabled, on both MS and DC Printer: Configure RPC listener settings Configure as RPC over TCP | Kerberos on MS Printer: Impersonate a client after authentication Add RESTRICTED SERVICES\PrintSpoolerService to allow the Print Spooler’s restricted service identity to impersonate clients securely Configure the behavior of the sudo command Sudo for Windows can be used as a potential escalation of privilege vector when enabled in certain configurations. It may allow attackers or malicious insiders to run commands with elevated privileges, bypassing traditional UAC prompts. This is especially concerning in environments with Active Directory or domain controllers. We recommend to configuring the policy Configure the behavior of the sudo command (System) as Enabled with the maximum allowed sudo mode as Disabled to prevent the sudo command from being used. Configure Validation of ROCA-vulnerable WHfB keys during authentication To mitigate Windows Hello for Business (WHfB) keys that are vulnerable to the Return of Coppersmith's attack (ROCA), we recommend enabling the setting Configure Validation of ROCA-vulnerable WHfB keys during authentication (System\Security Account Manager) in a Block mode in domain controllers. To ensure there are no incompatible devices/orphaned/vulnerable keys in use that will break when blocked, please see Using WHfBTools PowerShell module for cleaning up orphaned Windows Hello for Business Keys - Microsoft Support. Note: A reboot is not required for changes to this setting to take effect. Disable Internet Explorer 11 Launch Via COM Automation Similar to the Windows 11 version 25H2 security baseline, we recommend disabling Internet Explorer 11 Launch Via COM Automation (Windows Components\Internet Explorer) to prevent legacy scripts and applications from programmatically launching Internet Explorer 11 using COM automation interfaces such as CreateObject("InternetExplorer.Application"). Allowing such behavior poses a significant risk by exposing systems to the legacy MSHTML and ActiveX components, which are vulnerable to exploitation. Do not apply the Mark of the Web tag to files copied from insecure sources We have included the setting Do not apply the Mark of the Web tag to files copied from insecure sources (Windows Components\File Explorer) configured as Disabled, which is consistent with Windows 11 security baseline. When this configuration is set to Disabled, Windows applies the Mark of the Web (MotW) tag to files copied from locations classified as Internet or other untrusted zones. This tag helps enforce additional protections such as SmartScreen checks and Office macro blocking, reducing the risk of malicious content execution. NTLM Auditing As part of our ongoing effort to help customers transition away from NTLM and adopt Kerberos for a more secure environment, we introduce new recommendations to strengthen monitoring and prepare for future NTLM restrictions on Windows Server 2025. Configure Network security: Restrict NTLM: Audit Incoming NTLM Traffic (Security Options) to Enable auditing for all accounts on both member servers and domain controllers. When enabled, the server logs events for all NTLM authentication requests that would be blocked once incoming NTLM traffic restrictions are enforced. Configure Network security: Restrict NTLM: Audit NTLM authentication in this domain (Security Options) to Enable all on domain controllers. This setting logs NTLM pass-through authentication requests from servers and accounts that would be denied when NTLM authentication restrictions are applied at the domain level. Configure Outgoing NTLM traffic to remote servers (Security Options) to Audit all on both member servers and domain controllers to log an event for each NTLM authentication request sent to a remote server, helping identify servers that still receive NTLM traffic. In addition, there are two new NTLM auditing capabilities enabled by default that were recently introduced in Windows Server 2025 and Windows 11 version 25H2. These enhancements provide detailed audit logs to help security teams monitor and investigate authentication activity, identify insecure practices, and prepare for future NTLM restrictions. Since these auditing improvements are enabled by default, no additional configuration is required, and thus the baseline does not explicitly enforce them. For more details, see Overview of NTLM auditing enhancements in Windows 11 and Windows Server 2025. Prevent Downloading of Enclosures The policy Prevent downloading of enclosures (Windows Components\RSS Feeds) has been removed from the Windows Server 2025 security baseline. This setting is not applicable to Windows Server 2025 because it depends on Internet Explorer functionality for RSS feeds. Printer security enhancements There are two new policies in Windows Server 2025 designed to significantly improve security posture of printers: Require IPPS for IPP printers (Printers) Set TLS/SSL security policy for IPP printers (Printers) Enabling these policies may cause operational challenges in environments that still rely on IPP or use self-signed or locally issued certificates. For this reason, these policies are not ter enforced in the Windows Server 2025 security baseline. However, we do recommend customers transition out of IPP or self-signed certificates and restricting them for a more secure environment. In addition, there are some changes to printer security Added RESTRICTED SERVICES\PrintSpoolerServiceto the Impersonate a client after authentication (User Rights Assignments) policy for both member servers and domain controllers, consistent with security baseline for Windows 11 version 25H2. Enforced the default setting for Configure RPC connection settings (Printers) to always use RPC over TCP with Authentication Enabled on both member servers and domain controllers. This prevents misconfiguration that could introduce security risks. Raised the security bar of the policy Configure RPC listener settings (Printers) from Negotiate (default) to Kerberos on member servers. This change encourages customers to move away from NTLM and adopt Kerberos for a more secure environment. Secure Boot certificate update To help organizations deploy, manage, and monitor the Secure Boot certificate update, Windows includes several policy settings under Administrative Templates\Windows Components\Secure Boot. These settings are deployment controls and aids. Enable Secure Boot Certificate Deployment allows an organization to explicitly initiate certificate deployment on a device. When enabled, Windows begins the Secure Boot certificate update process the next time the Secure Boot task runs. This setting does not override firmware compatibility checks or force updates onto unsupported devices. Automatic Certificate Deployment via Updates controls whether Secure Boot certificate updates are applied automatically through monthly Windows security and non‑security updates. By default, devices that Microsoft has identified as capable of safely applying the updates will receive and apply them automatically as part of cumulative servicing. If this setting is disabled, automatic deployment is blocked and certificate updates must be initiated through other supported deployment methods. Certificate Deployment via Controlled Feature Rollout allows organizations to opt devices into a Microsoft‑managed Controlled Feature Rollout for Secure Boot certificate updates. When enabled, Microsoft assists with coordinating deployment across enrolled devices to reduce risk during rollout. Devices participating in a Controlled Feature Rollout must have diagnostic data enabled. Devices that are not enrolled will not participate. Secure Boot certificate updates depend on device firmware support. Some devices have known firmware limitations that can prevent updates from being applied safely. Organizations should test representative hardware, monitor Secure Boot event logs, and consult the deployment guidance at https://aka.ms/GetSecureBoot for detailed recommendations and troubleshooting information. SMB Server hardening feature SMB Server has been susceptible to relay attacks (e.g., CVE-2025-55234), and Microsoft has released multiple features to protect against the relay attacks including SMB Server signing, which can be enabled with the setting of Microsoft network server: Digitally sign communications (always) (Security Option) SMB Server extended protection for authentication (EPA), which can be enabled with the setting of Microsoft network server: Server SPN target name validation level (Security Option) To further support customers to adopt these SMB Server hardening features, in the September 2025 Security Updates, Microsoft has released support for Audit events, across all supported in-market platforms, to audit SMB client compatibility for SMB Server signing as well as SMB Server EPA. These audit capabilities can be controlled via the two policies located at Network\Lanman Server Audit client does not support signing Audit SMB client SPN support This allows you to identify any potential device or software incompatibility issues before deploying the hardening measures that are already supported by SMB Server. Our recommendation is For domain controllers, the SMB signing is already enabled by default so there is no action needed for hardening purposes. For member servers, first enabling the two new audit features to assess the environment and then decide whether SMB Server Signing or EPA should be used to mitigate the attack vector. Please let us know your thoughts by commenting on this post or through the Security Baseline Community.Architecting Microsoft 365 Environments for Multi-National Enterprises: Lessons from the Field
Introduction In today’s global economy, enterprises rely on Microsoft 365 to empower seamless collaboration across borders. However, deploying and securing multi-national M365 environments introduces complex technical, operational, and compliance challenges. With over two decades architecting cloud environments across the Americas, EMEA and APAC, I’ve led numerous deployments and migrations requiring hybrid identity resilience, data sovereignty compliance, and global operational continuity. This article presents field-tested lessons and strategic best practices to guide architects and IT leaders in designing robust, compliant, and scalable Microsoft 365 environments for multi-national operations. Key Challenges in Multi-National M365 Deployments 1. Hybrid Identity Complexity Managing synchronization between on-premises Active Directory and Azure AD becomes exponentially complex across regions. https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity can introduce replication delays and login failures if not properly planned. Tip: Always assess latency impact on Kerberos authentication, token issuance, and Azure AD Connect synchronization cycles. 2. Data Residency and Compliance Many countries enforce strict data sovereignty laws restricting where personal and sensitive data can reside. Selecting tenant regions and enabling https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-multi-geo?view=o365-worldwide become critical to avoid compliance violations. Impact Example: A financial institution with European operations faced potential GDPR breaches until Multi-Geo was implemented to ensure Exchange Online and OneDrive data remained within EU boundaries. 3. Licensing and Cost Control Balancing E3, E5, and F3 licenses across countries with varying user roles and local currencies adds administrative and financial complexity. Best Practice: Implement https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/licensing-groups-assign, aligning assignments with security groups mapped to user personas. 4. Secure Collaboration Across Borders External sharing in SharePoint, OneDrive, and Teams federation introduces security risks if not precisely configured. Default sharing settings often exceed local compliance requirements, risking data leakage. Lesson Learned: Always validate external sharing policies against each country’s data protection laws and client contractual agreements. 5. Operational Support and SLA Alignment Global operations require support models beyond single-region business hours, demanding proactive incident response and escalation planning. Example: Implementing follow-the-sun support with regional admins trained on Microsoft 365 admin centers and PowerShell mitigates downtime risks. Strategic Solutions and Best Practices 1. Architect Hybrid Identity with Redundancy Deploy https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-staging-server in alternate datacenters. Implement Password Hash Sync to reduce dependency on VPN and WAN availability for authentication. 2. Utilize Microsoft 365 Multi-Geo Capabilities Leverage https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-multi-geo?view=o365-worldwide to meet data residency requirements per geography. Validate licensing implications and admin configurations for each satellite location. 3. Segment Licensing by User Persona Define clear user personas (executives, knowledge workers, frontline staff). Map license types accordingly, optimizing costs while ensuring productivity needs are met. Use https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/licensing-groups-assign for scalable management. 4. Design Conditional Access Policies by Geography Create https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/location-condition. Integrate with Intune compliance policies to block or limit access for non-compliant devices. 5. Implement a Global Governance Model Establish clear local vs. global admin roles to maintain accountability. Enforce https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure to control and audit privileged access. Lessons Learned from the Field Latency is a silent killer – Always test Microsoft Teams and OneDrive performance across regions before production rollouts. Communication is critical – Local IT teams must align early with global security and compliance strategies. Compliance first – Never assume Microsoft’s default data location suffices for local regulations. Cost optimization is ongoing – Conduct license audits and adjust assignments every six months. Conclusion Architecting Microsoft 365 for a multi-national enterprise demands strategic integration of compliance, hybrid identity resilience, secure collaboration, and cost optimization. Cloud success in a global enterprise is not an accident – it is architected. By applying these best practices validated against Microsoft recommendations and real-world deployments, organizations can empower global collaboration without sacrificing governance or security. About the Author Gonzalo Brown Ruiz is a Senior Office 365 Engineer with over 21 years architecting secure, compliant cloud environments across North America, Latin America, EMEA and APAC. He specializes in Microsoft Purview, Entra ID, Exchange Online, eDiscovery, and enterprise cloud security.Securing the Modern Workplace: Transitioning from Legacy Authentication to Conditional Access
Authored by: Gonzalo Brown Ruiz, Senior Microsoft 365 Engineer & Cloud Security Specialist Date: July 2025 Introduction In today’s threat landscape, legacy authentication is one of the weakest links in enterprise security. Protocols like POP, IMAP, SMTP Basic, and MAPI are inherently vulnerable — they don’t support modern authentication methods like MFA and are frequently targeted in credential stuffing and password spray attacks. Despite the known risks, many organizations still allow legacy authentication to persist for “just one app” or “just a few users.” This article outlines a real-world, enterprise-tested strategy for eliminating legacy authentication and implementing a Zero Trust-aligned Conditional Access model using Microsoft Entra ID. Why Legacy Authentication Must Die No support for MFA: Enables attackers to bypass the most critical security control Password spray heaven: Common vector for brute-force and scripted login attempts Audit blind spots: Limited logging and correlation in modern SIEM tools Blocks Zero Trust progress: Hinders enforcement of identity- and device-based policies Removing legacy auth isn’t a nice-to-have — it’s a prerequisite for a modern security strategy. Phase 1: Auditing Your Environment A successful transition starts with visibility. Before blocking anything, I led an environment-wide audit to identify: All sign-ins using legacy protocols (POP, IMAP, SMTP AUTH, MAPI) App IDs and service principals requesting basic auth Users with outdated clients (Office 2010/2013) Devices and applications integrated via PowerShell, Azure Sign-In Logs, and Workbooks Tools used: Microsoft 365 Sign-In Logs Conditional Access insights workbook PowerShell (Get-SignInLogs, Get-CASMailbox, etc.) Phase 2: Policy Design and Strategy The goal is not just to block — it’s to transform authentication securely and gradually. My Conditional Access strategy included: Blocking legacy authentication protocols while allowing scoped exceptions Report-only mode to assess potential impact Role-based access rules (admins, execs, vendors, apps) Geo-aware policies and MFA enforcement Service account handling and migration to Graph or Modern Auth-compatible apps Key considerations: Apps that support legacy auth only Delegates and shared mailbox access scenarios BYOD and conditional registration enforcement Phase 3: Staged Rollout and Enforcement A phased approach reduced friction: Pilot group enforcement (IT, InfoSec, willing users) Report-only monitoring across business units Clear communications to stakeholders and impacted users User education campaigns on legacy app retirement Gradual enforcement by department, geography, or risk tier We used Microsoft Entra’s built-in messaging and Service Health alerts to notify users of policy triggers. Phase 4: Monitoring, Tuning, and Incident Readiness Once policies were in place: Monitored Sign-in logs for policy match rates and unexpected denials Used Microsoft Defender for Identity to correlate legacy sign-in attempts Created alerts and response playbooks for blocked sign-in anomalies Results: 100% of all user and app traffic transitioned to Modern Auth Drastic reduction in brute force traffic from foreign IPs Fewer support tickets around password lockouts and MFA prompts Lessons Learned Report-only mode is your best friend. Avoids surprise outages. Communication beats configuration. Even a perfect policy fails if users are caught off guard. Legacy mail clients still exist in vendor tools and old mobile apps. Service accounts can break silently. Replace or modernize them early. CA exclusions are dangerous. Every exception must be time-bound and documented. Conclusion Eliminating legacy authentication is not just a policy update — it’s a cultural shift toward Zero Trust. By combining deep visibility, staged enforcement, and a user-centric approach, organizations can securely modernize their identity perimeter. Microsoft Entra Conditional Access is more than a policy engine — it is the architectural pillar of enterprise-grade identity security. Author’s Note: This article is based on my real-world experience designing and enforcing Conditional Access strategies across global hybrid environments with Microsoft 365 and Azure AD/Entra ID. Copyright © 2025 Gonzalo Brown Ruiz. All rights reserved.Building Enterprise-Grade DLP with Microsoft Purview in Hybrid & Multi-Cloud Environments
Authored by: Gonzalo Brown Ruiz, Senior Microsoft 365 Engineer & Cloud Security Specialist Date: July 2025 Introduction Data is the lifeblood of every modern organization, yet it remains one of the most exposed assets. As organizations embrace hybrid and multi-cloud models, traditional endpoint or email-only DLP solutions no longer provide sufficient protection. The explosion of data across Exchange, SharePoint, Teams, OneDrive, and third-party SaaS applications introduces new risks and compliance challenges. Microsoft Purview Data Loss Prevention (DLP) provides a powerful solution that unifies data governance, sensitivity labeling, and policy enforcement across your cloud ecosystem. However, building an enterprise-grade DLP strategy goes far beyond enabling policies. Why Traditional DLP Fails in Modern Environments Traditional DLP approaches often: Protect only endpoints or email without covering cloud services Lack integration with data classification and labeling frameworks Generate excessive false positives due to generic rule sets Create operational friction for end users In hybrid environments with Teams, SharePoint, and OneDrive, these limitations lead to fragmented coverage, compliance blind spots, and user workarounds that expose sensitive data. The Microsoft Purview Advantage Microsoft Purview DLP offers: Unified policy management across Exchange Online, SharePoint, Teams, and OneDrive Integration with Sensitivity Labels for data classification and encryption Real-time policy tips that educate users without blocking productivity Built-in compliance manager integration for audit readiness When architected properly, Purview becomes a strategic enabler of data governance and compliance rather than just a security checkbox. Key Components of an Enterprise-Grade DLP Strategy 1. Data Classification and Labeling Implement Sensitivity Labels with auto-labeling policies to classify and protect sensitive data at scale. 2. Policy Scoping and Exceptions Handling Design DLP policies that balance security with operational needs, incorporating exceptions for justified business processes. 3. Insider Risk Management Integration Correlate DLP events with insider risk signals to identify intentional or accidental data misuse. 4. Audit, Reporting, and Compliance Evidence Configure alerting, detailed reporting, and data residency mapping to fulfill regulatory and internal audit requirements. Implementation Framework: Your Step-by-Step Guide 1. Preparation Conduct a data inventory and sensitivity assessment Identify regulatory and contractual compliance obligations Engage business stakeholders for adoption readiness 2. Pilot Deployment Roll out policies to a controlled user group Review policy matches and refine rules to minimize false positives Provide targeted user training on policy tips and data handling expectations 3. Full Deployment Scale DLP policies across workloads (Exchange, SharePoint, Teams, OneDrive) Implement automated remediation actions with user notifications and audit logs 4. Optimization and Continuous Improvement Review policy match reports regularly to fine-tune thresholds and rules Incorporate feedback from security, compliance, and end users Integrate with eDiscovery workflows for legal readiness Best Practices and Lessons Learned Start with monitor-only policies to baseline activity before enforcing blocks Combine DLP with Sensitivity Labels and encryption policies for holistic protection Regularly educate users on data classification and handling standards Create clear governance structures for DLP ownership and policy management Balance security controls with user productivity to avoid shadow IT workarounds Conclusion Data Loss Prevention is no longer optional – it is a critical enabler of trust, compliance, and operational excellence. By architecting Microsoft Purview DLP as part of an enterprise data governance strategy, organizations can protect their most valuable asset – data – while empowering users to work securely and efficiently. Author’s Note: This article is based on my extensive professional experience designing and implementing Microsoft Purview DLP solutions for global enterprises across hybrid and multi-cloud environments. Copyright © 2025 Gonzalo Brown Ruiz. All rights reserved.Introducing Security Dashboard for AI (Now in Public Preview)
AI proliferation in the enterprise, combined with the emergence of AI governance committees and evolving AI regulations, leaves CISOs and AI risk leaders needing a clear view of their AI risks, such as data leaks, model vulnerabilities, misconfigurations, and unethical agent actions across their entire AI estate, spanning AI platforms, apps, and agents. 53% of security professionals say their current AI risk management needs improvement, presenting an opportunity to better identify, assess and manage risk effectively. 1 At the same time, 86% of leaders prefer integrated platforms over fragmented tools, citing better visibility, fewer alerts and improved efficiency. 2 To address these needs, we are excited to announce the Security Dashboard for AI, previously announced at Microsoft Ignite, is available in public preview. This unified dashboard aggregates posture and real-time risk signals from Microsoft Defender, Microsoft Entra, and Microsoft Purview - enabling users to see left-to-right across purpose-built security tools from within a single pane of glass. The dashboard equips CISOs and AI risk leaders with a governance tool to discover agents and AI apps, track AI posture and drift, and correlate risk signals to investigate and act across their entire AI ecosystem. Security teams can continue using the tools they trust while empowering security leaders to govern and collaborate effectively. Gain Unified AI Risk Visibility Consolidating risk signals from across purpose-built tools can simplify AI asset visibility and oversight, increase security teams’ efficiency, and reduce the opportunity for human error. The Security Dashboard for AI provides leaders with unified AI risk visibility by aggregating security, identity, and data risk across Defender, Entra, Purview into a single interactive dashboard experience. The Overview tab of the dashboard provides users with an AI risk scorecard, providing immediate visibility to where there may be risks for security teams to address. It also assesses an organization's implementation of Microsoft security for AI capabilities and provides recommendations for improving AI security posture. The dashboard also features an AI inventory with comprehensive views to support AI assets discovery, risk assessments, and remediation actions for broad coverage of AI agents, models, MCP servers, and applications. The dashboard provides coverage for all Microsoft AI solutions supported by Entra, Defender and Purview—including Microsoft 365 Copilot, Microsoft Copilot Studio agents, and Microsoft Foundry applications and agents—as well as third-party AI models, applications, and agents, such as Google Gemini, OpenAI ChatGPT, and MCP servers. This supports comprehensive visibility and control, regardless of where applications and agents are built. Prioritize Critical Risk with Security Copilots AI-Powered Insights Risk leaders must do more than just recognize existing risks—they also need to determine which ones pose the greatest threat to their business. The dashboard provides a consolidated view of AI-related security risks and leverages Security Copilot’s AI-powered insights to help find the most critical risks within an environment. For example, Security Copilot natural language interaction improves agent discovery and categorization, helping leaders identify unmanaged and shadow AI agents to enhance security posture. Furthermore, Security Copilot allows leaders to investigate AI risks and agent activities through prompt-based exploration, putting them in the driver’s seat for additional risk investigation. Drive Risk Mitigation By streamlining risk mitigation recommendations and automated task delegation, organizations can significantly improve the efficiency of their AI risk management processes. This approach can reduce the potential hidden AI risk and accelerate compliance efforts, helping to ensure that risk mitigation is timely and accurate. To address this, the Security Dashboard for AI evaluates how organizations put Microsoft’s AI security features into practice and offers tailored suggestions to strengthen AI security posture. It leverages Microsoft’s productivity tools for immediate action within the practitioner portal, making it easy for administrators to delegate recommendation tasks to designated users. With the Security Dashboard for AI, CISOs and risk leaders gain a clear, consolidated view of AI risks across agents, apps, and platforms—eliminating fragmented visibility, disconnected posture insights, and governance gaps as AI adoption scales. Best of all, the Security Dashboard for AI is included with eligible Microsoft security products customers already use. If an organization is already using Microsoft security products to secure AI, they are already a Security Dashboard for AI customer. Getting Started Existing Microsoft Security customers can start using Security Dashboard for AI today. It is included when a customer has the Microsoft Security products—Defender, Entra and Purview—with no additional licensing required. To begin using the Security Dashboard for AI, visit http://ai.security.microsoft.com or access the dashboard from the Defender, Entra or Purview portals. Learn more about the Security Dashboard for AI at Microsoft Security MS Learn. 1AuditBoard & Ascend2 Research. The Connected Risk Report: Uniting Teams and Insights to Drive Organizational Resilience. AuditBoard, October 2024. 2Microsoft. 2026 Data Security Index: Unifying Data Protection and AI Innovation. Microsoft Security, 2026Primer: How to Use RBAC for Applications to Control App Use of the Mail.Send Permission
The temptation to use the Mail.Send application permission in scripts can lead PowerShell developers into trouble because the permission allows access to all mailboxes, including sensitive executive and financial mailboxes. Fortunately, RBAC for Applications allows tenants to control the access that apps have to mailboxes and other Exchange content. All explained here with an example script to test RBAC of Applications. https://office365itpros.com/2026/02/17/mail-send-rbac-for-applications/Security Review for Microsoft Edge version 145
We have reviewed the new settings in Microsoft Edge version 145 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 139 security baseline continues to be our recommended configuration which can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge version 145 introduced 11 new Computer and User settings; we have included a spreadsheet listing the new settings to make it easier for you to find. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baselines Discussion site or this post.Introducing eDiscovery Graph API Standard and Enhancements to Premium APIs
We have been busy working to enable organisations that leverage the Microsoft Purview eDiscovery Graph APIs to benefit from the enhancements in the new modern experience for eDiscovery. I am pleased to share that APIs have now been updated with additional parameters to enable organisations to now benefit from the following features already present in the modern experience within the Purview Portal: Ability to control the export package structure and item naming convention Trigger advanced indexing as part of the Statistics, Add to Review and Export jobs Enables for the first time the ability to trigger HTML transcription of Teams, Viva and Copilot interaction when adding to a review set Benefit from the new statistic options such as Include Categories and Include Keyword Report More granular control of the number of versions collected of modern attachments and documents collected directly collected from OneDrive and SharePoint These changes were communicated as part of the M365 Message Center Post MC1115305. This change involved the beta version of the API calls being promoted into the V1.0 endpoint of the Graph API. The following v1.0 API calls were updated as part of this work: Search Estimate Statistics – ediscoverySearch: estimateStatistics Search Export Report - ediscoverySearch: exportReport Search Export Result - ediscoverySearch: exportResult Search Add to ReviewSet – ediscoveryReviewSet: addToReviewSet ReviewSet Export - ediscoveryReviewSet: export The majority of this blog post is intended to walk through the updates to each of these APIs and provide understanding on how to update your calls to these APIs to maintain a consistent outcome (and benefit from the new functionality). If you are new to the Microsoft Purview eDiscovery APIs you can refer to my previous blog post on how to get started with them. Getting started with the eDiscovery APIs | Microsoft Community Hub First up though, availability of the Graph API for E3 customers We are excited to announce that starting September 9, 2025, Microsoft will launch the eDiscovery Graph API Standard, a new offering designed to empower Microsoft 365 E3 customers with secure, automated data export capabilities. The new eDiscovery Graph API offers scalable, automated exports with secure credential management, improved performance and reliability for Microsoft 365 E3 customers. The new API enables automation of the search, collect, hold, and export flow from Microsoft Purview eDiscovery. While it doesn’t include premium features like Teams/Yammer conversations or advanced indexing (available only with the Premium Graph APIs), it delivers meaningful value for Microsoft 365 E3 customers needing to automate structured legal exports. Key capabilities: Export from Exchange, SharePoint, Teams, Viva Engage and OneDrive for Business Case, search, hold and export management Integration with partner/vendor workflows Support automation that takes advantage of new features within the modern user experience Pricing & Access Microsoft will offer 50 GB of included export volume per tenant per month, with additional usage billed at $10/GB—a price point that balances customer value, sustainability, and market competitiveness. The Graph API Standard will be available in public preview starting September 9. For more details on pay-as-you-go features in eDiscovery and Purview refer to the following links. Billing in eDiscovery | Microsoft Learn Enable Microsoft Purview pay-as-you-go features via subscription | Microsoft Learn Wait, but what about the custodian and noncustodial locations workflow in eDiscovery Classic (Premium)? As you are probably aware, in the modern user experience for eDiscovery there have been some changes to the Data Sources tab and how it is used in the workflow. Typically, organisations leveraging the Microsoft Purview eDiscovery APIs previously would have used the custodian and noncustodial data sources APIs to add the relevant data sources to the case using the following APIs. ediscoveryCustodian resource type - Microsoft Graph v1.0 | Microsoft Learn ediscoveryNoncustodialDataSource resource type - Microsoft Graph v1.0 | Microsoft Learn Once added via the API calls, when creating a search these locations would be bound to a search. This workflow in the API remains supported for backwards compatibility. This includes the creation of system generated case hold policies when applying holds to the locations via these APIs. Organisations can continue to use this approach with the APIs. However, to simplify your code and workflow in the APIs consider using the following API call to add additional sources directly to the search. Add additional sources - Microsoft Graph v1.0 | Microsoft Learn Some key things to note if you continue to use the custodian and noncustodial data sources APIs in your automation workflow. This will not populate the new data sources tab in the modern experience for eDiscovery They can continue to be queried via the API calls Advanced indexing triggered via these APIs will have no influence on if advanced indexing is used in jobs triggered from a search Make sure you use the new parameters to trigger advanced indexing on the job when running the Statistics, Add to Review Set and Direct Export jobs Generating Search Statistics ediscoverySearch: estimateStatistics In eDiscovery Premium (Classic) and the previous version of the APIs, generating statistics was a mandatory step before you could progress to either adding the search to a review set or triggering a direct export. With the new modern experience for eDiscovery, this step is completely optional and is not mandatory. For organizations that previously generated search statistics but never checked or used the results before moving to adding the search to a review set or triggering a direct export job, they can now skip this step. If organizations do want to continue to generate statistics, then calling the updated API with the same parameters call will continue to generate statistics for the search. An example of a previous call would look as follows: POST /security/cases/ediscoveryCases/{ediscoveryCaseId}/searches/{ediscoverySearchId}/estimateStatistics Historically this API didn’t require a request body. With the APIs now natively working with the modern experience for eDiscovery; the API call now supports a request body, enabling you to benefit from the new statistic options. Details on these new options can be found in the links below. Create a search for a case in eDiscovery | Microsoft Learn Evaluate and refine search results in eDiscovery | Microsoft Learn If a search is run without a request body it will still generate the following information: Total matches and volume Number of locations searched and the number of locations with hits Number of data sources searched and the number of data sources with hits The top five data sources that make up the most search hits matching your query Hit count by location type (mailbox versus site) As the API is now natively working with the modern experience for eDiscovery you can optionally include a request body to pass the statisticOptions parameter in the POST API call. With the changes to how Advanced Indexing works within the new UX and the additional reporting categories available, you can use the statisticsOptions parameter to trigger the generate statistic job with the additional options within the modern experience for the modern UX. The values you can include are detailed in the table below. Property Option from Portal includeRefiners Include categories: Refine your view to include people, sensitive information types, item types, and errors. includeQueryStats Include query keywords report: Assess keyword relevance for different parts of your search query. includeUnindexedStats Include partially indexed items: We'll provide details about items that weren't fully indexed. These partially indexed items might be unsearchable or partially searchable advancedIndexing Perform advanced indexing on partially indexed items: We'll try to reindex a sample of partially indexed items to determine whether they match your query. After running the query, check the Statistics page to review information about partially indexed items. Note: Can only be used if includeUnindexedStats is also included. locationsWithoutHits Exclude partially indexed items in locations without search hits: Ignore partially indexed items in locations with no matches to the search query. Checking this setting will only return partially indexed items in locations where there is already at least one hit. Note: Can only be used if includeUnindexedStats is also included. In eDiscovery Premium (Classic) the advanced indexing took place when a custodian or non-custodial data location was added to the Data Sources tab. This means that when you triggered the estimate statistics call on the search it would include results from both the native Exchange and SharePoint index as well as the Advanced Index. In the modern experience for eDiscovery, the advanced indexing runs as part of the job. However, this must be selected as an option on the job. Note that not all searches will benefit from advanced indexing, one example would be a simple date range search on a mailbox or SPO site as this will still have hits on the partially indexed items (even partial indexed email and SPO file items have date metadata in the native indexes). The following example using PowerShell and the Microsoft Graph PowerShell module and passes the new StatisticsOptions parameter to the POST call and selects all available options. # Generate estimates for the newly created search $statParams = @{ statisticsOptions = "includeRefiners,includeQueryStats,includeUnindexedStats,advancedIndexing,locationsWithoutHits" } $params = $statParams | ConvertTo-Json -Depth 10 $uri = "https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases/$caseID/searches/$searchID/estimateStatistics" Invoke-MgGraphRequest -Method Post -Uri $uri -Body $params Write-Host "Estimate statistics generation triggered for search ID: $searchID" Once run, it will create a generated statistic job with the additional options selected. Direct Export - Report ediscoverySearch: exportReport This API enables you to generate an item report directly form a search without taking the data into a review set or exporting the items that match the search. With the APIs now natively working with the modern experience for eDiscovery, new parameters have been added to the request body as well as new values available for existing parameters. The new parameters are as follows: cloudAttachmentVersion: The versions of cloud attachments to include in messages ( e.g. latest, latest 10, latest 100 or All). This controls how many versions of a file that is collected when a cloud attachment is contained within a email, teams or viva engage messages. If version shared is configured this is also always returned. documentVersion: The versions of files in SharePoint to include (e.g. latest, latest 10, latest 100 or All). This controls how many versions of a file that is collected when targeting a SharePoint or OneDrive site directly in the search. These new parameters reflect the changes made in the modern experience for eDiscovery that provides more granular control for eDiscovery managers to apply different collection options based on where the SPO item was collected from (e.g. directly from a SPO site vs a cloud attachment link included in an email). Within eDiscovery Premium (Classic) the All Document Versions option applied to both SharePoint and OneDrive files collected directly from SharePoint and any cloud attachments contained within email, teams and viva engage messages. Historically for this API, within the additionalOptions parameter you could include the allDocumentVersions value to trigger the collection of all versions of any file stored in SharePoint and OneDrive. With the APIs now natively working with the modern experience for eDiscovery, the allDocumentVersions value can still be included in the additionalOptions parameter but it will only apply to files collected directly from a SharePoint or OneDrive site. It will not influence any cloud attachments included in email, teams and viva engage messages. To collect additional versions of cloud attachments use the cloudAttachmentVersion parameter to control the number of versions that are included. Also consider moving from using the allDocumentVersions value in the additionalOptions parameter and switch to using the new documentVersion parameter. As described earlier, to benefit from advanced indexing in the modern experience for eDiscovery, you must trigger advanced indexing as part of the direct export job. Within the portal to include partially indexed items and run advanced indexing you would make the following selections. To achieve this via the API call we need to ensure we include the following parameters and values into the request body of the API call. Parameter Value Option from the portal additionalOptions advancedIndexing Perform advanced indexing on partially indexed items exportCriteria searchHits, partiallyIndexed Indexed items that match your search query and partially indexed items exportLocation responsiveLocations, nonresponsiveLocations Exclude partially indexed items in locations without search hits. Finally, in the new modern experience for eDiscovery more granular control has been introduced to enable organisations to independently choose to convert Teams, Viva Engage and Copilot interactions into HTML transcripts and the ability to collect up to 12 hours of related conversations when a message matches a search. This is reflected in the job settings by the following options: Organize conversations into HTML transcripts Include Teams and Viva Engage conversations In the classic experience this was a single option titled Teams and Yammer Conversations that did both actions and was controlled by including the teamsAndYammerConversations value in the additionalOptions parameter. With the APIs now natively working with the modern experience for eDiscovery, the teamsAndYammerConversations value can still be included in the additionalOptions parameter but it will only trigger the collection of up to 12 hours of related conversations when a message matches a search without converting the items into HTML transcripts. To do this we need to include the new value of htmlTranscripts in the additionalOptions parameter. As an example, lets look at the following direct export report job from the portal and use the Microsoft Graph PowerShell module to call the exportReport API call with the updated request body. $exportName = "New UX - Direct Export Report" $exportParams = @{ displayName = $exportName description = "Direct export report from the search" additionalOptions = "teamsAndYammerConversations,cloudAttachments,htmlTranscripts,advancedIndexing" exportCriteria = "searchHits,partiallyIndexed" documentVersion = "recent10" cloudAttachmentVersion = "recent10" exportLocation = "responsiveLocations" } $params = $exportParams | ConvertTo-Json -Depth 10 $uri = https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases/$caseID/searches/$searchID/exportReport" $exportResponse = Invoke-MgGraphRequest -Method Post -Uri $uri -Body $params Direct Export - Results ediscoverySearch: exportResult - Microsoft Graph v1.0 | Microsoft Learn This API call enables you to export the items from a search without taking the data into a review set. All the information from the above section on the changes to the exportReport API also applies to this API call. However with this API call we will actually be exporting the items from the search and not just the report. As such we need to pass in the request body information on how we want the export package to look. Previously with direct export for eDiscovery Premium (Classic) you had a three options in the UX and in the API to define the export format. Option Exchange Export Structure SharePoint / OneDrive Export Structure Individual PST files for each mailbox PST created for each mailbox. The structure of each PST is reflective of the folders within the mailbox with emails stored based on their original location in the mailbox. Emails named based on their subject. Folder for each mailbox site. Within each folder, the structure is reflective of the SharePoint/OneDrive site with documents stored based on their original location in the site. Documents are named based on their document name. Individual .msg files for each message Folder created for each mailbox. Within each folder the file structure within is reflective of the folders within the mailbox with emails stored as .msg files based on their original location in the mailbox. Emails named based on their subject. As above. Individual .eml files for each message Folder created for each mailbox. Within each folder the file structure within is reflective of the folder within the mailbox with emails stored as .eml files based on their original location in the mailbox. Emails named based on their subject As above. Historically with this API, the exportFormat parameter was used to control the desired export format. Three values could be used and they were pst, msg and eml. This parameter is still relevant but only controls how email items will be saved, either in a PST file, as individual .msg files or as individual .eml files. Note: The eml export format option is depreciated in the new UX. Going forward you should use either pst or msg. With the APIs now natively working with the modern experience for eDiscovery; we need to account for the additional flexibility customers have to control the structure of their export package. An example of the options available in the direct export job can be seen below. More information on the export package options and what they control can be found in the following link. https://learn.microsoft.com/en-gb/purview/edisc-search-export#export-package-options To support this, new values have been added to the additionalOptions parameter for this API call, these must be included in the request body otherwise the export structure will be as follows. exportFormat value Exchange Export Structure SharePoint / OneDrive Export Structure pst PST files created that containing data from multiple mailboxes. All emails contained within a single folder within the PST. Emails named a based on an assigned unique identifier (GUID) One folder for all documents. All documents contained within a single folder. Documents are named based on an assigned unique identifier (GUID) msg Folder created containing data from all mailboxes. All emails contained within a single folder stored as .msg files. Emails named a based on an assigned unique identifier (GUID) As above. The new values added to the additionalOptions parameters are as follows. They control the export package structure for both Exchange and SharePoint/OneDrive items. Property Option from Portal splitSource Organize data from different locations into separate folders or PSTs includeFolderAndPath Include folder and path of the source condensePaths Condense paths to fit within 259 characters limit friendlyName Give each item a friendly name Organizations are free to mix and match which export options they include in the request body to meet their own organizational requirements. To receive a similar output structure when previously using the pst or msg values in the exportFormat parameter I would include all of the above values in the additionalOptions parameter. For example, to generate a direct export where the email items are stored in separate PSTs per mailbox, the structure of the PST files reflects the mailbox and each items is named as per the subject of the email; I would use the Microsoft Graph PowerShell module to call the exportResults API call with the updated request body. $exportName = "New UX - DirectExportJob - PST" $exportParams = @{ displayName = $exportName description = "Direct export of items from the search" additionalOptions = "teamsAndYammerConversations,cloudAttachments,htmlTranscripts,advancedIndexing,includeFolderAndPath,splitSource,condensePaths,friendlyName" exportCriteria = "searchHits,partiallyIndexed" documentVersion = "recent10" cloudAttachmentVersion = "recent10" exportLocation = "responsiveLocations" exportFormat = "pst" } $params = $exportParams | ConvertTo-Json -Depth 10 $uri = “https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases/$caseID/searches/$searchID/exportResult" $exportResponse = Invoke-MgGraphRequest -Method Post -Uri $uri -Body $params If I want to export the email items as individual .msg files instead of storing them in PST files; I would use the Microsoft Graph PowerShell module to call the exportResults API call with the updated request body. $exportName = "New UX - DirectExportJob - MSG" $exportParams = @{ displayName = $exportName description = "Direct export of items from the search" additionalOptions = "teamsAndYammerConversations,cloudAttachments,htmlTranscripts,advancedIndexing,includeFolderAndPath,splitSource,condensePaths,friendlyName" exportCriteria = "searchHits,partiallyIndexed" documentVersion = "recent10" cloudAttachmentVersion = "recent10" exportLocation = "responsiveLocations" exportFormat = "msg" } $params = $exportParams | ConvertTo-Json -Depth 10 $uri = " https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases/$caseID/searches/$searchID/exportResult" Add to Review Set ediscoveryReviewSet: addToReviewSet This API call enables you to commit the items that match the search to a Review Set within an eDiscovery case. This enables you to review, tag, redact and filter the items that match the search without exporting the data from the M365 service boundary. Historically with this API call it was more limited compared to triggering the job via the eDiscovery Premium (Classic) UI. With the APIs now natively working with the modern experience for eDiscovery organizations can make use of the enhancements made within the modern UX and have greater flexibility in selecting the options that are relevant for your requirements. There is a lot of overlap with previous sections, specifically the “Direct Export – Report” section on what updates are required to benefit from updated API. They are as follows: Controlling the number of versions of SPO and OneDrive documents added to the review set via the new cloudAttachmentVersion and documentVersion parameters Enabling organizations to trigger the advanced indexing of partial indexed items during the add to review set job via new values added to existing parameters However there are some nuances to the parameter names and the values for this specific API call compared to the exportReport API call. For example, with this API call we use the additionalDataOptions parameter opposed to the additionalOptions parameter. As with the exportReport and exportResult APIs, there are new parameters to control the number of versions of SPO and OneDrive documents added to the review set are as follows: cloudAttachmentVersion: The versions of cloud attachments to include in messages ( e.g. latest, latest 10, latest 100 or All). This controls how many versions of a file that is collected when a cloud attachment is contained within a email, teams or viva engage messages. If version shared is configured this is also always returned. documentVersion: The versions of files in SharePoint to include (e.g. latest, latest 10, latest 100 or All). This controls how many versions of a file that is collected when targeting a SharePoint or OneDrive site directly in the search. Historically for this API call, within the additionalDataOptions parameter you could include the allVersions value to trigger the collection of all versions of any file stored in SharePoint and OneDrive. With the APIs now natively working with the modern experience for eDiscovery, the allVersions value can still be included in the additionalDataOptions parameter but it will only apply to files collected directly from a SharePoint or OneDrive site. It will not influence any cloud attachments included in email, teams and viva engage messages. To collect additional versions of cloud attachments use the cloudAttachmentVersion parameter to control the number of versions that are included. Also consider moving from using the allDocumentVersions value in the additionalDataOptions parameter and switch to using the new documentVersion parameter. To benefit from advanced indexing in the modern experience for eDiscovery, you must trigger advanced indexing as part of the add to review set job. Within the portal to include partially indexed items and run advanced indexing you would make the following selections. To achieve this via the API call we need to ensure we include the following parameters and values into the request body of the API call. Parameter Value Option from the portal additionalDataOptions advancedIndexing Perform advanced indexing on partially indexed items itemsToInclude searchHits, partiallyIndexed Indexed items that match your search query and partially indexed items additionalDataOptions locationsWithoutHits Exclude partially indexed items in locations without search hits. Historically the API call didn’t support the add to review set job options to convert Teams, Viva Engage and Copilot interactions into HTML transcripts and collect up to 12 hours of related conversations when a message matches a search. With the APIs now natively working with the modern experience for eDiscovery this is now possible by adding support for the htmlTranscripts and messageConversationExpansion values to the addtionalDataOptions parameter. As an example, let’s look at the following add to review set job from the portal and use the Microsoft Graph PowerShell module to invoke the addToReviewSet API call with the updated request body. $commitParams = @{ search = @{ id = $searchID } additionalDataOptions = "linkedFiles,advancedIndexing,htmlTranscripts,messageConversationExpansion,locationsWithoutHits" cloudAttachmentVersion = "latest" documentVersion = "latest" itemsToInclude = "searchHits,partiallyIndexed" } $params = $commitParams | ConvertTo-Json -Depth 10 $uri = "https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases/$caseID/reviewSets/$reviewSetID/addToReviewSet" Invoke-MgGraphRequest -Method Post -Uri $uri -Body $params Export from Review Set ediscoveryReviewSet: export This API call enables you to export items from a Review Set within an eDiscovery case. Historically with this API, the exportStructure parameter was used to control the desired export format. Two values could be used and they were directory and pst. This parameter has had been updated to include a new value of msg. Note: The directory value is depreciated in the new UX but remains available in v1.0 of the API call for backwards compatibility. Going forward you should use msg alongside the new exportOptions values. The exportStructure parameter will only control how email items are saved, either within PST files or as individual .msg files. With the APIs now natively working with the modern experience for eDiscovery; we need to account for the additional flexibility customers have to control the structure of their export package. An example of the options available in the direct export job can be seen below. As with the exportResults API call for direct export, new values have been added to the exportOptions parameter for this API call. The new values added to the exportOptions parameters are as follows. They control the export package structure for both Exchange and SharePoint/OneDrive items. Property Option from Portal splitSource Organize data from different locations into separate folders or PSTs includeFolderAndPath Include folder and path of the source condensePaths Condense paths to fit within 259 characters limit friendlyName Give each item a friendly name Organizations are free to mix and match which export options they include in the request body to meet their own organizational requirements. To receive an equivalent output structure when previously using the pst value in the exportStructure parameter I would include all of the above values in the exportOptions parameter within the request body. An example using the Microsoft Graph PowerShell module can be found below. $exportName = "ReviewSetExport - PST" $exportParams = @{ outputName = $exportName description = "Exporting all items from the review set" exportOptions = "originalFiles,includeFolderAndPath,splitSource,condensePaths,friendlyName" exportStructure = "pst" } $params = $exportParams | ConvertTo-Json -Depth 10 $uri = "https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases/$caseID/reviewSets/$reviewSetID/export" Invoke-MgGraphRequest -Method Post -Uri $uri -Body $params To receive an equivalent output structure when previously using the directory value in the exportStructure parameter I would instead use the msg value within the request body. As the condensed directory structure format export all items into a single folder, all named based on uniquely assigned identifier I do not need to include the new values added to the exportOptions parameter. An example using the Microsoft Graph PowerShell module can be found below. An example using the Microsoft Graph PowerShell module can be found below. $exportName = "ReviewSetExport - MSG" $exportParams = @{ outputName = $exportName description = "Exporting all items from the review set" exportOptions = "originalFiles" exportStructure = "msg" } $params = $exportParams | ConvertTo-Json -Depth 10 $uri = "https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases/$caseID/reviewSets/$reviewSetID/export" Invoke-MgGraphRequest -Method Post -Uri $uri -Body $params Continuing to use the directory value in exportStructure will produce the same output as if msg was used. Wrap Up Thank you for your time reading through this post. Hopefully you are now equipped with the information needed to make the most of the new modern experience for eDiscovery when making your Graph API calls.
