Skip to main content

We just upgraded to 2022E. We would like to know how to reduce false positives from our roaming terminal services profiles stored on our main file server, from our users that are using Microsoft Visual Studio Code… I’m sure Commvault, you know that one of the file extensions you are constantly alerting on is anything ending in “.code” - but the problem with this is that VScode saves temp files with .code extension in users’ appdata folders. Here’s an example from this morning:

Description: A suspicious file iM:\LabTSProfiles\jsmith.v6\AppData\Roaming\Code\CachedData\6261075646f055b99068d3688932416f2346dd3b\polyfills-3e1ee7640a5aae80b3466bca7f4bdf90.code] is detected on the machine

Anyway as you can see, we have John Smith’s roaming appdata folder, with VS Code’s “code” folder.

I’d like to know if I can use a wildcard of some kind to specifically exclude any .code file that falls into that Code subfolder. I do not want to use the sExcludeExtensions additional setting to block every code file, I just want to do something like:

M:\LabTSProfiles\*\AppData\Roaming\Code\CachedData\*\*.code

This would, in theory, get every roaming profile (the first asterisk that replaces jsmith.v6), then the first random string of alphanumeric characters for Code’s cacheddata folder, then lastly the random alphanumeric string that makes up the filename before the code extension.

Will the asterisk wildcard option I hypothesize above work, or does Commvault use some other character, or do I have no options to do what I’m asking?

Check out the link below

This may be an easier filter expression if I got you right

M:\**\*.code - includes the file named move.cpp located at any directory level under the C: drive. (e.g., c:\info\com\move.cpp)

ttps://documentation.commvault.com/2022e/expert/62537_wildcards_for_windows_file_system_agent.html

Hello @Hyder - well, we were trying not to be too permissive and allow .code files to exist anywhere, at least during this audit period. We specifically were looking for .code files, in the appdata\code folder of our terminal services profiles.

With that caveat aside, it seems like you’re saying with the link you posted which lists itself as being for the file backup system, not for the File Anomaly detection system, can work with both? That’s great news if so.

My colleagues and I have implemented a test to see if we stop getting false positives for vscode files, and if that does indeed do the trick over the next few days, then your response will be the best answer.

That being said, I might make the suggestion to update the documentation at https://documentation.commvault.com/v11/essential/134333_monitoring_unusual_file_activity.html to mention a link to the aforementioned document and make it clear that this is the formatting and structure for wildcards mentioned at that link, can also be used in the AdditionalSettings. Thanks!

@Hyder unfortunately the filter M:\LabTSProfiles\*\AppData\Roaming\Code\CachedData\*\*.code in sAnomalyFilters did not work, we are still being emailed with false positives for files ending in .code on our file server.

The one that just went off now (besides username being redacted) was

Description: A suspicious file [M:\LabTSProfiles\username.v6\AppData\Roaming\Code\CachedData\6261075646f055b99068d3688932416f2346dd3b\sqlite3-ec1ce889c385a0602b29444d97f1b5b6.code] is detected on the machine [sscwin]. Please alert your administrator.

Any idea what we are doing wrong with the filter we are doing above?

Did you happen to run a Full on the test subclient after adding the filter?

No - we run 3x daily incrementals on weekdays, then a synthetic full to roll those up on saturday. We do not ever run full backups because they take so long.

...that shouldn’t make a difference though, should it? We have other filters that are working fine, but they’re less complex (i.e. we have one filter that is an entire path with no wildcards which works fine, and we have one filter that uses a c:\users\serviceaccount\** wildcard, and that also works fine.

We specifically want to allow .code files from our users’ terminal services appdata folders for VS code though, as this is the false positive email we get the most often. Basically, whenever a user happens to be working in VScode on our terminal servers when one of the 3x daily incremental runs, and commvault’s file agent detects a new .code file in that appdata folder, we get an email.

It’s very annoying.

Can you make a test subcilent, then make a test folder and mimic the pathing and run a full to see if the filter takes effect, I can’t confirm but really think you need a full for that to take effect

No - we run 3x daily incrementals on weekdays, then a synthetic full to roll those up on saturday. We do not ever run full backups because they take so long.

...that shouldn’t make a difference though, should it? We have other filters that are working fine, but they’re less complex (i.e. we have one filter that is an entire path with no wildcards which works fine, and we have one filter that uses a c:\users\serviceaccount\** wildcard, and that also works fine.

We specifically want to allow .code files from our users’ terminal services appdata folders for VS code though, as this is the false positive email we get the most often. Basically, whenever a user happens to be working in VScode on our terminal servers when one of the 3x daily incremental runs, and commvault’s file agent detects a new .code file in that appdata folder, we get an email.

It’s very annoying.

I think SynFull should work too

 

Reply


Terms & ConditionsCookie settings