What's the best way to handle OS updates without triggering S1 protections?

Hey there, I'm a systems architect at a mid-size fintech (around 300 endpoints), and we've been running SentinelOne across Windows and Mac for about three years now. We do managed monthly patching for both OS families, so we've been through this exact wringer.

Here's the breakdown of approaches we've tried and what we've settled on:

* **Temporary Policy Group**: We initially tried moving devices into a "Monitoring Only" group for a 4-hour update window. It worked, but the manual group management and the brief, full-coverage gap felt risky. It also created ticket noise from users whose updates ran outside the window. We saw a 15-20% admin time overhead just coordinating this dance.
* **Process Exclusions**: This is the most common advice, but getting it right is fiddly. For Windows, you need to exclude `TrustedInstaller.exe`, `TiWorker.exe`, and sometimes `dism.exe` and `wusa.exe`. For macOS, it's `softwareupdated` and `installer`. The key detail is to scope the exclusion **specifically to the "Installation" and "Patching" policy modules** and NOT to the real-time protection. This kept us safe but allowed updates through. It took us two patch cycles to refine the list and avoid over-privileging.
* **Script-Based Control**: Our current, automated method uses the SentinelOne API. About an hour before our patch deployment, a script runs that does two things: first, it temporarily sets the "Script Control" module to "Monitor" for the target device group, and second, it adds a one-time, 6-hour exclusion for the hash of our patch deployment toolkit. This gives us a tight, audited window. The script then reverts the settings after the window. This required about 40 hours of initial dev time but has cut update-related issues to near zero.
* **Ransomware Rollback & Rollback Settings**: This was our biggest lesson. You **must** temporarily disable "Ransomware Rollback" for the update duration. Even with process exclusions, we found this feature could sometimes quarantine a crucial update file, thinking it was malicious encryption. We dial this down via API/script as well. We leave other behavioral protections (like suspicious behavior) fully active.

My pick is the **Script-Based Control** method if you have any automation capacity. It's the best balance of security and ops smoothness for a managed environment. If you're fully manual, then go with **tight Process Exclusions** scoped only to the Installation/Patching modules.

To decide, tell us if you have API access/licensing and if your patch deployment is on a fixed, known schedule.

That's a really solid breakdown of the trade-offs. The scoping detail about limiting exclusions to just the Installation/Patching modules is crucial - we missed that at first and opened ourselves up.

We landed on a similar process-exclusion model, but we paired it with a lightweight automation step to reduce the overhead you mentioned. Our patch management tool (InsightVM in our case) tags devices as "Patching_In_Progress" via the S1 API about 15 minutes before the job runs. A separate, more permissive policy is scoped to that tag. It gives us the safety valve without permanently widening any rules. It did require some scripting glue, though.

Oh, the driver update thing is the worst. It feels like you're always choosing between breaking the update or breaking the protection.

> very specific exclusions for the trusted installer processes
This is what our team leans toward, but we scope it super tight. Like, not just for `trustedinstaller.exe`, but we also limit it to only the "Installation/Patching" module in the policy. That way, it's not a free pass for anything else.

I'm still new to this though - how do you even start testing exclusions without breaking things in production? Do you have a test group set up?

Totally feel that driver update pain. We do the specific exclusions route too, but we had to go a step further and add the actual Windows Update folders (like `C:WindowsSoftwareDistributionDownload`) to the path exclusions for good measure. That stopped the stubborn "suspicious behavior" flags during downloads.

For testing, we have a pilot group of about 10 non-critical machines. We push the proposed exclusions to them a week early and force a manual update cycle. It's clunky, but it's caught a few bad rules before they hit everyone.

How big is your fleet? I found the exclusion approach gets trickier to manage past a few hundred unique endpoints.

Temporary policy groups are pure operational theater. You're either protected or you're not. That 4-hour window you create is exactly when something nasty decides to land.

The driver update pain is real, but it's S1 doing its job. A "suspicious behavior" alert on a driver is often justified. Creating a narrow path exclusion for the SoftwareDistribution folder is the least-bad option, but you have to accept it as a calculated risk.

Smooth ops vs. security is a false choice here. The real balance is between convenience and actual exposure.

We had that exact same driver update problem a few months back, and it was a mess. I'm fairly new to managing our S1 deployment, but I've been trying to figure out a systematic way to test these changes.

You mentioned being wary of broad exceptions, and I completely agree. We started with the specific process exclusions for trustedinstaller.exe and the like, but found we also needed to add path exclusions for the temporary update folders on Windows, as someone else here noted. The tricky part was discovering that different update types, especially on the macOS side, seemed to use slightly different parent processes, which meant our initial list wasn't comprehensive.

My big question right now is about the testing process. We don't have a formal pilot group, and I'm worried about pushing a new exclusion rule straight to production. How do you validate that your exceptions work correctly without also accidentally creating a blind spot? Is it really just about having a small set of sacrificial test machines you update first, or is there a better way to audit the rule's impact in the console afterward?

Great question. We handle about 500 endpoints, primarily Windows, and landed on the specific process exclusion method after trying temporary policy groups. The operational overhead was just too high.

I'd strongly recommend scoping those exclusions to just the "Installation/Patching" module in the policy. This prevents it from becoming a blanket exception. For Windows, your list should include `trustedinstaller.exe`, `msiexec.exe`, and the various `*.exe` files under `C:WindowsSoftwareDistributionDownload`. Don't forget `TiWorker.exe`. On macOS, watch for `softwareupdated` and `installer`.

The key is testing these in a pilot group first. We use a set of 10 non-critical machines and force a manual update cycle with the proposed exclusions active. It catches about 90% of the issues before they hit production. It sounds like you're already wary of broad exceptions, which is the right instinct. This approach keeps them narrow and contextual.