When DLP Endpoint Detection is enabled for Office files such as Word, Excel or Power Point on networks with high latency, a longer than expected delay may be observed.
When the "Copy to Share" channel is enabled in the Agent configuration and the Advanced Agent features of File Restoration (FileSystem.ENABLE_FILE_RESTORATION.int=1) and VEP (FileSystem.ENABLE_VEP_FILE_ELIMINATION.int=3) are at their default settings (1 and 3 respectively), an SNP copy is made in the local endpoint agent’s temp directory when a Word or Excel document is opened from a network share.
In this process, a total of 2 additional file copies from the share happen at Open, 1 SNP file of the actual file you are opening and 1 VEP file of the Word "Owner File" which is the hidden ~$<stub>.docx file that gets created in the same directory as the file itself, then 3 additional files copied (SNP, VEP, SNP) during Save given our default settings.
Microsoft's save to temp and rename design is described in the following Microsoft KB - under the heading "Saved Files (Same Directory as the Saved File)". It's this design that causes us to create 2 SNP files on Save instead of 1:
The following PowerShell can be used to get the average latency to the file server host being written to (wait for the command prompt to return a value, it takes several seconds):
(test-connection <FileServerHostName> -count 10 | measure-object -property responsetime -average).average
Take this average response time and use it in the formula below to find the expected additional latency for copying a file down from the network that goes through our kernel filter driver:
(Average latency in seconds) * (number of 32KB file chunks) = seconds to copy file.
Our vfsmfd.sys driver requests files in 32KB chunks.
For the “Copy to Share” channel, VEP File Elimination does not apply to saving files to network shares using Word and Excel, because of the order of operations.
Upon Save, Word/Excel write their working data to a tmp file on the network share, and we have to copy that data back in order to have a local copy of the new data that can be extracted and scanned on the endpoint.
Although turning File Restoration off (FileSystem.ENABLE_FILE_RESTORATION.int=0) can provide a speedup (since File Restoration makes the most copies from the network share), there are additional factors to consider if you have any endpoint policies that include response rules with an action set to "Prevent: Block" or "Prevent: User Cancel". Be aware that when a user saves a file that violates a policy that has either of these actions, the destination file will be deleted after the save.
In either case though, the document with the user's changes is quarantined on the endpoint under "%userprofile%\My Recovered Files\FileName <%DateTimeStamp%>\, so the data can be recovered, and the response rule prompt alerts them with the path to the quarantine file.
The File Restoration and VEP File Elimination defaults setting are the most conservative to help ensure both the ability for our service to inspect the data contention-free and the convenience of automatic restoration of the version of the file that was opened, with the tradeoff of additional network latency. On networks with good latency in the 1 to 2 millisecond range, the cumulative latency that comes as a result of our driver requesting the files from the network in 32KB chunks is negligible. Simply put, the cumulative latency overhead increases as network latency increases.
Another approach to limit impact is to pick an upper limit for Office file types for the "Copy to Share" channel using a Monitoring Filter as shown below:
Files that match the File Filter criteria you set in the filter above will not have a File Restoration snapshot (SNP) created at Open, nor a VEP file created at Save, as the agent does not scan the file. A single SNP file still gets created during the Save from the existing document on the share, after the tmp files have been written, and before the interim tmp file gets renamed by the editing application to replace the contents of the document that is being edited.
In one case, the issue only occurred when opening PowerPoint files (PPTX) from Network Shares when connected to VPN. Disabling Application File Access within Global Application Monitoring, just for the affected application, PowerPoint.exe in this case, resolved the issue.