Occasionally Sophos receives reports of an unusual performance impact on a small number of systems, after the installation of a SafeGuard 8.1 file encryption module (Data Exchange, File Encryption, Synchronized Encryption or Cloud Storage). Often this primarily affects low spec hardware, equipped with spindle disks but is not limited to this.
Good to know is, that a filter driver with improvements in regards to boot and runtime performance is available in the latest File Encryption Engine update, which can be installed on top of a SafeGuard 126.96.36.1993 Client.
Information and downloads of the latest File Encryption Engine updates can be found here.
Besides that, it is important to understand what is expected and what can be considered an issue. File encryption always comes with a certain impact on the performance of a system, in most use cases the felt impact on a users workflow is neglectable on current hardware.
A deep dive into the technical background is available here. If a performance impact is not explainable and outside the expected boundaries, you should follow the steps described in this KBA.
The following sections are covered:
Applies to the following Sophos products and versions SafeGuard Data Exchange 8.1SafeGuard Synchronized Encryption 8.1SafeGuard File Encryption 8.1SafeGuard Cloud Storage 8.1
First of all, the involvement of the SafeGuard file filter driver needs to be verified. This can be achieved by temporarily disabling it using a registry key as described in KBA132398
Whether there are additional 3rd party filter drivers installed and active on an endpoint, can be verified running FLTMC in an elevated Command Prompt. Crosschecking if an issue only exists with a combination of several filters, e.g. by disabling other filters or temporarily uninstalling the corresponding 3rd party software, also makes sense when narrowing down the reason for a performance issue.
If the performance without the SafeGuard file filter loaded, is back on the expected level, the following steps can help mitigating the impact or gathering the required logs for an investigation. The measure depends on the issue you experience, here we need to distinguish between boot and run-time performance impact.
Mitigation: Add Explorer.exe to the SpecialNetworkShareWriteApps registry key.
The driver removes the "share write" flag for applications defined in this reg key when a file is opened on a network volume for reading. This can increase performance, because without "share write" the isolation filter must not reread the cache when performing a cached read.
Download the SpecialNetworkShareWriteApps file, remove the .txt extension and apply the resulting .reg file on an affected system. After a reboot the filter driver will consider the new handling for the Explorer.exe.
Mitigation #1: Ignore the corresponding path or volume
Define System Ignore Rules for folders which are used for example to compile data (e.g. MS Visual Studio) or that contain databases.
System Ignore Rules apply to "transparent encryption" and also "initial encryption". That means that no file in a System Ignore Rule can be "initial encrypted" even if an "encryption rule" applies. If an encrypted file resides in a "System Ignore Rules" directory (e.g. encrypted before the System Ignore Rule was added) the user just gets the encrypted data of the file.
If you want to add directories to the System Ignore Rules, modify the following registry key:
The paths are separated by semicolons.
Example: "IgnoreRules"="c:\*.*; \\server\plain\*.*"
Mitigation #2 (only if files are located on a network share): Add the executable of the affected application to the SpecialNetworkShareReadApps registry key.
The driver will remove the "share read" flag for applications defined in this reg key when a file is opened on a network volume for writing. This can increase performance, because without "share read" the isolation filter must not flush the cache after each write into it.
If that does not help follow the steps below.
Mitigation (only if files are located on a network share): Add the executable of the affected application to the SpecialNetworkShareReadApps registry key.
If that does not help follow the steps below:
Gather a boot Process Monitor log as described in KBA119038 and provide it together with an SDU log.
If you've spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article. This is invaluable to us to ensure that we continually strive to give our customers the best information possible.
Every comment submitted here is read (by a human) but we do not reply to specific technical questions. For technical support post a question to the community. Or click here for new feature/product improvements. Alternatively for paid/licensed products open a support ticket.