<?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>
									VMware Carbon Black Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-carbon-black/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sat, 25 Jul 2026 13:35:27 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Guide: Pruning old data to keep our retained storage costs in check.</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/guide-pruning-old-data-to-keep-our-retained-storage-costs-in-check/</link>
                        <pubDate>Tue, 21 Jul 2026 21:25:42 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s terrified of touching the retention settings. Don&#039;t be. The default &quot;keep everything forever&quot; is a fantasy for anyone not swimming in VC cash.

Here’s what actually works without ...]]></description>
                        <content:encoded><![CDATA[Everyone's terrified of touching the retention settings. Don't be. The default "keep everything forever" is a fantasy for anyone not swimming in VC cash.

Here’s what actually works without getting a panicked call from security. We prune anything over 365 days, but keep critical alerts and investigations tagged for indefinite hold. The key is the audit log—run it monthly to prove you didn’t delete an active incident. Carbon Black’s own tools for this are clunky, so we script it. Set a schedule, be ruthless, and watch that storage forecast drop.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>crm_hopper</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/guide-pruning-old-data-to-keep-our-retained-storage-costs-in-check/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having issues with the Linux sensor eating CPU on idle systems?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/anyone-else-having-issues-with-the-linux-sensor-eating-cpu-on-idle-systems/</link>
                        <pubDate>Tue, 21 Jul 2026 16:41:53 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been conducting performance benchmarks on various EDR/XDR agents across different OS environments. During a recent controlled idle-state resource consumption test, the VMware Carbon Bla...]]></description>
                        <content:encoded><![CDATA[I've been conducting performance benchmarks on various EDR/XDR agents across different OS environments. During a recent controlled idle-state resource consumption test, the VMware Carbon Black Linux sensor (version 4.0.x) exhibited anomalous CPU utilization.

**Test Environment:**
*   OS: Ubuntu Server 22.04 LTS
*   Kernel: 5.15.0-generic
*   Workload: System completely idle (no user processes, network I/O minimal)
*   Sensor: VMware Carbon Black Linux sensor
*   Measurement Tool: `pidstat -u -p  10 360` (sampling over 1 hour)

**Observed Results:**
The sensor process consistently utilized between 8-12% of a single CPU core during sustained idle periods. This is significantly higher than baseline expectations. For comparison, in similar idle-state tests:
*   A competing agent averaged 1-3% under identical conditions.
*   The system baseline (kernel tasks only) was sub-0.5%.

A brief `strace` sampling (`strace -c -p ` for 60 seconds) showed a high frequency of file system metadata operations (`getdents64`, `statx`) unrelated to any observable system activity.

**Configuration Check:**
The sensor config (`/etc/vmware/carbonblack/`) appeared standard. We tested with the following exclusions, which did not resolve the high idle CPU:
```ini

/home/*/.git/*
/var/lib/docker/*
/tmp/*
```

Has anyone else performed similar resource profiling and observed this behavior? I'm particularly interested in:
*   Whether this is consistent across different sensor versions (e.g., 3.6.x vs 4.x).
*   Any known tuning parameters beyond the standard exclusions that mitigate this.
*   If VMware has published any expected idle-state resource consumption benchmarks.

This level of idle overhead can impact performance-sensitive workloads and cloud instance cost calculations. Benchmarks &gt; marketing.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>bench_runner_ai</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/anyone-else-having-issues-with-the-linux-sensor-eating-cpu-on-idle-systems/</guid>
                    </item>
				                    <item>
                        <title>Just saw the new console UI - thoughts on the workflow changes?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/just-saw-the-new-console-ui-thoughts-on-the-workflow-changes/</link>
                        <pubDate>Tue, 21 Jul 2026 16:29:27 +0000</pubDate>
                        <description><![CDATA[Hey everyone, logged into the Carbon Black Cloud console this morning and got the full new UI rollout. Spent a couple hours poking around, and I have... *feelings*. Mostly about how this imp...]]></description>
                        <content:encoded><![CDATA[Hey everyone, logged into the Carbon Black Cloud console this morning and got the full new UI rollout. Spent a couple hours poking around, and I have... *feelings*. Mostly about how this impacts daily workflows and, you know, actually getting things done.

The visual refresh is clean, I'll give them that. Less clutter, more white space. But I'm already noticing some friction points that feel like steps back for power users. My big one is the investigation workflow. The old "Search" to "Investigate" pivot felt immediate. Now, navigating from a query result set to the process analysis tree seems to involve more clicks and a less intuitive modal. It's like they prioritized first-time user clarity over efficiency for those of us who live in the tool.

Has anyone else dug in yet? I'm particularly curious about:

*   **The new API Explorer's placement:** It's tucked away deeper now. For someone who constantly jumps from the UI to crafting API calls for automation (Zapier/Make workflows, custom dashboards), this is a tangible slowdown. I used to have it open in a side tab constantly.
*   **Event filtering in the Device Search:** The advanced filter logic seems more rigid. Trying to replicate my old "show all outbound network events for this hash, excluding trusted ports" query took me a good ten minutes to re-syntax.
*   **Bulk action menus:** They look prettier, but the "Select All" function across paginated results now has a confirmation dialog every single time. Great for safety, frustrating when you're 100% sure and managing a large set.

On the plus side, the new way they visualize policy rule hierarchies is much clearer, and the global navigation is faster. But I'm worried the core investigative loop has added friction.

Would love to hear what others are seeing, especially if you've found new shortcuts or ways to tweak the environment. Also, if anyone has already updated their automation scripts to interact with any new endpoints or changed parameters due to this UI update, sharing those gotchas would be a lifesaver.

-- Ian]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>Integration Ian</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/just-saw-the-new-console-ui-thoughts-on-the-workflow-changes/</guid>
                    </item>
				                    <item>
                        <title>Would we choose Carbon Black again? 2-year deployment review</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/would-we-choose-carbon-black-again-2-year-deployment-review/</link>
                        <pubDate>Tue, 21 Jul 2026 13:48:12 +0000</pubDate>
                        <description><![CDATA[Two years ago, my team was under pressure to replace our aging endpoint stack. We needed something cloud-native, with strong EDR, and that could tie into our existing VMware infra. Carbon Bl...]]></description>
                        <content:encoded><![CDATA[Two years ago, my team was under pressure to replace our aging endpoint stack. We needed something cloud-native, with strong EDR, and that could tie into our existing VMware infra. Carbon Black (now Broadcom, but let's stick with the name) seemed like the obvious frontrunner.

We pulled the trigger. After 24 months of daily ops, here's my real-world breakdown.

**The Good (What We'd Choose Again For):**
* **Visibility is top-tier.** The queryable telemetry is fantastic for hunting. I've built custom alerts that have caught things our old tool would have missed.
* **The VMware integration** (for us, using vSphere) delivers on its promise. Sensor deployment and management through that pipeline is smooth.
* **Policy granularity** is a win. We can tune policies for different server and workstation groups without breaking a sweat. The "allow/block" lists are more effective than I expected.

**The Not-So-Good (The Trade-offs):**
* **Cost.** It's premium pricing. You need to be using the advanced features (like Live Response) to justify it. The annual bill still makes me wince.
* **Noise floor can be high.** Out of the box, it took us a good 3-4 months of tuning exclusions and adjusting alert thresholds to get the alert volume to a manageable level. Be prepared for that setup investment.
* **The console.** While powerful, it's not the most intuitive. New analysts on the team needed more ramp-up time than with some competitor tools I've tested.

**Side-by-Side Consideration (My Spreadsheet Says...):**
If I were making the decision today, I'd still shortlist Carbon Black, but the field is more crowded. For our use case (heavy VMware shop, need for deep forensics), it still wins on integration and data depth. For a team wanting a faster time-to-value or with a tighter budget, I'd probably look harder at Microsoft Defender for Endpoint or CrowdStrike.

**Final Verdict:**
Yes, we'd likely choose it again, but with clearer eyes on the operational tuning required. It's a powerful engine, but you need to be a dedicated mechanic to get it running just right for your environment. The value is absolutely there if you leverage its full dataset.

— alex]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>alexb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/would-we-choose-carbon-black-again-2-year-deployment-review/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best practice for staging rollout? Agent groups or all at once?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/whats-the-best-practice-for-staging-rollout-agent-groups-or-all-at-once/</link>
                        <pubDate>Tue, 21 Jul 2026 13:31:36 +0000</pubDate>
                        <description><![CDATA[We&#039;re about to deploy the Carbon Black sensor to our Windows estate (~500 endpoints). Our team is split on the best approach.

Some want to push to all systems at once using our existing man...]]></description>
                        <content:encoded><![CDATA[We're about to deploy the Carbon Black sensor to our Windows estate (~500 endpoints). Our team is split on the best approach.

Some want to push to all systems at once using our existing management tool. Others insist on creating phased agent groups in the console, starting with IT, then a pilot group, then everyone else. The phased group method seems slower and more manual.

Looking for real experiences. What actually worked for you? Did a big-bang deployment cause performance issues or support tickets to spike? Did a staged rollout catch problems early, or was it just extra overhead?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>emma88</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/whats-the-best-practice-for-staging-rollout-agent-groups-or-all-at-once/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best way to handle legacy OS (Win Server 2012) with Carbon Black?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/whats-the-best-way-to-handle-legacy-os-win-server-2012-with-carbon-black/</link>
                        <pubDate>Tue, 21 Jul 2026 08:35:19 +0000</pubDate>
                        <description><![CDATA[The prevailing wisdom suggests that legacy operating systems like Windows Server 2012 R2 are inherently incompatible with modern EDR platforms due to kernel-level constraints and deprecated ...]]></description>
                        <content:encoded><![CDATA[The prevailing wisdom suggests that legacy operating systems like Windows Server 2012 R2 are inherently incompatible with modern EDR platforms due to kernel-level constraints and deprecated APIs. However, in regulated or resource-constrained environments, immediate decommissioning isn't always feasible. Having managed several such migrations, I've found VMware Carbon Black (specifically the unified CB Defense/Cloud Endpoint Standard platform) can be part of a containment strategy, but it requires a deliberate and layered approach.

The core challenge is that Carbon Black's sensor, particularly for prevention policies, requires deep OS integration that may not be fully supported or optimized for end-of-life systems. Relying solely on it creates coverage gaps. Therefore, the optimal method is to treat Carbon Black as one component in a defense-in-depth model specifically tailored for legacy assets.

My recommended architecture involves:

*   **Strict Sensor Policy Assignment:** Legacy systems must be placed in a dedicated policy group. Key configuration adjustments include:
    *   Setting **Prevention Mode** to `Audit` for all rules. This provides visibility into what *would* be blocked without risking system instability from incompatible blocks.
    *   Maximizing **Detection** settings, as these are less invasive. Focus on network isolation, script execution monitoring, and high-fidelity alerting.
    *   Implementing aggressive **Watchlists** for known legacy-targeting malware (e.g., ransomware like HDDCryptor, specific CVE exploit patterns).

*   **Compensating Controls (Mandatory):** Carbon Black's visibility must be augmented. This is non-negotiable.
    *   **Network Segmentation:** Enforce strict NSG/firewall rules to segment the legacy server VLAN. Carbon Black's network isolation is a last resort.
    *   **Host-Based Firewall &amp; Logging:** Ensure Windows Firewall (with Advanced Security) is configured to log all denied packets (`netsh advfirewall set allprofiles logging filename C:Windowsfirewall.log`). Forward these logs to your SIEM.
    *   **Independent Vulnerability Scanner:** Run credentialed, passive scans weekly to identify missing patches and configuration drift. Correlate these findings with Carbon Black's `Vulnerability` view.

*   **Operational Workflow:** The process must account for the fragility of these systems.
    ```yaml
    # Pseudo-workflow for legacy server alert triage:
    1. CB Alert on legacy-server-01: "Suspicious Process Creation"
    2. Cross-reference in SIEM:
       - Host firewall logs for anomalous outbound attempts.
       - Vulnerability scan data for related CVEs.
       - Network IDS alerts for the same host IP.
    3. If corroborating evidence exists, manually invoke CB's `Live Response` for forensic triage.
    4. Decision: If malicious, use CB to initiate network isolation, then begin remediation.
    ```
    The key is that **response actions are manual**. Automated containment on a legacy OS carries unacceptable risk.

Ultimately, this approach transforms Carbon Black from a primary prevention tool into a rich data source within a broader monitoring context. The primary goal shifts from perfect protection to accelerated detection and response, buying critical time for the eventual workload migration or upgrade. The most significant pitfall is assuming Carbon Black alone provides adequate security for an unsupported OS—it does not.

—chris]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>chris</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/whats-the-best-way-to-handle-legacy-os-win-server-2012-with-carbon-black/</guid>
                    </item>
				                    <item>
                        <title>My results after a 90-day PoC: Hard numbers on alert volume and MTTR.</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/my-results-after-a-90-day-poc-hard-numbers-on-alert-volume-and-mttr/</link>
                        <pubDate>Tue, 21 Jul 2026 07:12:24 +0000</pubDate>
                        <description><![CDATA[Just wrapped up a 90-day Carbon Black POC. Everyone talks about &quot;better security posture.&quot; I care about two things: alert noise and how long it takes my team to kill something.

Here are the...]]></description>
                        <content:encoded><![CDATA[Just wrapped up a 90-day Carbon Black POC. Everyone talks about "better security posture." I care about two things: alert noise and how long it takes my team to kill something.

Here are the actual numbers from our ~5000 endpoint estate:
* **Baseline (legacy AV):** ~1200 alerts/week, MTTR ~4 hours (mostly triage)
* **Carbon Black (first 30 days):** ~3400 alerts/week &#x1f611;
* **Carbon Black (final 30 days, tuned):** ~220 alerts/week, MTTR ~25 minutes

The kicker? The "tuning" wasn't fancy. It was:
- Killing all the default "informational" garbage alerts
- Writing 4 custom watchlist rules that actually mattered for our stack
- Setting proper exclusions for our CI/CD runners and dev containers

The product isn't magic. The out-of-the-box config is a flood designed to scare you into thinking you're vulnerable. Tear it down to what you actually need, and the numbers get real.

Paying for the "cloud" console felt like a tax. The API is decent though. For the price, I expected less babysitting.

fight me]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>devops_barbarian_v2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/my-results-after-a-90-day-poc-hard-numbers-on-alert-volume-and-mttr/</guid>
                    </item>
				                    <item>
                        <title>Help: Sensor disconnections spiking after latest agent update (v4.7).</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/help-sensor-disconnections-spiking-after-latest-agent-update-v4-7/</link>
                        <pubDate>Tue, 21 Jul 2026 06:05:01 +0000</pubDate>
                        <description><![CDATA[Hi everyone. I’ve been quietly following the discussions here for a while, but we’ve hit an issue I haven’t seen covered yet.

Since deploying the latest agent update (v4.7) across our Windo...]]></description>
                        <content:encoded><![CDATA[Hi everyone. I’ve been quietly following the discussions here for a while, but we’ve hit an issue I haven’t seen covered yet.

Since deploying the latest agent update (v4.7) across our Windows 10 and Server 2019 systems, we’ve seen a significant spike in sensor disconnections. Our dashboard shows intermittent drops, usually lasting 2-5 minutes, before the sensors reconnect. This wasn’t happening at this scale with the previous version.

Our environment is relatively standard, with the agents communicating through our proxy servers. We’ve double-checked the proxy rules and firewall logs, and there’s no increase in blocked traffic that correlates with the disconnection times.

I’m curious if anyone else is observing this pattern after the update. Specifically:
- Are the disconnections clustered at particular times, like during system startup or a specific scheduled task?
- Has anyone found a correlation with other security software? We run a separate EDR tool, but there were no conflicts before.
- Are there any recommended configuration tweaks for the sensor settings in the policy to improve stability with this version?

I’m looking through our Carbon Black Cloud console for clues, but any pointers on where to focus the logs would be really helpful.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>emilyh</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/help-sensor-disconnections-spiking-after-latest-agent-update-v4-7/</guid>
                    </item>
				                    <item>
                        <title>Switched from Carbon Black to Microsoft Defender for Endpoint - honest comparison after 6 months</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/switched-from-carbon-black-to-microsoft-defender-for-endpoint-honest-comparison-after-6-months/</link>
                        <pubDate>Tue, 21 Jul 2026 05:01:51 +0000</pubDate>
                        <description><![CDATA[Hey folks, longtime Carbon Black user here (ran their EDR on our Linux workloads for about 2 years). Our org recently went all-in on the Microsoft ecosystem, so we were pushed to migrate to ...]]></description>
                        <content:encoded><![CDATA[Hey folks, longtime Carbon Black user here (ran their EDR on our Linux workloads for about 2 years). Our org recently went all-in on the Microsoft ecosystem, so we were pushed to migrate to Microsoft Defender for Endpoint (MDE). I've spent the last six months knee-deep in both, so wanted to share a hands-on, backend-focused comparison.

**Deployment &amp; Management**
Carbon Black felt like a separate, specialized appliance. Its API was robust but very much its own world. MDE is, unsurprisingly, deeply woven into the Microsoft Graph security API. If you're already using `Entra ID` and `Intune`, the integration is seamless. The trade-off? Less standalone configuraability. Managing everything via Graph is powerful, but the learning curve is steeper than CB's more focused interface.

**Performance &amp; Resource Impact**
On our Linux boxes (mostly API backends), CB's sensor was predictable but could be heavy during full scans. MDE's footprint is generally lighter, but we saw more variable I/O usage. The biggest difference is in the cloud processing: CB's "conclusions" felt faster for custom IOCs, while MDE relies more on its cloud ML, which sometimes adds latency to alerts. Here's a quick comparison of resource usage from our monitoring (avg over 100 VMs):

| Component | Carbon Black (avg CPU%) | MDE (avg CPU%) |
|-----------|-------------------------|----------------|
| User Mode | 3.5%                    | 2.1%           |
| Kernel    | 1.8%                    | 2.9%           |
| Memory    | 215 MB                  | 185 MB         |

**API &amp; Automation**
This was a big one for me. CB's API is very RESTful, well-documented, and great for pulling raw telemetry into our Postgres logs DB. MDE's advanced hunting (KQL) is incredibly powerful for analysts, but as a dev, I miss the straightforward REST endpoints. Writing automations now means wrestling with KQL queries via the Graph API, which is more complex. Example: fetching a simple process list from a host.

Carbon Black (straightforward):
```http
GET /api/v1/process?hostname=api-server-01
```

MDE (requires KQL via Graph):
```http
POST https://api.security.microsoft.com/api/advancedhunting/run
{
  "Query": "DeviceProcessEvents | where DeviceName == 'api-server-01' | limit 100"
}
```

**The Bottom Line**
If you need deep, customizable EDR with a great standalone API and don't mind managing another pane of glass, Carbon Black is superb. Defender for Endpoint wins if you live in the Microsoft cloud—the integration and unified security posture are hard to beat, but be prepared for a different, query-centric automation model.

For our microservices stack, the native integration with our existing Azure services tipped the scales, but I do miss the simplicity of CB's data model. Curious if others have had similar experiences, especially on non-Windows workloads.

--builder]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>backend_builder</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/switched-from-carbon-black-to-microsoft-defender-for-endpoint-honest-comparison-after-6-months/</guid>
                    </item>
				                    <item>
                        <title>Has anyone benchmarked the sensor&#039;s disk I/O impact on SQL servers?</title>
                        <link>https://communities.stackinsight.net/community/cyber-carbon-black/has-anyone-benchmarked-the-sensors-disk-i-o-impact-on-sql-servers/</link>
                        <pubDate>Tue, 21 Jul 2026 03:30:27 +0000</pubDate>
                        <description><![CDATA[Every vendor white paper and sales deck touts &quot;near-zero performance impact,&quot; a phrase that should trigger immediate skepticism in anyone who has ever run a production database. When I see t...]]></description>
                        <content:encoded><![CDATA[Every vendor white paper and sales deck touts "near-zero performance impact," a phrase that should trigger immediate skepticism in anyone who has ever run a production database. When I see that, I immediately translate it to "we haven't measured it under a realistic workload, or we're defining 'near-zero' in a way that would make a politician blush."

I'm specifically looking at Carbon Black for some of our Windows-based SQL Server instances, but before I even consider a rollout, I need hard numbers. The sensor is, at its core, a filesystem filter driver, and anyone who has dealt with those knows they can turn a high-throughput OLTP disk subsystem into a congested single-lane road during rush hour. I'm not interested in anecdotes about "it feels fine." I need to see the quantified latency tax on:
*   Log file writes (sequential, but latency-sensitive)
*   TempDB operations (random, high-frequency)
*   Checkpoint operations
*   Backup I/O streams

Has anyone done a proper, controlled benchmark? I'm thinking using something like Diskspd or HammerDB with a defined workload, capturing metrics from the host, the SQL Server wait stats (WRITELOG, PAGEIOLATCH_*, etc.), and the Windows performance counters for the disk subsystem. The key is a before/after with the sensor in both passive and active modes.

I'd want to see the configuration used as well. The impact is undoubtedly tunable, but tuning for performance often means gutting the security efficacy, which is the whole point. A sample of a "performance-optimized" policy that still provides meaningful protection would be illustrative.

```yaml
# What does a 'SQL Server Optimized' policy look like?
# Example: Exclusions that go beyond the basic C:Program Files...
# - Specific process names (sqlservr.exe, ssms.exe)?
# - Exclusion of .mdf, .ldf, .ndf file extensions (risky?)
# - Directory exclusions for DATA, LOG, BACKUP volumes?
# - Sensor resource limits (CPU throttling, IOPS throttling)?
```

Without this data, we're just trading a potential security threat for a guaranteed performance and stability threat. The FinOps side of me also wants to know if this I/O latency translates to needing to scale up instances or provision higher-tier storage to maintain SLA, which is just another form of hidden cost.

So, has anyone actually put this to the test with a methodology that would hold up under peer review, or are we all just crossing our fingers and hoping the marketing material isn't completely fictional?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-carbon-black/">VMware Carbon Black Reviews</category>                        <dc:creator>cameronj</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-carbon-black/has-anyone-benchmarked-the-sensors-disk-i-o-impact-on-sql-servers/</guid>
                    </item>
							        </channel>
        </rss>
		