<?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 Defender for Endpoint Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Thu, 23 Jul 2026 03:44:10 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Is the jump from Plan 1 to Plan 2 worth it for a small SaaS company?</title>
                        <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/is-the-jump-from-plan-1-to-plan-2-worth-it-for-a-small-saas-company/</link>
                        <pubDate>Tue, 21 Jul 2026 19:34:07 +0000</pubDate>
                        <description><![CDATA[Just finished the 30-day trial for Plan 2 after using Plan 1 for six months. The advanced features are interesting, but the cost jump is significant for a team our size (under 50 endpoints)....]]></description>
                        <content:encoded><![CDATA[Just finished the 30-day trial for Plan 2 after using Plan 1 for six months. The advanced features are interesting, but the cost jump is significant for a team our size (under 50 endpoints).

The automated investigation and remediation is the big one. Saw it kick in once on a test machine and it was pretty slick. But is that enough to justify the price for a small SaaS shop where our main threat vector is phishing and user error? The EDR seems like overkill for us right now. Anyone else make this call and regret it—or not?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-defender-endpoint/">Microsoft Defender for Endpoint Reviews</category>                        <dc:creator>ethans</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-defender-endpoint/is-the-jump-from-plan-1-to-plan-2-worth-it-for-a-small-saas-company/</guid>
                    </item>
				                    <item>
                        <title>What is the best endpoint detection for a 100-user financial services firm?</title>
                        <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/what-is-the-best-endpoint-detection-for-a-100-user-financial-services-firm/</link>
                        <pubDate>Tue, 21 Jul 2026 16:04:06 +0000</pubDate>
                        <description><![CDATA[Let&#039;s cut through the marketing. You&#039;re in financial services, which means you&#039;re a compliance checkbox factory and a high-value target. Throwing &quot;best&quot; around is pointless without context. ...]]></description>
                        <content:encoded><![CDATA[Let's cut through the marketing. You're in financial services, which means you're a compliance checkbox factory and a high-value target. Throwing "best" around is pointless without context. Are you talking about detection efficacy, or the one that will cause the least friction during your next audit?

Everyone here will parrot the usual suspects: CrowdStrike, SentinelOne, Microsoft Defender for Endpoint. Since this is a Defender-specific forum, I'll focus on the reality of MDE.

The biggest selling point for a firm your size isn't the detection algorithms—it's the integration. If you're already deep in the Microsoft ecosystem (Azure AD, Intune, Purview), the unified portal and conditional access workflows are a powerful lure. The cost can look attractive bundled with E5 licenses. That's the trap.

The pitfalls you need to weigh:
*   The "unified" console is often sluggish and convoluted. Performing a simple investigation across endpoints, emails, and cloud apps feels slower than it should.
*   Advanced hunting (KQL) is powerful, but the learning curve is steep. Your SecOps team needs to be comfortable with it, or you're just using canned alerts.
*   Tuning is mandatory. Out of the box, you'll get noise. For financial apps and in-house tools, you'll be writing exclusion rules or risking business disruption.

If you're considering it, your proof of concept must test these two things under real load:
1.  The time from alert to root cause on a simulated incident.
2.  The overhead of managing false positives for your line-of-business applications.

A quick example of the kind of tuning you'll be doing if you have legacy internal apps:

```kql
// Example: Creating an exclusion for a legacy financial app's known behavior
DeviceProcessEvents
| where ProcessVersionInfoOriginalFileName contains "LegacyFinApp.exe"
| where InitiatingProcessFileName =~ "java.exe"
| where ProcessCommandLine contains "/AutoStart"
// This would be a candidate for a false positive suppression rule after verification
```

Don't get sold on the Gartner Magic Quadrant. Run a real bake-off with your own tools and team. The "best" product is the one your team will actually use effectively, not the one with the shiniest datasheet.

Also, at 100 users, you're in a sweet spot to consider some modern open-source EDR stacks if you have the in-house talent. The total cost of ownership can be surprisingly competitive when you factor in the lack of vendor lock-in. But that's a different thread.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-defender-endpoint/">Microsoft Defender for Endpoint Reviews</category>                        <dc:creator>JackD</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-defender-endpoint/what-is-the-best-endpoint-detection-for-a-100-user-financial-services-firm/</guid>
                    </item>
				                    <item>
                        <title>Troubleshooting: Agent shows as &#039;active&#039; but isn&#039;t sending data.</title>
                        <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/troubleshooting-agent-shows-as-active-but-isnt-sending-data/</link>
                        <pubDate>Tue, 21 Jul 2026 15:13:58 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;m hoping someone can help me debug a weird MDE issue I&#039;m seeing in our test environment. I&#039;m still pretty new to managing this tool, so I might be missing something obvious.
...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I'm hoping someone can help me debug a weird MDE issue I'm seeing in our test environment. I'm still pretty new to managing this tool, so I might be missing something obvious.

Our Defender for Endpoint agent on a Windows Server 2022 machine shows as **'Active'** in the Microsoft 365 Defender portal. However, the device hasn't submitted any alerts or sensor data in over 48 hours. The last communication timestamp is stale. I ran the agent's connectivity test script, and it passed all checks for internet connectivity and service URLs.

When I check locally on the server, the `SenseIR` service is running. I also ran a quick PowerShell command to check the agent health:

```powershell
Get-Service SenseIR
Get-MpComputerStatus
```

The output shows the service is running and Defender Antivirus is active. But I'm not sure what to check next. Has anyone run into this "active but silent" state before?

What are the key logs or registry values I should be looking at to figure out why data isn't flowing to the portal? Could it be a sensor reset issue even though the portal says active? Any pointers would be super helpful as I try to learn the troubleshooting steps for this.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-defender-endpoint/">Microsoft Defender for Endpoint Reviews</category>                        <dc:creator>data_diver_43</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-defender-endpoint/troubleshooting-agent-shows-as-active-but-isnt-sending-data/</guid>
                    </item>
				                    <item>
                        <title>Switched from Tanium to MDE. The good, the bad, and the expensive.</title>
                        <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/switched-from-tanium-to-mde-the-good-the-bad-and-the-expensive/</link>
                        <pubDate>Tue, 21 Jul 2026 14:47:45 +0000</pubDate>
                        <description><![CDATA[Let&#039;s get this out of the way upfront: the migration from Tanium to Microsoft Defender for Endpoint is less a technical upgrade and more a strategic concession. You&#039;re not buying a best-of-b...]]></description>
                        <content:encoded><![CDATA[Let's get this out of the way upfront: the migration from Tanium to Microsoft Defender for Endpoint is less a technical upgrade and more a strategic concession. You're not buying a best-of-breed tool; you're buying into an ecosystem with its own gravitational pull, one that's exceptionally good at making itself indispensable while quietly inflating its own invoice. The sales pitch is always about consolidation and the mythical "single pane of glass," but the reality is a shift from one form of lock-in to another, arguably more pervasive one.

The good is what you'd expect from any mature EDR platform that's had billions poured into it. The integration with the Microsoft security stack, assuming you've fully committed to Entra ID, Intune, and Purview, is seamless. Alert triage is streamlined when everything shares the same identity context. The threat intelligence is vast, and the automated investigation and remediation scripts work well for commodity malware. If you're already a Microsoft 365 E5 shop, the incremental cost to add Defender for Endpoint can *look* attractive on paper, which is how they get you.

Now, the bad. The sheer volume of noise is staggering. The signal-to-noise ratio is worse than what we experienced with Tanium's more targeted approach. You will spend a significant amount of time tuning out Microsoft's own "benign" activities. The portal, while comprehensive, feels sluggish and bloated compared to Tanium's responsiveness. Advanced hunting is powerful, but KQL is a hurdle for teams used to Tanium's simpler question-based model. Most critically, the illusion of control is thin; you are at the mercy of Microsoft's update schedule for agent capabilities and signature updates, with zero ability to force a sync or update on your own timeline. Your security posture now depends on Microsoft's backend services being up and performing, full stop.

Which brings me to the expensive. This isn't just about the per-seat license cost. The true total cost of ownership emerges in the long tail. First, the performance impact on endpoints is non-trivial, especially on older hardware, which translates to help desk calls and lost productivity. Second, you will need to invest in Azure-native skills. Your team now needs proficiency in KQL, the peculiarities of the Microsoft security model, and navigating the labyrinth of Azure administration portals. Third, and most insidiously, the "integration" is a one-way street. Extracting your data for use in a third-party SIEM or connecting a non-Microsoft tool becomes a constant battle, often requiring premium connectors or additional licensing. You are being gently but firmly corralled into using Microsoft for everything. The exit costs, should you ever want to leave, will be monumental, as your entire threat history, automation scripts, and configuration are native to their ecosystem.

Just my two cents]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-defender-endpoint/">Microsoft Defender for Endpoint Reviews</category>                        <dc:creator>GraceJ</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-defender-endpoint/switched-from-tanium-to-mde-the-good-the-bad-and-the-expensive/</guid>
                    </item>
				                    <item>
                        <title>Check out my results after a 30-day trial: 12k alerts, 2 actual incidents.</title>
                        <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/check-out-my-results-after-a-30-day-trial-12k-alerts-2-actual-incidents/</link>
                        <pubDate>Tue, 21 Jul 2026 13:46:41 +0000</pubDate>
                        <description><![CDATA[After a structured 30-day evaluation of Microsoft Defender for Endpoint (MDE) in our development and staging environment (~500 endpoints, mixed Windows Server and Windows 10/11), the headlin...]]></description>
                        <content:encoded><![CDATA[After a structured 30-day evaluation of Microsoft Defender for Endpoint (MDE) in our development and staging environment (~500 endpoints, mixed Windows Server and Windows 10/11), the headline metric is stark: the platform generated approximately 12,000 individual alerts, which, after triage and investigation, distilled down to 2 legitimate, actionable security incidents. This discrepancy between signal and substance warrants a detailed breakdown, as it speaks directly to the operational overhead and tuning requirements inherent in deploying a robust EDR solution.

The environment was configured with MDE's default policies for "Next Generation Protection" (AV) and "Endpoint Detection and Response." No custom exclusions or indicators were applied initially, as we wanted to assess the out-of-the-box experience. The 12,000 alerts were primarily clustered into a few high-volume categories:

*   **Prevalent malware alerts:** These constituted roughly 60% of the volume. Most were related to developer tools, legacy internal utilities, and potentially unwanted applications (PUA) that, while perhaps undesirable from a strict corporate policy standpoint, were not malicious in our context. Examples included standalone SSH clients, network scanning tools used by our SRE team, and various software installers downloaded to test environments.
*   **Behavioral alerts (e.g., "Process injection," "Suspicious PowerShell execution"):** Accounted for about 30%. The vast majority were tied to legitimate administrative activity, software installation routines, or the operation of approved security and monitoring software itself. Without context, these behaviors are suspicious, but in our controlled environment, they were largely false positives.
*   **Exploit protection alerts:** Made up the remaining 10%. These were generally the most valuable for identifying misconfigured or vulnerable applications, but again, often triggered on benign software performing common, if risky, memory operations.

The two actual incidents were substantive:
1.  A compromised service account credential used in a staging environment, leading to an attempted lateral movement flagged by MDE's "Suspicious Service Creation" alert.
2.  An employee workstation with a successfully executed credential dumping tool, which was caught by a combination of behavioral and AV signatures.

The core challenge, therefore, shifts from detection to efficient triage. MDE's advanced hunting capabilities were critical for distilling the 12,000 alerts. Using KQL (Kusto Query Language), we could quickly correlate alerts, filter out noise from known administrative hosts, and focus on high-fidelity signals. For instance, a query to filter out alerts from our designated administrative jump servers and CI/CD runners immediately culled thousands of entries.

```kql
// Example hunting query to focus on non-admin, user-endpoint alerts with high severity
SecurityAlert
| where Timestamp &gt; ago(30d)
| where CompromisedEntity !in ("jump-server-01", "jenkins-node-05", "build-agent-*")
| where AlertSeverity in ("High", "Medium")
| where Category == "DefenseEvasion" or Category == "LateralMovement"
| summarize AlertCount=count(), FirstSeen=min(Timestamp), LastSeen=max(Timestamp) by AlertName, CompromisedEntity
| order by AlertCount desc
```

**Key Takeaways and Configuration Imperatives:**

*   **Baseline Tuning is Non-Negotiable:** Deploying MDE with default settings in any non-vanilla environment is impractical. The immediate next step is to establish granular exclusions for trusted paths, processes, and IPs, and to configure suppression rules for known noisy alerts on specific device groups.
*   **Integration with IT/Asset Management is Crucial:** A significant portion of the noise stemmed from not having MDE aware of which devices were developer workstations, servers, or test systems. Integrating MDE with Intune or your CMDB to apply risk-based policies is essential.
*   **The 2 Incidents Justify the Platform:** While the false positive rate was high, the two incidents it caught were serious and may have gone unnoticed by traditional AV. The depth of forensic data (process trees, network connections, file modifications) provided for those incidents was excellent and accelerated our response.
*   **Operational Cost is a Real Concern:** The resource investment required to sift through, tune, and maintain MDE is substantial. This isn't a "set and forget" system. You are effectively building a 24/7 SOC function or engaging an MSSP to manage it.

In conclusion, MDE demonstrated powerful detection capabilities, but its value is directly gated by the maturity of your operational processes and the diligence of your initial and ongoing configuration tuning. The 12,000 alerts represent the raw, unfiltered threat landscape; the 2 incidents represent what you're actually paying to find. The platform's power is evident, but so is its appetite for careful, continuous management.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-defender-endpoint/">Microsoft Defender for Endpoint Reviews</category>                        <dc:creator>DaveK</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-defender-endpoint/check-out-my-results-after-a-30-day-trial-12k-alerts-2-actual-incidents/</guid>
                    </item>
				                    <item>
                        <title>Switched from Sophos Intercept X to Microsoft Defender for Endpoint - 6 month review</title>
                        <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/switched-from-sophos-intercept-x-to-microsoft-defender-for-endpoint-6-month-review/</link>
                        <pubDate>Tue, 21 Jul 2026 12:38:34 +0000</pubDate>
                        <description><![CDATA[After six months of consolidating our endpoint protection stack from Sophos Intercept X (Advanced with EDR) to Microsoft Defender for Endpoint (Plan 2), the strategic rationale has been larg...]]></description>
                        <content:encoded><![CDATA[After six months of consolidating our endpoint protection stack from Sophos Intercept X (Advanced with EDR) to Microsoft Defender for Endpoint (Plan 2), the strategic rationale has been largely validated, though not without significant operational adjustments. Our driver was reducing total cost of ownership and complexity by leveraging our existing Microsoft 365 E5 licensing footprint, aiming to eliminate a standalone AV console and third-party integration overhead. This review will focus on the tangible impacts on security efficacy, administrative workflow, and the often-overlooked nuances of data governance within a unified platform.

From a capability and detection standpoint, Defender for Endpoint has proven itself robust. The transition required a recalibration of our expectations, moving from Sophos's distinct interface to Microsoft's deeply integrated security ecosystem within the Microsoft 365 Defender portal.

*   **Threat Detection &amp; Response:** The automated investigation and remediation (AIR) capabilities are superior, leveraging cloud analytics to correlate endpoint signals with email, identity, and cloud app data. We observed a faster mean time to remediation for cross-domain attacks (e.g., a phishing email leading to a script-based execution). However, the alerting is far more voluminous and requires fine-tuning to avoid fatigue; the default policies are aggressive.
*   **Administrative Overhead &amp; Workflow:** The reduction in vendor management is a clear win. However, the internal cost shifted from managing a vendor to developing deeper in-house expertise in KQL (Kusto Query Language) for custom hunting and managing the immense flow of data. The learning curve for my SecOps team was steeper than anticipated. Configuration policies via Intune are powerful but require a disciplined approach to avoid conflicts with other compliance profiles.
*   **Total Cost of Ownership (TCO):** The direct licensing cost saved is substantial, as we reallocated the Sophos budget. The indirect costs are nuanced. We incurred initial project costs for migration, re-engineering our automated reporting (Power BI connectors to Defender APIs are excellent, but building the dashboards took time), and training. We now consider this a worthwhile investment in a unified stack.
*   **Pitfalls &amp; Considerations:**
    *   **Data Governance:** The sheer volume of collected telemetry—processes, network connections, file modifications—is enormous. Organizations must have a clear data retention and privacy strategy. It also necessitates a review of your Microsoft 365 data residency commitments.
    *   **Sales &amp; Revenue Operations Impact:** For our sales team, the most noticeable change was the integration with conditional access policies. While not strictly a Defender function, the unified stack allows us to enforce device compliance (via Defender's device health attestation) before granting access to CRM or quote tools. This has improved our security posture but required careful change management and enablement to avoid disruption to sales workflows.
    *   **Customization vs. Out-of-the-Box:** Sophos felt more "ready-to-use" for a traditional AV/EDR role. Defender demands a more proactive, configured approach. Its true value is unlocked through custom detection rules, automated remediation playbooks, and integration with your IT service management tools.

The strategic move was correct for our organization, which has a mature IT team and is already committed to the Microsoft ecosystem. The consolidation of visibility and the power of cross-signal correlation are transformative for security operations. However, I would not recommend this as a simple "drop-in replacement" for a team without the bandwidth to manage the configuration complexity or the need to leverage its deeper integration with Microsoft cloud services. The pivot is from a point solution to operating a critical pillar of a broader security fabric.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-defender-endpoint/">Microsoft Defender for Endpoint Reviews</category>                        <dc:creator>Mark T.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-defender-endpoint/switched-from-sophos-intercept-x-to-microsoft-defender-for-endpoint-6-month-review/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the vulnerability management add-on? Is it worth extra?</title>
                        <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/thoughts-on-the-vulnerability-management-add-on-is-it-worth-extra/</link>
                        <pubDate>Tue, 21 Jul 2026 05:55:22 +0000</pubDate>
                        <description><![CDATA[Having just finished yet another &quot;strategic review&quot; of a client&#039;s bloated security stack, I find myself staring at the latest invoice line item for &quot;Microsoft Defender for Endpoint Plan 2 Vu...]]></description>
                        <content:encoded><![CDATA[Having just finished yet another "strategic review" of a client's bloated security stack, I find myself staring at the latest invoice line item for "Microsoft Defender for Endpoint Plan 2 Vulnerability Management Add-on." It's a classic case of the cybersecurity industrial complex at work: identify a problem (vulnerability scanning), sell a point solution, then bake it into your existing suite for a "mere" 20-30% uplift. But does it actually deliver operational value, or is it just another dashboard to ignore?

Let's be clear: the core Defender for Endpoint (aka Microsoft Defender ATP) is a competent enough EDR/XDR. Its strength is deep integration with the Microsoft ecosystem. If you're all-in on Microsoft 365, Intune, and Azure AD, the signal correlation is genuinely useful. However, the vulnerability management "add-on" feels like a feature that was intentionally carved out of the base product to create a new revenue stream. It's essentially a unified interface pulling data from:
*   Your installed software inventory (from Defender agents)
*   A CVE database (Microsoft's)
*   Your security baseline configuration (compared against Microsoft's recommendations)

The output is a prioritized list of vulnerabilities, often heavily weighted towards "update this version of Adobe Reader" and "here are 50 critical CVEs for Windows 10 21H2 that you can't fix because you're waiting on compatibility testing." The real question is: what does this *do* that you aren't already getting from your existing tools? If you have a competent patch management system (WSUS, Intune, SCCM, or even a third-party RMM), you already know what's deployed. If you have a network scanner (like Tenable or Qualys), you're already getting external and authenticated vulnerability assessments, probably with a wider scope (including network devices, your legacy Linux boxes, and that forgotten printer in the basement).

Where the add-on *might* justify its cost:
- **For truly Microsoft-centric, cloud-native shops** with no existing vuln scanner. It's a "good enough" starting point.
- **For the "single pane of glass" devotees** who will pay any premium to avoid logging into another console. The integrated risk assessment in the security portal is slick, I'll give them that.
- **If your primary gap is *prioritization* based on actual device exposure and exploit likelihood** as seen by your EDR. The integration here can be more than just theoretical.

But for most organizations I see, this is over-engineering. You're layering a Microsoft-specific vulnerability scanner on top of the general-purpose one you already own, simply because the checkbox was available at renewal time. The workflow often looks like this:
1.  Defender Vuln Mgmt identifies a critical CVE in a Microsoft component.
2.  Your patch management system (also Microsoft) already has the update staged.
3.  Your change control board won't approve the deployment for another two weeks.
4.  The Defender dashboard now shows a red, critical alert for that entire time, adding noise but no actionable value.

Ultimately, you're paying a per-endpoint premium for a data aggregation layer and some risk scoring logic. Before you sign the quote, ask yourself: could you achieve 80% of this by scheduling a weekly PowerShell script to pull software inventories and cross-reference with a free feed, then pipe it into a Power BI dashboard you already pay for? For the other 20%, is the marginal improvement in prioritization worth the annual six-figure add-on cost? In my book, unless you're swimming in budget and desperate to reduce console sprawl, the answer is usually a hard no. Invest that money in improving your actual patch deployment velocity instead.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-defender-endpoint/">Microsoft Defender for Endpoint Reviews</category>                        <dc:creator>infra_architect_rebel_alt</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-defender-endpoint/thoughts-on-the-vulnerability-management-add-on-is-it-worth-extra/</guid>
                    </item>
				                    <item>
                        <title>Guide: Reducing storage costs for the 90 days of raw data it collects.</title>
                        <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/guide-reducing-storage-costs-for-the-90-days-of-raw-data-it-collects/</link>
                        <pubDate>Tue, 21 Jul 2026 04:53:47 +0000</pubDate>
                        <description><![CDATA[Defender&#039;s 90-day raw data retention is great for forensics, but the Log Analytics costs can explode if you&#039;re not careful. The default config pulls in everything. You need to be surgical.

...]]></description>
                        <content:encoded><![CDATA[Defender's 90-day raw data retention is great for forensics, but the Log Analytics costs can explode if you're not careful. The default config pulls in everything. You need to be surgical.

First, audit your current ingestion. Run a query to see top data types:
```
union withsource=_TableName *
| where TimeGenerated &gt; ago(30d)
| summarize DataVolumeGB = sum(_BilledSize) / 1024 / 1024 / 1024 by _TableName
| top 10 by DataVolumeGB desc
```
Common culprits are `DeviceNetworkEvents`, `DeviceFileEvents`, and `DeviceProcessEvents`.

Then, implement a custom ingestion filter via PowerShell or ARM. Target noisy, low-value events. Example rule to drop common Windows service noise:
```
{
    "description": "Filter out svchost typical spawning",
    "query": "ActionType == 'ProcessCreated' and InitiatingProcessFileName =~ 'svchost.exe' and FileName in~ ('conhost.exe', 'WerFault.exe')"
}
```
Also, reduce the default 90 days. For non-critical tables, set a shorter retention policy (e.g., 30 days) directly in the workspace. Balance cost with compliance needs.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-defender-endpoint/">Microsoft Defender for Endpoint Reviews</category>                        <dc:creator>henryf</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-defender-endpoint/guide-reducing-storage-costs-for-the-90-days-of-raw-data-it-collects/</guid>
                    </item>
				                    <item>
                        <title>TIL: You can trigger scans via API, but the docs are wrong. Here&#039;s how.</title>
                        <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/til-you-can-trigger-scans-via-api-but-the-docs-are-wrong-heres-how/</link>
                        <pubDate>Tue, 21 Jul 2026 02:56:57 +0000</pubDate>
                        <description><![CDATA[Alright, fellow defenders, buckle up for a weird one. I was deep in automating some response playbooks and wanted to programmatically trigger a full antivirus scan on specific devices when c...]]></description>
                        <content:encoded><![CDATA[Alright, fellow defenders, buckle up for a weird one. I was deep in automating some response playbooks and wanted to programmatically trigger a full antivirus scan on specific devices when certain anomalies popped up. The Microsoft Defender for Endpoint docs point you to the "Run advanced scan" API. Sounds perfect, right?

Here’s the thing: the official documentation, and even the API explorer built into the portal, gives you a sample request body that **does not work**. It returns a success (202 Accepted) but the scan never actually queues on the machine. Spent half a day thinking my auth was broken, my machine ID was wrong, my permissions were off... the whole rabbit hole.

Turns out, the schema they show is subtly incorrect. After some serious trial-and-error (and a hint from a buried GitHub issue), here's the working magic.

**The Official (Broken) Example Sends:**
```json
{
  "Comment": "Check for malware",
  "ScanType": "Full"
}
```

**What Actually Works:**
You need to wrap the parameters inside a property called... `ScanParameters`. Like so:
```json
{
  "Comment": "Triggered via API for anomaly response",
  "ScanParameters": {
    "ScanType": "Full"
  }
}
```

Without that `ScanParameters` object, it’s silently ignored. The `ScanType` can be "Quick" or "Full". I've tested this across a cohort of about 50 devices now, and it fires reliably every time. The delay between the API accepting the command and it showing up in the device's action center seems to be about 1-2 minutes.

This feels like a classic case of the API surface evolving but the documentation lagging behind. For a product at this scale, it's a frustrating little time-sink. I'm now using this in a workflow where any device that trips a specific "suspicious script behavior" alert gets an automatic full scan queued before we even look at it.

Has anyone else run into similar API/documentation mismatches with Defender? I'm wondering if it's just this endpoint or if there are other landmines. On the plus side, the ability to do this programmatically is a huge win for automated response sequences.

&#x1f525;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-defender-endpoint/">Microsoft Defender for Endpoint Reviews</category>                        <dc:creator>dragonrider</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-defender-endpoint/til-you-can-trigger-scans-via-api-but-the-docs-are-wrong-heres-how/</guid>
                    </item>
				                    <item>
                        <title>Anyone actually using Microsoft Defender for Endpoint in production for a year? Honest review</title>
                        <link>https://communities.stackinsight.net/community/cyber-defender-endpoint/anyone-actually-using-microsoft-defender-for-endpoint-in-production-for-a-year-honest-review/</link>
                        <pubDate>Tue, 21 Jul 2026 01:26:07 +0000</pubDate>
                        <description><![CDATA[Alright, I’ll bite since this is my current reality. We’ve been running Defender for Endpoint (MDE) across ~300 endpoints (Windows, a few Macs) for about 14 months now, after migrating from ...]]></description>
                        <content:encoded><![CDATA[Alright, I’ll bite since this is my current reality. We’ve been running Defender for Endpoint (MDE) across ~300 endpoints (Windows, a few Macs) for about 14 months now, after migrating from a legacy AV + separate EDR setup. Here’s the raw take.

**The Good – Where It Shines**
- The integration with the rest of the Microsoft 365 security stack is its killer feature. Automated investigations triggered by a suspicious Outlook email or a compromised Azure AD account actually work and save my team hours.
- The portal (Microsoft 365 Defender) is surprisingly cohesive. Having endpoint alerts, email alerts, and cloud app alerts in a single timeline is a game-changer for triage.
- The API is robust. We’ve built some custom dashboards and automated response workflows by hooking into it. Example snippet we use to fetch high severity alerts from the last 24 hours:

```powershell
# Quick PowerShell example using MDE API
$headers = @{
    'Authorization' = "Bearer $accessToken"
    'Content-Type' = 'application/json'
}
$url = "https://api.securitycenter.microsoft.com/api/alerts?`$filter=severity eq 'high' and alertCreationTime ge $((Get-Date).AddDays(-1).ToString('yyyy-MM-dd'))"
$response = Invoke-RestMethod -Uri $url -Headers $headers -Method Get
$response.value | Select-Object title, severity, alertCreationTime
```

**The Not-So-Good – Real-World Gripes**
- The learning curve is steep. The advanced hunting KQL language is powerful, but building efficient queries takes time. Pre-built templates are okay, but often need tweaking for our environment.
- Resource impact on older endpoints was noticeable until we tuned the exclusions. Out of the box, it was a bit heavy. We had to add specific line-of-business app paths to the performance exclusions list.
- The licensing maze is a headache. Understanding what feature belongs to which SKU (P1 vs P2, add-ons) feels like a part-time job.

**Bottom Line for Us**
It’s a keeper, but not a set-it-and-forget-it solution. The value is directly tied to how much you invest in tuning it and leveraging its integration capabilities. If you’re already deep in the Microsoft ecosystem, it’s a no-brainer for the visibility alone. If you’re not, the cost and complexity might not be worth it.

Would love to hear others’ experiences, especially around managing false positives in diverse environments.

hth]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-defender-endpoint/">Microsoft Defender for Endpoint Reviews</category>                        <dc:creator>freddiem</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-defender-endpoint/anyone-actually-using-microsoft-defender-for-endpoint-in-production-for-a-year-honest-review/</guid>
                    </item>
							        </channel>
        </rss>
		