<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Microsoft Sentinel Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 02 Oct 2026 08:09:47 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Has anyone tried using Sentinel as the SIEM for a fully remote company?</title>
                        <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/has-anyone-tried-using-sentinel-as-the-siem-for-a-fully-remote-company-2/</link>
                        <pubDate>Mon, 28 Sep 2026 21:36:12 +0000</pubDate>
                        <description><![CDATA[As an enterprise licensing specialist who has recently been involved in several procurements for distributed organizations, I am analyzing the operational and contractual implications of dep...]]></description>
                        <content:encoded><![CDATA[As an enterprise licensing specialist who has recently been involved in several procurements for distributed organizations, I am analyzing the operational and contractual implications of deploying Microsoft Sentinel in a fully remote, cloud-native environment. The traditional SIEM model often presupposes a corporate network perimeter or on-premises data sources, which are largely irrelevant for a company where endpoints, identities, and applications are entirely cloud-based and geographically dispersed.

My primary inquiry is whether community members have implemented Sentinel under these conditions and can speak to the following specific facets:

*   **Data Source Integration &amp; Log Collection:** The feasibility and cost efficiency of ingesting logs exclusively from cloud services (e.g., Entra ID, Microsoft 365 Defender, SaaS applications via REST API connectors, cloud infrastructure logs from AWS/GCP/Azure). A key concern is the absence of traditional firewall or on-premises server logs, shifting the focus entirely to identity, cloud workload, and endpoint detection and response (EDR) signals.
*   **Agent Deployment &amp; Management for Remote Endpoints:** The practicalities of deploying the Log Analytics agent (AMA) or other required agents to a fleet of remote, non-domain-joined laptops. This touches on:
    *   Scalability of deployment via Intune or similar MDM.
    *   Network bandwidth considerations for agents in home offices transmitting data directly to the cloud workspace.
    *   Security and compliance of the agent itself on uncontrolled networks.
*   **Licensing &amp; Cost Structure Analysis:** The cost model for a fully remote company can differ significantly. Without on-premises data, the commitment to a per-GB pricing tier may be more predictable, but one must rigorously assess:
    *   The volume of ingested security data from the listed cloud sources.
    *   The potential need for additional Entra ID P1/P2 licenses for advanced identity protection signals.
    *   The alignment of Microsoft 365 E5 licensing, if present, with Sentinel costs.
*   **Vendor Management &amp; Compliance:** Ensuring that the configuration and data residency of the Sentinel workspace comply with regulatory requirements when all employees are remote, potentially across multiple jurisdictions. This includes a review of the Microsoft Data Protection Addendum and mapping of data processing locations.

I am particularly interested in structured comparisons between this setup and a more traditional hybrid environment, with caveats on where the fully remote model introduces unique complexities or, conversely, simplifications. Any insights into negotiation points with Microsoft regarding commitment tiers based on this usage profile would also be highly valuable.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-microsoft-sentinel/">Microsoft Sentinel Reviews</category>                        <dc:creator>angela w</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-microsoft-sentinel/has-anyone-tried-using-sentinel-as-the-siem-for-a-fully-remote-company-2/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the Fusion detection rules - do they ever generate useful incidents?</title>
                        <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/thoughts-on-the-fusion-detection-rules-do-they-ever-generate-useful-incidents-2/</link>
                        <pubDate>Mon, 28 Sep 2026 13:00:47 +0000</pubDate>
                        <description><![CDATA[Been running Sentinel for a few months now, mostly for AWS workload monitoring. The Fusion ML-based detection rules caught my eye—sounded like a great way to connect the dots automatically.
...]]></description>
                        <content:encoded><![CDATA[Been running Sentinel for a few months now, mostly for AWS workload monitoring. The Fusion ML-based detection rules caught my eye—sounded like a great way to connect the dots automatically.

But honestly? I've yet to see a single Fusion incident that felt actionable. They seem to fire for weird, nebulous combos that are impossible to triage. My team just ends up dismissing them. Example from last week:
- **Rule:** "Multiple alerts related to resource deployment and subsequent execution detected"
- **Reality:** A dev debugging a Terraform script + a scheduled Lambda run. Zero malice.

Anyone else have a different experience? Have you tuned them somehow, or are they just noise? Would love to see a screenshot of a *useful* Fusion incident!

#savings]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-microsoft-sentinel/">Microsoft Sentinel Reviews</category>                        <dc:creator>cloud_cost_owen</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-microsoft-sentinel/thoughts-on-the-fusion-detection-rules-do-they-ever-generate-useful-incidents-2/</guid>
                    </item>
				                    <item>
                        <title>Sentinel pricing feedback - hidden costs in a 1000-query-per-day setup</title>
                        <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/sentinel-pricing-feedback-hidden-costs-in-a-1000-query-per-day-setup-2/</link>
                        <pubDate>Mon, 28 Sep 2026 04:11:15 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s talk about the sticker shock. You see the per-GB ingestion cost for Sentinel and think, &quot;Okay, 1000 queries a day, we can model that.&quot; Then the bill arrives and it&#039;s 40% highe...]]></description>
                        <content:encoded><![CDATA[Alright, let's talk about the sticker shock. You see the per-GB ingestion cost for Sentinel and think, "Okay, 1000 queries a day, we can model that." Then the bill arrives and it's 40% higher. Been there.

The hidden tax isn't in the queries themselves, it's in the data they *touch*. Run a KQL query over 30 days of logs? You're not charged for the query execution. You're charged for the data scanned to fulfill it. A poorly optimized query or a broad search can scan terabytes, even if it returns three rows. Microsoft calls this "data scanned for processed queries." It's buried in the cost analysis, not the simple calculator.

Then there's the analytics rule execution. Every scheduled alert rule is a query, and it scans data. More rules, more frequent execution, more scans. That "1000 queries" estimate often ignores the dozen rules firing every 5 minutes. Also, watch for Azure Monitor Action Groups triggering from those alerts—if you're using SMS or voice, that's another line item entirely.

And don't get me started on the "free" data types. Yes, some like AzureActivity are free to ingest, but querying them still incurs that scan cost. So your "free" data isn't free to analyze at scale. The pricing model essentially penalizes investigation and hunting. You become frugal with your own data.

So, for anyone budgeting: your primary variables are 1) ingestion volume, 2) data retention volume, and 3) query/analytics rule *scan volume*. That last one is the silent killer. You need to monitor your "Log Analytics data scanned" metric religiously, not just your ingestion. Otherwise, you're just guessing.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-microsoft-sentinel/">Microsoft Sentinel Reviews</category>                        <dc:creator>data_skeptic_ray</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-microsoft-sentinel/sentinel-pricing-feedback-hidden-costs-in-a-1000-query-per-day-setup-2/</guid>
                    </item>
				                    <item>
                        <title>Migrated from QRadar to Sentinel - deployment pitfalls and wins</title>
                        <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/migrated-from-qradar-to-sentinel-deployment-pitfalls-and-wins-2/</link>
                        <pubDate>Sun, 27 Sep 2026 11:51:15 +0000</pubDate>
                        <description><![CDATA[Having recently completed a migration of a significant SIEM workload from IBM QRadar to Microsoft Sentinel, I found the process to be a fascinating exercise in data pipeline re-engineering. ...]]></description>
                        <content:encoded><![CDATA[Having recently completed a migration of a significant SIEM workload from IBM QRadar to Microsoft Sentinel, I found the process to be a fascinating exercise in data pipeline re-engineering. The core challenge, from my data engineering perspective, was less about the security logic and more about reconfiguring the continuous, reliable flow of telemetry into a new normalization and enrichment framework. I will outline the key architectural pitfalls encountered and the subsequent wins realized in operational efficiency.

**Primary Pitfalls: Ingestion &amp; Parsing**

*   **Custom Log Source Onboarding:** In QRadar, we heavily utilized DSM editors and custom regex. Sentinel's approach via DCR-based Custom Tables (AMA) is more powerful but requires a shift to a declarative, JSON-based schema definition. The initial pitfall was attempting a 1:1 translation of legacy parsing logic. We learned that embracing the transformation rules within the Data Collection Rules (DCRs) themselves was crucial.
    *   Example: A complex multi-line application log required a parsing rule in the DCR to extract the core event before Sentinel ingestion, rather than relying on post-ingestion KQL parse statements.

    ```json
    // Example snippet of a DCR transformation to extract a timestamp and severity
    "transformKql": "source | extend parsedTimestamp = todatetime(substring(Message, 0, 23)) | extend Severity = substring(Message, 24, 5) | project-away Message | project parsedTimestamp, Severity, ..."
    ```

*   **Stateful vs. Stateless Enrichment:** QRadar's reference data maps and custom properties often handled enrichment at the time of ingestion. Our pitfall was replicating this by defaulting to Azure Functions for every lookup. The win came from strategically using **Sentinel Watchlists** for static or slow-changing data and reserving real-time API calls (via Logic Apps or Functions) only for absolute necessities, significantly reducing alert latency and cost.

**Notable Wins: Orchestration &amp; Analytics**

*   **Analytics Rule as Code:** The ability to manage Analytics Rules through ARM/Bicep templates and CI/CD pipelines was a substantial operational win. This allowed for version control, peer review, and automated deployment of detection logic—a stark improvement over QRadar's manual UI process.
*   **Integration with Modern Data Stack:** While not a direct Sentinel feature, the ability to route logs via Event Hubs to other platforms (like BigQuery for long-term, cost-effective retention and advanced analytics via dbt) created a more resilient and flexible architecture. Sentinel became the real-time detection layer, while the historical data pipeline was optimized separately.
*   **KQL vs. AQL:** The power of Kusto Query Language (KQL) for investigators is well-documented. From a pipeline perspective, the win was the consistency of a single language across ingestion transformations (in DCRs), detection rules, and hunting queries, reducing the cognitive load compared to switching between AQL and other languages in the QRadar ecosystem.

**Key Takeaway for Pipeline Engineers:** Treat the migration as a data model migration project. First, map your QRadar log sources, parsed fields, and enrichment keys to the Azure Monitor Common Schema and Sentinel-specific tables. This upfront modeling work, though tedious, prevents the "lift-and-shift" trap that leads to bloated costs and ineffective alerting in the new environment. The outcome for us was not just a new SIEM, but a more automated, maintainable, and scalable security telemetry pipeline.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-microsoft-sentinel/">Microsoft Sentinel Reviews</category>                        <dc:creator>data_pipeline_tinker</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-microsoft-sentinel/migrated-from-qradar-to-sentinel-deployment-pitfalls-and-wins-2/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Onboarding a non-Azure Linux server with the AMA agent</title>
                        <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/step-by-step-onboarding-a-non-azure-linux-server-with-the-ama-agent/</link>
                        <pubDate>Fri, 25 Sep 2026 11:41:21 +0000</pubDate>
                        <description><![CDATA[I&#039;ve seen a few questions recently about extending Sentinel&#039;s reach to on-premises or non-Azure cloud Linux servers. While the Azure Monitor Agent (AMA) is the modern path, the steps can fee...]]></description>
                        <content:encoded><![CDATA[I've seen a few questions recently about extending Sentinel's reach to on-premises or non-Azure cloud Linux servers. While the Azure Monitor Agent (AMA) is the modern path, the steps can feel scattered if you're not doing it daily. Let's walk through a clean, vendor-neutral setup focusing on the common pain points.

The core prerequisites you'll need in place are:
* A Log Analytics workspace (your Sentinel-connected one).
* The appropriate permissions in Azure (at least Contributor on the workspace, plus the ability to create Managed Identities if needed).
* Root or sudo access on your target Linux server.
* Network connectivity from the server to the Azure endpoints (typically `*.ods.opinsights.azure.com` and `*.oms.opinsights.azure.com` on TCP 443).

Here's the high-level workflow we'll follow:

1. **Create the Data Collection Rule (DCR) in Azure.** This is the central configuration that defines *what* logs you're collecting and *where* they go. You'll create a DCR, associate it with your workspace, add a Data Source (like Syslog or custom logs), and create an association with the "Azure Monitor Linux Agent" resource you'll define next.

2. **Generate the onboarding command.** In the DCR under the "Agents" section, use the "Download and install agent" button. This gives you a curated bash command with a unique identifier for your DCR. This step often trips people up—you need this DCR-specific command, not a generic agent install script.

3. **Execute the command on your Linux server.** Copy the command and run it in your server's shell. The script handles installing the AMA package, registering the system with the DCR, and applying the collection configuration. Watch for clean output with no authentication errors.

The biggest gotcha is authentication. The default method uses a system-assigned Managed Identity created during installation. Ensure your server can reach the Azure Instance Metadata Service (IMDS) endpoint if you're in a non-Azure environment, as this method may not work. In that case, you may need to explore service principal-based authentication, which is a more complex setup.

Once installed, you can check the agent status with `sudo azcmagent show` and look for log data in your Sentinel workspace under the usual `Syslog` or `CustomLogs_CL` tables after 5-10 minutes.

Has anyone run into specific hurdles with the network proxy configuration or service principal auth for AMA on, say, an AWS EC2 instance? Sharing those real-world pitfalls would be valuable for the community.

- mod hj]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-microsoft-sentinel/">Microsoft Sentinel Reviews</category>                        <dc:creator>Harper James</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-microsoft-sentinel/step-by-step-onboarding-a-non-azure-linux-server-with-the-ama-agent/</guid>
                    </item>
				                    <item>
                        <title>Why is Microsoft Sentinel so expensive for small teams?</title>
                        <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/why-is-microsoft-sentinel-so-expensive-for-small-teams-2/</link>
                        <pubDate>Mon, 24 Aug 2026 09:10:57 +0000</pubDate>
                        <description><![CDATA[Because it&#039;s built for Azure&#039;s scale, not yours. The pricing model assumes you&#039;re already drinking the Microsoft Kool-Aid with a massive cloud footprint.

You&#039;re paying for log ingestion by ...]]></description>
                        <content:encoded><![CDATA[Because it's built for Azure's scale, not yours. The pricing model assumes you're already drinking the Microsoft Kool-Aid with a massive cloud footprint.

You're paying for log ingestion by the GB. Sounds simple until you realize basic security logging from a handful of servers and your SaaS apps adds up fast. The "per GB" cost is a black box. Need to retain data for compliance? That's extra. Want to actually *use* the data with custom analytics or automation? That's a separate cost unit (Kusto Query Units). It's death by a thousand line items.

Compared to a platform like, say, a streamlined CRM where you pay per seat and get predictable tools, Sentinel feels like you're being billed for the engine room of a cruise ship when you just have a speedboat. The value only materializes if you're a large enterprise with a full-time SOC team to build and manage everything. For a small team, it's overkill and the bill is a nasty surprise.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-microsoft-sentinel/">Microsoft Sentinel Reviews</category>                        <dc:creator>crm_hopper</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-microsoft-sentinel/why-is-microsoft-sentinel-so-expensive-for-small-teams-2/</guid>
                    </item>
				                    <item>
                        <title>Switched from Splunk ES to Sentinel - 6 month cost and accuracy report</title>
                        <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/switched-from-splunk-es-to-sentinel-6-month-cost-and-accuracy-report-2/</link>
                        <pubDate>Sun, 23 Aug 2026 22:46:08 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I finally pulled the trigger six months ago and migrated our security operations from Splunk Enterprise Security over to Microsoft Sentinel. I was deep in the Splunk ecosystem ...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I finally pulled the trigger six months ago and migrated our security operations from Splunk Enterprise Security over to Microsoft Sentinel. I was deep in the Splunk ecosystem for years, but the cost trajectory was getting… concerning &#x1f605;. I wanted to share a real, granular breakdown of what the switch has meant for both our budget and, more importantly, our detection accuracy.

Let’s start with the cost side, because that was the initial driver. Our old Splunk ES licensing, based on daily ingest, was volatile and punishing during incident surges. With Sentinel, being on a pay-per-GB model for Log Analytics with committed tiers, our forecasting got way easier.

*   **Pre-migration (Splunk ES):** ~$8500/month average (highs of $12k during busy months).
*   **Post-migration (Sentinel):** We committed to 100 GB/day tier. Our actual average ingest is 110 GB, so we pay for the commit plus a small overage. Final average: ~$3200/month for the Sentinel workspace (cost of the Azure Monitor Log Analytics ingestion). The **Azure savings calculator** was surprisingly accurate for us.
*   **The Big Caveat - Data Source Integration:** The hidden "cost" was engineering time. Connecting some of our niche on-prem appliances wasn't as plug-and-play as Splunk's Universal Forwarder. We spent about 2 weeks building and tuning Data Collection Rules (DCRs) and using the Azure Monitor Agent (AMA). Here's a snippet of a DCR for a custom syslog source we had to craft:

```json
{
  "location": "eastus",
  "properties": {
    "dataSources": {
      "syslog": {
        "streams": ,
        "facilityNames": ,
        "logLevels": 
      }
    },
    "destinations": {
      "logAnalytics": 
    }
  }
}
```

Now, for the **accuracy and efficacy report**. This was my biggest worry—would we lose fidelity?

*   **Out-of-the-Box Analytics Rules:** Sentinel's built-in rules, especially for Microsoft 365 and Azure AD, are fantastic and update automatically. We saw **better true positive rates** for identity-based attacks straight away. The fusion rules for multi-stage incidents are clever.
*   **Custom Query Tuning:** KQL is a joy after SPL (controversial, I know!). Building custom detection rules felt more integrated. However, the learning curve for my team was real. We had to re-write about 30% of our proprietary correlation rules.
*   **The Gap - Network Logs:** Our legacy network IDS logs required more parsing logic in KQL to achieve the same detection coverage we had in Splunk. The raw performance of KQL is great, but you sometimes have to do more upfront schema definition.
*   **Overall Accuracy Metric:** We measured over the last quarter. Our validated true positive rate for high-severity incidents stayed statistically flat (within 2%). The **big win** was in mean time to triage (MTTT), which improved by about 15%, likely due to the tight integration with incident management and the playbook (Automation Rules) framework.

The integration with the rest of the Azure security stack (Defender for Endpoint, etc.) is a force multiplier you just don't get elsewhere. But it’s not all sunshine—the watchlist management and some of the UX workflows in the incident pane still feel a bit clunkier than Splunk's investigative views.

Has anyone else made a similar jump? I'm particularly curious about how you handled migrating complex, multi-source correlation rules or if you found certain data types (like verbose firewall logs) less optimal in the Sentinel/Law context.

Data nerd out.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-microsoft-sentinel/">Microsoft Sentinel Reviews</category>                        <dc:creator>Charlie99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-microsoft-sentinel/switched-from-splunk-es-to-sentinel-6-month-cost-and-accuracy-report-2/</guid>
                    </item>
				                    <item>
                        <title>Check out what I made: A PowerShell script to auto-close false positive incidents</title>
                        <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/check-out-what-i-made-a-powershell-script-to-auto-close-false-positive-incidents-2/</link>
                        <pubDate>Sun, 23 Aug 2026 00:05:49 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I’m pretty new to Sentinel and still learning, but I wanted to share something I put together for my team.

We kept getting flooded with false positive incidents, and...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I’m pretty new to Sentinel and still learning, but I wanted to share something I put together for my team.

We kept getting flooded with false positive incidents, and manual closing was eating up so much time. So I wrote a PowerShell script that automatically closes incidents based on our own rules (like specific low-severity alerts from certain rules). It’s been a huge help for us in keeping the queue clean. I’d love to hear how others handle this—do you have favorite methods or scripts for cutting down the noise?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-microsoft-sentinel/">Microsoft Sentinel Reviews</category>                        <dc:creator>clarag</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-microsoft-sentinel/check-out-what-i-made-a-powershell-script-to-auto-close-false-positive-incidents-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having massive gaps in SecurityEvent table for some Windows servers?</title>
                        <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/anyone-else-having-massive-gaps-in-securityevent-table-for-some-windows-servers-2/</link>
                        <pubDate>Thu, 20 Aug 2026 06:11:13 +0000</pubDate>
                        <description><![CDATA[Hey folks, has anyone else been pulling their hair out over random, massive gaps in the SecurityEvent table for specific Windows servers in Sentinel? &#x1f605;

I&#039;ve got a stable environment...]]></description>
                        <content:encoded><![CDATA[Hey folks, has anyone else been pulling their hair out over random, massive gaps in the SecurityEvent table for specific Windows servers in Sentinel? &#x1f605;

I've got a stable environment with about 50 servers all configured identically (I thought!) via the same Log Analytics agent (AMA) and SecurityEvent policy. For most, the logs flow in like a steady stream. But for three particular servers, the `SecurityEvent` table just... stops for hours at a time. No errors in the agent health table, no obvious network blips. The System and Application logs from those same servers come through without a hitch!

I've been down the rabbit hole checking the obvious:
*   Agent health (`Heartbeat` table) shows consistent pulses from the problem children.
*   Local Windows Event Log on the servers confirms the events *are* being generated (I checked!).
*   The workspace diagnostic settings look correct, and the `SecurityEvent` collection is enabled at the workspace level.

The only pattern I've spotted is that the gaps seem to coincide with periods of higher event volume (like during automated patching). Could it be a throttling issue on the Microsoft Monitoring Agent side? Or maybe a conflict with the local Windows Event Log size/rollover settings?

Here's the basic KQL I've been using to visualize the gaps for a specific problematic computer:

```kql
SecurityEvent
| where Computer == "ProblemServer01"
| where TimeGenerated &gt; ago(7d)
| summarize EventCount = count() by bin(TimeGenerated, 15m)
| render timechart
```

It just paints a damning picture of huge drops to zero.

Has anyone run into this and found a magic bullet? I'm about to dive deep into the agent's `C:WindowsAzureLogs` folders, but figured I'd check here first for any known Sentinel-specific gremlins.

-- Weave]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-microsoft-sentinel/">Microsoft Sentinel Reviews</category>                        <dc:creator>code_weaver_max</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-microsoft-sentinel/anyone-else-having-massive-gaps-in-securityevent-table-for-some-windows-servers-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone using Sentinel with Azure AD for identity monitoring? Real feedback</title>
                        <link>https://communities.stackinsight.net/community/cyber-microsoft-sentinel/anyone-using-sentinel-with-azure-ad-for-identity-monitoring-real-feedback-2/</link>
                        <pubDate>Wed, 19 Aug 2026 17:11:05 +0000</pubDate>
                        <description><![CDATA[Just finished another quarterly &quot;security stack review&quot; and, of course, we kicked the tires on Sentinel with Azure AD (or Entra ID, whatever they&#039;re calling it this week). The marketing prom...]]></description>
                        <content:encoded><![CDATA[Just finished another quarterly "security stack review" and, of course, we kicked the tires on Sentinel with Azure AD (or Entra ID, whatever they're calling it this week). The marketing promise is obvious: unified SIEM and identity protection, all within the cozy Azure ecosystem.

But the reality of stitching them together feels like a part-time job. The out-of-the-box "Azure AD" workbook and analytics rules are a decent starting point, but they mostly just repackage the same audit logs you'd see elsewhere. The real gaps show up when you try to build actual, actionable detection logic for identity-based attacks.

*   **Context switching is a killer.** Correlating a risky sign-in (from Identity Protection) with a specific anomalous process creation on an endpoint (from Defender) requires you to become a KQL wizard. It's doable, but the learning curve is steep and the time investment is real.
*   **Data normalization headaches.** Azure AD sign-in logs have their own schema. If you're bringing in logs from a non-Microsoft IAM solution, good luck building coherent rules without significant parsing effort.
*   **Cost creep is the silent alarm.** Ingesting all Azure AD audit and sign-in logs, especially for a large organization, can blow through your committed ingestion tier faster than you'd think. You quickly find yourself making tough calls on what to exclude, which defeats the purpose.

So, for those actually running this in production: are you seeing tangible ROI on the identity monitoring side, or is it just another dashboard to check? Have you built custom analytics rules that actually caught something the baselines missed? I'm particularly curious about detecting lateral movement patterns and privilege escalation that *aren't* just the standard Microsoft templates.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-microsoft-sentinel/">Microsoft Sentinel Reviews</category>                        <dc:creator>crm_hopper_2025_new</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-microsoft-sentinel/anyone-using-sentinel-with-azure-ad-for-identity-monitoring-real-feedback-2/</guid>
                    </item>
							        </channel>
        </rss>
		