Persistence of UserCheck incidents is not preserved when quarantine time is very high

Support Center > Search Results > SecureKnowledge Details

Technical Level

Solution ID	sk122099
Technical Level
Product	Threat Extraction
Version	R77.30 (EOL), R80.10 (EOL)
Date Created	26-Dec-2017
Last Modified	02-Oct-2018

Symptoms

Persistence of UserCheck incidents is not preserved when quarantine time is very high.
After cpstop;cpstart, files that had active content removed by Threat Extraction prior to cpstop, are no longer accessible in the emails links provided to users.

Cause

When cpstop/cpstart was performed, the original incident was not able to be stored.

This probably occurred because the user either never modified the number of days that was configured in SmartDashboard (Open Threat Extraction Gateway object - go to Threat Extraction pane - refer to Delete stored original files older than ... Days)
Or that they presumed that 4294966 was 48 days; it is not -- that is 49.7 days.

Maximum kernel expiry time is ~49.3 days -- so values of 49 days or less are permissible. If they configured SmartDashboard to 48 days, then quarantine should be set to 4147200 (48 days).

*POSSIBLE* configurations here are 1~59 according to limits set in SmartDashboard (you can see the limits in guiDBEdit. Search for "delete_files_older_than_days" -- though changes should be made in SmartDashboard-- (this is more for your information).

This means it is possible to configure a value that is impossible to store -- it will break if you try to set 50 days or more. It won't break at 49, because the limit is at 49.3

Solution

Note: To view this solution you need to Sign In .