Auto-remediation on Defender for Endpoint is quarantining critical files from our CAD suite (SOLIDWORKS). Breaks licensing and causes corrupted assemblies on load.
Tried creating an indicator to allow the process and its directories. Didn't work. Remediation still triggers.
Current exclusion attempt (via PowerShell):
```powershell
Add-MpPreference -ExclusionProcess "C:Program FilesSOLIDWORKS CorpSOLIDWORKSsldworks.exe"
Add-MpPreference -ExclusionPath "C:ProgramDataSOLIDWORKS"
```
Need the exact MDE policy settings to prevent automated response on these files. Process tree exclusions? Should we turn off auto-remediation entirely for this device group?
- What's the precedence order? AV exclusions vs. MDE automated response exclusions?
- Is the ASR rule "Block executable content from email client and webmail" a likely culprit? Logs are unclear.
-bench_beast
Benchmarks don't lie.
Have you checked the exclusions are actually applying? I've seen them fail if the device is getting conflicting policies from Intune and local config.
Your question about AV exclusions vs. MDE automated response is key. My understanding is they're separate. The AV exclusion might stop the scan, but the automated response could still act based on a different detection source.
For process tree exclusions, you need to set that in the MDE portal under Settings > Endpoints > Advanced features > Automation exclusions. Add the SOLIDWORKS parent process there.
Turning off auto-remediation for the group seems too broad, but maybe as a temporary fix? I'd be worried about other threats getting through.
learning every day
Exactly right about the separate exclusions, that's a common tripping point. The AV exclusions stop the local scanner, but the automated response engine can still act on EDR telemetry or cloud detections.
I'd add that for the automation exclusions in the portal, you'll want to exclude both the main executable and any child processes it spawns. SOLIDWORKS often launches separate modules for simulation or file management, and the automated response could trigger on one of those.
And I agree, turning off auto-remediation for the whole group is a last resort. It's better to get the process tree exclusion right. Have you also checked the alert itself in the portal to see the exact detection source? That can tell you if it's a file, behavior, or script detection driving the action.
Keep it real, keep it kind.
Totally feel your pain with this one. I've seen similar issues with specialized engineering software, and those MDE automation exclusions can be really finicky. Others here are spot on about the separate exclusion systems.
For your question about precedence, I think the automated response rules can override the AV ones in some cases, especially if it's a cloud-initiated action. That might be why your PowerShell fix didn't stick.
Have you looked at the "Automation exclusions" under device groups in the MDE portal yet? You might need to add the entire SOLIDWORKS folder tree there, not just the main EXE. It's a different policy spot than where you set the AV scanner exclusions.
The ASR rule "Block executable content from email client and webmail" is probably unrelated to your CAD software's core processes, but I've seen ASR rules cause unexpected blocks on installer scripts. Have you checked the file paths being quarantined in the security center? That might tell you if it's a specific component, like a license manager or update module, getting caught.
I'm still learning MDE's exclusion hierarchy myself, but I found the device group-based "Automation exclusions" you need are in a different portal section than the AV ones. The PowerShell exclusions you set might be getting overridden by a higher-priority Intune policy for your group. Could you check if there's a conflict there?
That's a really good point about checking the quarantined file paths. I had a similar issue once with a different software suite, and it turned out the auto-remediation was targeting a tiny background licensing service, not the main application. Identifying that specific component let us narrow the exclusion way down instead of trying to cover the whole folder.
And thanks for the tip about the different policy spots. It sounds like the PowerShell AV exclusions and the MDE portal automation exclusions are managed separately, which explains why one might not stop the other. I'll definitely look into the Intune policy conflict you mentioned.
Do you know if the automation exclusions in the portal take effect immediately, or is there a sync delay like with some other settings?
PowerShell AV exclusions won't stop automated remediation. You need the process tree exclusions in the MDE portal under Settings > Endpoints > Automation exclusions.
Add the parent process and maybe the licensing service. Check the exact detection in the portal first - it'll show you if it's a file, behavior, or script that's triggering it. That rule you mentioned is probably unrelated, but check the file paths in the alert details.
Don't turn off auto-remediation for the group. Get the process tree exclusion right. There's a slight sync delay, usually a few minutes after you save.
Run it yourself.
You're absolutely correct about the portal location and the separate exclusion systems. That sync delay is critical to flag.
When you set the process tree exclusion, immediately navigate to the device's page in the portal (Security Center > Devices > select device > Exclusions). The applied exclusions from policy will list there, but it can take 5-10 minutes for the device to check in and refresh that view. Watching that list is more reliable than waiting for an incident to see if it worked.