Recent Blogs
Security teams rely on scheduled scans to ensure consistent coverage across devices, detect dormant or missed threats, and meet compliance requirements. However, managing scans on Linux has tradition...
Jun 10, 2026
Background: IPM vs. Non-IPM Subtree
Every Exchange Online mailbox is organized into two parts:
IPM subtree (Interpersonal Message subtree) — the visible, user-facing part of a mailbox, designed...
Jun 10, 2026
As network and application-layer threats continue to evolve, security and infrastructure teams need more than product knowledge. They need practical, scenario-driven guidance they can apply to real w...
Jun 09, 2026
At Ignite in November, we announced that Microsoft Defender is now the only endpoint protection solution that allows data-hungry security teams to meet specific telemetry needs by optimizing their da...
Jun 09, 2026Recent Discussions
Sentinel Foundry - MCP Server (Preview) (Github Community Release)
I’ve been cooking something that a lot of people in SOC have been struggling with — especially on the engineering side of Microsoft Sentinel. Thanks to the Microsoft Security team for shaping the capabilities of Sentinel even better with Sentinel Data Lake & Modern SecOps. Today’s the day I can finally share it. Note: This is not an official Microsoft product, but it is designed to make the Sentinel Build even better (complement) with much more intelligence. 🚀 Sentinel Foundry is now in public preview with 43 tools. (Sentinel Foundry - MCP Server) It’s an MCP server built to act like the brain of a strong Sentinel engineer — helping make building, improving, and operating Sentinel far more practical, faster, and honestly more enjoyable. For a lot of teams, the challenge is not understanding what Sentinel can do. The hard part is the engineering work around it: -> Deciding what data should actually be ingested -> Building a clean, scalable Sentinel foundation -> Writing useful detections instead of noisy ones -> Balancing security value with cost -> Turning ideas into deployable engineering outputs That is exactly why I built Sentinel Foundry to help communities grow stronger. It helps with the real engineering tasks behind Sentinel — from architecture thinking to detection design, deployment planning, ingestion strategy, automation ideas, and many of the workflows outlined in the GitHub project. How does it work? Here’s one of the flagship prompts I ran with it: “Give me a complete security posture report for our workspace. Score each pillar and tell me what to prioritise.” And within seconds, it produced a structured engineering blueprint that would normally take a lot longer to pull together manually. You can see the example prompts here in what it can do: https://github.com/prabhukiranveesam/Sentinel-Foundry#what-can-it-do I want building Sentinel to feel less like repetitive engineering overhead — and more like real security engineering that is fast, creative, and enjoyable. If you work with Sentinel as a SOC L2 analyst, engineer, detection engineer, consultant, or architect, I’d genuinely love for you to try it and tell me what you think. 🔗 Public Preview: https://github.com/prabhukiranveesam/Sentinel-Foundry This is just the start of an AI era — and I’m excited to keep shaping it with more powerful features over the coming days. This is very easy to set up and will be available to all of you at no cost during this month as part of the public preview, and your feedback is extremely valuable to shape this as a powerful solution.
Exempt a specific container in MDC
I have this recommendation showing in defender. Immutable (read-only) root filesystem should be enforced for containers There are multiple containers inside AKS that are showing as "Unhealthy" airflow/db1 airflow/sql1 airflow/scheduler1 Is there a way to exempt a specific container or the whole recommendation has to be exempted. Thanks
Detecting AI agents and non-human identities in Microsoft Sentinel: the classic-agent blind spot
Build 2026 made the direction official. The industry is moving from the app era into the agent era, and Microsoft spent a real share of the keynote on securing agents across their lifecycle, from discovering what is exploitable to governing what is running in production. On the identity side the centerpiece is Microsoft Entra Agent ID, now generally available, which gives AI agents first-class identities and extends Conditional Access, Identity Protection, and full audit logging to them. That is good news for agents you build the new way. It is not the whole picture, and the gap is where most SOCs will get hurt first. Modern agents are covered. Classic agents are not. Entra Agent ID draws a hard line between two kinds of agent. Modern agents are created through the Agent ID platform, each backed by an agent identity blueprint. They carry a proper Agent ID, a full audit trail, and the complete set of governance capabilities, including Identity Protection for Agents, which establishes a baseline for an agent's normal activity and flags anomalies automatically. Classic agents are everything that came before, or that gets built outside the platform: AI agents implemented as ordinary service principals or app registrations, for example Copilot Studio agents created before Agent ID was enabled, or any home-grown automation calling Graph with client credentials. In the Entra agent registry they appear with "Has Agent ID: No," and that flag matters, because the Agent ID protections apply to identities that actually hold an Agent ID. Classic agents sit outside Identity Protection for Agents and Conditional Access for Agents. Here is the uncomfortable part. The non-human identities you already run, the service principals behind your pipelines, your integrations, your scripts, your pre-platform Copilot Studio bots, are almost all classic agents. They tend to outnumber your human accounts, they have no MFA in any meaningful sense, and a credential added to one does not show up in the Azure portal. The new platform protections do not reach them. Until you migrate them, the only place you get detection coverage on that population is your SIEM. So this is the job Sentinel does that Agent ID does not: detect risky behavior on the classic, service-principal-backed agents that the platform cannot yet protect. The telemetry you have, and the one switch people forget Three tables carry most of the signal. AADServicePrincipalSignInLogs records service principal authentications, the client-credentials sign-ins your agents and automation use. No user, no MFA, just an app proving it holds a secret or certificate. AADManagedIdentitySignInLogs does the same for managed identities. AuditLogs records directory changes, including the one that matters most for persistence: a new credential added to an application or service principal. One practical warning before any of this works. Service principal and managed identity sign-in logs are not streamed by default. You have to enable those categories explicitly in the Entra diagnostic settings feeding your workspace. Plenty of teams write the detection, never check, and never notice the table is empty. Verify that first. Detection 1: a new credential on a service principal or app Adding a secret or certificate to an existing service principal is one of the cleanest persistence techniques in a Microsoft cloud. The attacker compromises a privileged user or app, drops a fresh credential on a service principal that already holds useful Graph permissions, and now has access that survives password resets and session revocation. It maps to MITRE T1098.001, Account Manipulation: Additional Cloud Credentials. For a classic agent it is especially nasty, because there is no Identity Protection baseline watching it. // Detection 1: new secret or certificate added to an application or service principal // MITRE T1098.001 - Account Manipulation: Additional Cloud Credentials AuditLogs | where OperationName has_any ("Add service principal", "Certificates and secrets management") | where Result =~ "success" | extend Initiator = coalesce( tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)) | extend InitiatorIp = tostring(InitiatedBy.user.ipAddress) | mv-apply Target = TargetResources on ( where Target.type =~ "Application" | extend TargetName = tostring(Target.displayName), TargetId = tostring(Target.id), KeyChanges = Target.modifiedProperties ) | mv-apply Prop = KeyChanges on ( where tostring(Prop.displayName) =~ "KeyDescription" | extend NewKeys = parse_json(tostring(Prop.newValue)), OldKeys = parse_json(tostring(Prop.oldValue)) ) | extend AddedKeys = set_difference(NewKeys, OldKeys) | where array_length(AddedKeys) > 0 | project TimeGenerated, Initiator, InitiatorIp, TargetName, TargetId, AddedKeys | order by TimeGenerated desc The operation filter catches the three shapes this event takes in the log: "Add service principal," "Add service principal credentials," and "Update application - Certificates and secrets management." The modifiedProperties parsing isolates the KeyDescription change, and set_difference confirms a key was actually added rather than removed, so rotating out an old credential does not, on its own, fire the rule. False positives come from legitimate rotation and from automation that provisions app credentials (CI/CD, infrastructure as code). The initiator is the discriminant. A credential added by your deployment pipeline's service account at the usual time is routine. The same change initiated by an interactive admin out of hours, or by an account that never normally touches app credentials, is what you want to surface. Allow-list the expected initiators, not the targets. Detection 2: a classic agent signing in from a first-seen IP A service principal that has only ever authenticated from your Azure regions and suddenly signs in from somewhere new is a strong signal that its credential has been lifted and is being used elsewhere. Service principals have stable, boring network behavior, which makes a first-seen IP a far cleaner indicator for them than it is for roaming human users. This is the behavioral baseline Identity Protection gives you for free on modern agents, rebuilt in KQL for the classic ones it ignores. MITRE T1078.004, Valid Accounts: Cloud Accounts. // Detection 2: classic-agent service principal signing in from a previously unseen IP // MITRE T1078.004 - Valid Accounts: Cloud Accounts let baseline = 14d; let detection = 1d; let KnownIPs = AADServicePrincipalSignInLogs | where TimeGenerated between (ago(baseline + detection) .. ago(detection)) | where tostring(ResultType) == "0" | summarize KnownIPSet = make_set(IPAddress) by AppId; AADServicePrincipalSignInLogs | where TimeGenerated > ago(detection) | where tostring(ResultType) == "0" | lookup kind=leftouter KnownIPs on AppId | where set_has_element(KnownIPSet, IPAddress) == false | summarize FirstSeen = min(TimeGenerated), Resources = make_set(ResourceDisplayName, 10) by ServicePrincipalName, AppId, IPAddress | order by FirstSeen desc The query builds a per-application baseline of source IPs over the previous two weeks, then flags any successful sign-in today from an address outside that set. Two tuning notes. Brand-new service principals have no baseline, so they surface on first use. That is usually worth seeing once, but you can exclude AppIds younger than the baseline window if it gets noisy. And if your agents egress through shifting cloud IP ranges, widen the comparison from an exact IP to the autonomous system number or a known-range allow-list, otherwise you will chase your own infrastructure. This complements Agent ID, it does not replace it! The endgame is not to run these rules forever. It is to shrink the population they apply to. Inventory your tenant for agents marked "Has Agent ID: No," prioritize the ones holding sensitive Graph permissions, and migrate them onto the Agent ID platform, where Identity Protection and Conditional Access take over the baselining you are doing here by hand. Microsoft has signaled a migration path from classic to modern agents. Treat these two detections as the coverage you need in the meantime, and as a permanent safety net for anything that never makes the move. If you do one thing this week: enable the service principal sign-in log category, deploy detection 1, and pull a list of every service principal that had a credential added in the last 90 days. That list alone tends to be more interesting than people expect. Cheers, Marcel
Ways to fetch quarantine files
We are working with quarantine files and have a few questions: 1. Is there a public API available to retrieve quarantined files from Microsoft Defender for Endpoint? 2. Is there a documented method to map an alert or a file SHA-1/SHA-256 hash to the corresponding object in the Defender quarantine store? 3. Is there a way to retrieve quarantined files other than using a PowerShell script through the Live Response API?
Performance in scanning
We are trying to search for CUI data on internal file stores. Last week, I decided to run another discovery scan, this time using ALL instead of Policy Only. It took much longer and left the scanner server in an almost unusable state and didn’t give really any more information than the first one did. Based on my research, we need to define and set the policy before we run scans. This is the information tip from the Purview scanner settings: Scan started at: 2026-05-20 22:54:06Z Scan ended at: 2026-05-24 16:16:51Z Scan duration: 3 days, 17 hours, 22 minutes, 45 seconds Scan id: 93acb922-e2ac-4fb7-b259-d6184e7aa434 Repository: \\cab-filesrv-01.fg.com\Departments. Enforce mode is Off Scanned files:3509640 Actions: Classified:3369456 Classified as Public:14 Classified as Fg Private:3369442 Labeled:0 Remove label:0 Protected:0 Remove protection:0 Files with matched information types:572895 Skipped due to - No match:0 Skipped due to - Not supported:0 Skipped due to - Already labeled:0 Skipped due to - Already scanned:0 Skipped due to - Require justification:0 Skipped due to - Unknown reason:0 Skipped due to - Excluded:98833 Skipped due to - Attribute:0 Failed:41318Purview DLP Behaviours in Outlook Desktop
We are currently testing Microsoft Purview DLP policies for user awareness, where sensitive information shared externally triggers a policy tip, with override allowed (justification options enabled) and no blocking action configured. We are observing the following behaviours in Outlook Desktop: Inconsistent policy tip display (across Outlook Desktop Windows clients) – For some users, the policy tip renders correctly, while for others it appears with duplicated/stacked lines of text. This is occurring across users with similar configurations. Override without justification – Users are able to click “Send Anyway/Confirm and send” without selecting any justification option (e.g. business justification, manager approval, etc.), which bypasses the intended control. New Outlook: Classic Outlook: This has been observed on Outlook Desktop (Microsoft 365 Apps), including: Version 2602 (Build 19725.20170 Click-to-Run) Version 2602 (Build 16.0.19725.20126 MSO) Has anyone experienced similar behaviour with DLP policy tips or override enforcement in Outlook Desktop? Keen to understand if this is a known issue or if there are any recommended fixes or workarounds.
I just want to secure AI. DLP vs Info Protection vs DSPM vs Governance vs...
I'm with an MSP, and I've avoided Purview like the plague, because it seems to be suffering from the same 'made by marketing teams' 'strategy' the 365 documentation is. However, it's my understanding Purview policies are needed for Data control of Copilot. Here's my issue: all of these different 'solutions' sound like the exact same thing, but are pitched as if they are something different. i'm going to post a couple of descriptions for these 'solutions' to illustrate this. 'discover, label, and protect sensitive and business-critical info' 'make sure your organization can identify, monitor, and protect sensitive info across the expanding Microsoft 365 landscape' 'discover and secure all your sensitive data across Microsoft 365 and non-365 data sources' 'Discover, label, and protect sensitive and business-critical info across your multicloud data estate.' I genuinely do not have time to figure out what each of these 'solutions' are, then figure out their policies, then their giant library of settings (below)... It's not even clear to me what's active NOW, considering we never licensed Purview - but somehow have been roped into it. It SEEMS like these are all variations of marketing terms, which all point to 3-4 actual technical implementations in obscure ways. Can someone advise on the ACTUAL technical policies we want to target and enable? Or just give some clarity? I've never felt so overwhelmed or disconnected from Microsoft's environment. We just want to secure our tenant's AI usage.
Prompted to sign in to Microsoft Defender Platform on W11/W2025 using Entra
Hi Microsoft Defender XDR community, Since around May 18th, our users on devices that are onboarded to Microsoft Defender for Endpoint are being prompted to sign-in to the following application using Entra on login to Windows. Application Microsoft Defender Platform Application ID cab96880-db5b-4e15-90a7-f3f1d62ffe39 Is anyone aware of a change that requires user sign-in to Entra as a requirement for Microsoft Defender for Endpoint? I have tried raising a support topic on this topic. Regards Chris
Unified Catalog Self-serve analytics integration
I'm hoping someone has gone through the process of setting up the Self-serve analytics in the Unified Catalog settings to push the Unified Catalog information down to a Fabric Lakehouse. I created a Workspace, and then created a lakehouse in this workspace, and created a folder under the files section in the lakehouse. I used the MSI that is shown in Purview when you configure the storage for the connection and granted it contriubutor access to the Workspace. I then went into Purview, settings for Unified Catalog, and in the solution integrations, set up Fabric storage and provided the URL to the File folder I set up on the lakehouse. I tested the connection and it tested successfully. When I set up the scheduler to run, I received the following: The blacked out is the Workspace ID. I'm trying to understand what I'm missing, I'm assuming write permissions are missing somewhere, but I'm not sure. Any assistance is appreciated.MSSP migration to Unified portal: how are you sequencing your customer portfolio?
Following the automation and SOAR discussion, I wanted to open a conversation specifically focused on the MSSP and multi-tenant side of the migration, because this is where the coordination challenges are an order of magnitude higher than the technical ones. A few things I am working through before writing this up as Part 5 of the migration series. On Workspace Manager: Microsoft's own documentation now points you away from Workspace Manager at the point of onboarding to the Defender portal, directing you to Microsoft Defender multitenant management instead. For MSSPs who built their operating model around Workspace Manager, this is a significant structural change. For those implementing now, the recommendation is to go straight to the multitenant portal. I am interested in what the transition has looked like in practice for teams who were mid-flight on Workspace Manager when this became clear. On access delegation: one of the more honest framings I want to include in the article is around the GDAP plus Unified RBAC gap. A Microsoft employee confirmed in the RSAC 2026 thread that Unified RBAC support for GDAP in the Defender portal is on the roadmap with no firm date. MSSPs choosing between Entra B2B and the governance relationships model today are making an architectural call that is difficult to reverse. I want to present this accurately, and real experience from practitioners will sharpen that framing. On the connector deployment constraint: you cannot deploy connectors from a managed workspace configured with Azure Lighthouse alone, you also need GDAP. This makes a layered delegation architecture, Lighthouse plus GDAP plus B2B or governance relationships, necessary rather than optional. I am curious whether MSSPs are already running this layered model or whether most are still trying to make Lighthouse work as a single mechanism. On migration sequencing: the question I want to ask specifically is how teams are structuring their customer portfolio migration. Are you running waves based on customer complexity, based on contract renewal timing, based on customer risk appetite, or some other factor? And when something goes wrong in one tenant's migration, how are you containing the impact on the rest of the programme? Sharing the full article once it is written. Happy to discuss anything above in more detail in the thread.
Filtrer les résultats de la recherche des produits de données à l'aide des termes de glossaire
Bonjour, Je teste Microsoft Purview (Unified Catalog) avec des produits de données auxquels j’ai associé des termes de glossaire. Les termes de glossaire sont publiés et visibles dans l’onglet Découverte → Glossaire d’entreprise. Les produits de données sont également publiés et retrouvables via la recherche. Cependant, je ne vois pas d’option (ou elle ne retourne aucun résultat) pour filtrer les résultats de recherche des produits de données par termes de glossaire, contrairement à d’autres filtres disponibles (ex. Propriétaire, Type de produit). Est-ce que le filtrage des produits de données par termes de glossaire est supporté dans l’onglet Découverte ? Si oui, y a-t-il des pré-requis ou conditions particulières (ex. type de glossaire, indexation/délai, association au niveau data product vs assets, etc.) ?
Risky sign-ins not showing anything
Hi, For some time already, I am not sure why but I cannot see anything in risky sign-ins in Identity Protection (MS Entra). Even when I receive a summary email (Microsoft Entra ID Protection Weekly Digest) mentioning there were risky sinn-ings detected. When I click on the risky signings directly in the email to take me to the report, I see no data there at all... When I modify filters to include all, nothing shows up either. It has been like this for few months already. Before, I could see them with no issues. Has anything changed? Or why I can't see any records?Operational Notes on Microsoft Security Copilot Agents in Defender XDR and Microsoft Entra ID
Microsoft Security Copilot is now becoming more visible inside day-to-day security operations, especially through embedded experiences and agent-based workflows across Microsoft Defender XDR, Microsoft Entra ID, Microsoft Intune, and Microsoft Purview. Instead of looking at Security Copilot only as a standalone prompt interface, SOC and identity teams should also understand how Security Copilot agents are deployed, how they consume Security Compute Units, how they appear in operational workflows, and where activity can be monitored. This post summarizes practical observations from a security operations perspective, with a focus on Microsoft Defender XDR, Microsoft Entra ID, usage monitoring, and KQL-based activity review. Licensing & Capacity Units Requirements Requires eligible Microsoft security licensing, typically: Microsoft 365 E5 Microsoft 365 E7 Security Compute Units (SCUs) Security Copilot capacity is measured using Security Compute Units (SCUs). SCUs are billed based on provisioned capacity. Indicative pricing: $4 per Provisionied SCU/hour $6 per Overage SCU/hour Billing is calculated hourly, based on the amount of SCUs provisioned. Included Capacity Organizations with: 1,000 Microsoft 365 E5 licenses Receive: 400 included SCUs Included SCUs are shared across the tenant within a common capacity pool. Scaling SCU capacity can be scaled dynamically based on operational requirements and workload demand. Data Retention Security Copilot session and interaction data without active SCU-backed retention is typically retained for: 90 days Security Copilot Agents - Microsoft Defender This section outlines the Microsoft Security Copilot agents currently available in the Microsoft Defender portal. NameKey characteristics Security Alert Triage Agent (Preview) Manual setup from Defender portal Automatically creates Unified RBAC custom role Runs automatically when a user reports a suspicious email or when a new supported alert is generated, supported alert sources: MDI, MDC, MDO If an alert tuning rule is enabled, it will be automatically disabled when the agent is deployed. Creates and connects with agentic user account: Phishing Triage Agent (Security Copilot) Automatic alert assignment to SecurityCopilotAgentUser-db16fec3-f1fb-4632-843e-46d07408c584@<tenant-domain>Alert was assigned to Phishing Triage Agent (Security Copilot). Adds Tag Agent to the created Incidents Threat Hunting Agent Manual setup from Defender portal Automatically creates Unified RBAC custom role This agent runs manually. There isn't an automatic trigger. Creates and connects with agentic user account: Threat Hunting Agent (Security Copilot) Analyst Questions in natural language Generates and executed KQL queries in Advanced hunting Provides charts, dynamic follow-up questions and remediation actions recommendations No activity is identified from agent's identity during agent execution Threat Intelligence Briefing Agent Manual setup from Defender portal Provides automated TI briefing summary Configured from https://security.microsoft.com/securitysettings/defender/agent_configuration-threatintelligencebriefingagent Security Analyst Agent Manual setup from Defender portal Dynamic Threat Detection Agent (Preview) Automatically enabled always-on, runs continuously in the background Correlates: Alerts, Security events, Behavioral anomalies, TI signals Generates Alerts with Detection Source: Security Copilot The Alerts can be correlated with existing Multi-Stage Incidents No agentic user account identity is used by this agent Available free of charge during public preview, will begin consuming Security Compute Units (SCUs) once generally available (GA) Incidents handled by Security Alert Triage Agent: Alerts created by Dynamic Threat Detection Agent: Execution of Threat Hunting Agent: View agents in use: https://security.microsoft.com/security-copilot/agents View Unified RBAC custom roles: https://security.microsoft.com/mtp_roles View Security Copilot user identities in Microsoft Entra ID: Notes: CloudAppEvents activity logs only from the following agents: Phishing Triage Agent Conditional Access Optimization Agent Security Copilot Agents - Microsoft Entra ID Conditional Access Optimization Agent Usage Monitoring Sign-in to Security Copilot portal using Global Admin account and navigate to the following location: https://securitycopilot.microsoft.com/usage-monitoring Reference: https://learn.microsoft.com/en-us/copilot/security/manage-usage Logging Activity Copilot Agents Management: CloudAppEvents | where ActionType contains "CopilotAgent" | extend AgentName = RawEventData.AgentName | extend Workload = RawEventData.Workload | extend ResultStatus = RawEventData.ResultStatus | project TimeGenerated, ActionType, ResultStatus, AgentName, Application, Workload All Copilot Workload data: CloudAppEvents | extend Workload = RawEventData.Workload | where Workload == "Copilot" | summarize EventCount = count() by ActionType, AccountDisplayNameNo way to automate restoring user‑reported emails after “no threats found”
When a user reports an email as phishing in Defender, the message gets moved to Deleted Items. After we triage it, if we mark it as “no threats found,” there’s no way to push it back to the user’s inbox as part of that workflow. That creates a bit of a broken experience: User is told the email is safe with our customized email response, but has to go find it themselves In a lot of cases they don’t (Outlook search won’t find it) We end up with follow‑ups like “where did it go?” Technically we could restore the email as part of our triage process, but that just shifts the effort onto the SOC. It doesn’t scale, and it’s not really the right place for that work. We have tried to create an automation to do this, but we have not been able to create an advanced hunting query based on our triage result that can then trigger an action to restore it to the mailbox. So we end up choosing between: Users having a bad experience, or Analysts doing manual mailbox work Neither is ideal. Other platforms (like Proofpoint) handle this end‑to‑end — once something is confirmed clean, it can be returned to the user automatically. Right now Defender stops at classification instead of completing the workflow. Is there a reason this isn’t wired in, or anything on the roadmap to address it?June 4 - Secure Boot AMA
Microsoft is updating the Secure Boot certificates originally issued in 2011 to ensure Windows devices continue to verify trusted boot software. These older certificates begin expiring in June 2026. Devices that haven’t received the newer 2023 certificates will continue to start and operate normally, and standard Windows updates will continue to install. However, these devices will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities. Whether you are already working through Secure Boot certificate updates across your estate, or aren't sure where to start, you can get answers to your questions and helpful insights at the next Secure Boot AMA on 8:00 a.m. PDT June 4, 2026. Can't attend live? No problem. Post your questions in advance. Visit https://aka.ms/AMA/SecureBoot to save the date and post your questions. For detailed, step-by-step guidance, see the following resources: Secure Boot Playbook for Windows client Secure Boot playbook for Windows Server Secure Boot Certificate Updates for Windows 365 Secure Boot Certificate Updates for Azure Virtual DesktopSentinelHealth: Scheduled Rule Retry Logging Does Not Match Docs
## Objective I am working on a health checks architecture for Microsoft Sentinel analytic rules. The goal is to build a set of monitoring queries/approaches that cover rule execution failures, configuration issues (entity mapping, partial success), rule audit tracking, and auto-disabled rule detection. ## My Current Approach So far I have built monitoring for the following areas using the SentinelHealth and SentinelAudit tables: - Scheduled rule window failures (retry exhaustion) - NRT rule execution delays (cumulative delay over 25 minutes) - Partial success and configuration issues (entity mapping drops, alert size limits, semantic errors) with transient error codes filtered out - Auto-disabled rules detection - Rule disable/delete audit tracking via SentinelAudit + AzActivity ## The Issue: Scheduled Rule Retry Logging The documentation at https://learn.microsoft.com/en-us/azure/sentinel/monitor-analytics-rule-integrity#scheduled-rules states that when a scheduled rule fails, it is retried 5 more times on the same window (6 total attempts). It also provides this query to detect completely skipped windows: ```kql _SentinelHealth() | where SentinelResourceType == @"Analytics Rule" | where SentinelResourceKind == "Scheduled" | where Status != "Success" | extend startTime = tostring(ExtendedProperties["QueryStartTimeUTC"]) | summarize failuresByStartTime = count() by startTime, SentinelResourceId | where failuresByStartTime == 6 | summarize count() by SentinelResourceId ``` This query assumes that each retry attempt is logged as a separate event in SentinelHealth, all sharing the same QueryStartTimeUTC. You would then count 6 failure records per startTime to identify a fully skipped window. However, in practice I am seeing different behavior. I ran a diagnostic query with a 90-day lookback (480 non-success events total, 73 unique rules). Every single event had a count of 1 per unique (SentinelResourceName, startTime) combination. No grouping of retries was observed at all. I then found an actual failed-window event that confirms this. Here is the record: - Rule: Port scan detected (ASIM Network Session schema) - Status: Failure - Description: "Rule's scheduled run at 06/01/2026 10:43:55 failed after numerous attempts. It will be re-executed over the next scheduled time." - Issue Code: SemanticErrorInQuery - Only 1 SentinelHealth record exists for this failed window The Description field says "failed after numerous attempts" which indicates the retries happened internally, but only one consolidated Failure event was written to SentinelHealth after all retries were exhausted. The individual retry attempts do not appear as separate records. This means the failuresByStartTime == 6 query from the documentation would never match this pattern, because there is only 1 record per failed window, not 6. ## Why This Matters Yes, completely skipped windows are rare. In my 90-day dataset most failures were permanent types (SemanticErrorInQuery, QueryGeneralError) that would not benefit from retries anyway. But they still happen, and if a tenant experiences a transient issue that causes a higher rate of failed windows, the documented query would silently return nothing. For my health checks I have rewritten the detection to simply look for Status == "Failure" with Description containing "failed after numerous attempts" which matches the actual consolidated event Sentinel writes. ## Questions Is the documented failuresByStartTime == 6 query still accurate? Or has the retry logging behavior changed to write a single consolidated event per failed window? Are there specific failure types or conditions where individual retries are logged as separate events? Perhaps transient failures behave differently from permanent ones in this regard? For anyone else building health monitoring on SentinelHealth - am I missing any important use cases beyond what I described above? Any clarification would be appreciated.
Events
Modern identity security means stopping attacks before they escalate and extending protection beyond human users to apps and agentic identities across your identity fabric.
Learn how Microsoft Entr...
Online
Join us for a live demo and AMA on the Microsoft Sentinel SIEM migration experience. We’ll show how the experience helps teams move from legacy SIEMs like Splunk and QRadar into Microsoft Sentinel wi...
Online