We recently updated our DLP client to DLP9.1 patch 1 (188.8.131.52 running with extension 184.108.40.206. We have seven ePO servers in the environment all running the EXACT same setup and policy.
For some reason, machines homed on only ONE of the ePO servers are experiencing an issue in which they cannot save Excel spreadsheets to a network share.
We've taken the following troubleshooting steps:
1) First, DLP was uninstalled, the machine in question rebooted, and we were able to save directly to the network share.
2) DLP was reinstalled/rebooted, and we could no longer save directly to the share. (This is not a specific share; it's specifically Excel spreadsheets and any network share.)
3) We can save the Excel spreadsheet locally and copy it over to any share fine.
4) We moved the machine to another ePO server, uninstalled/rebooted, reinstalled/rebooted, and we could save directly to the share fine. As soon as the machine was placed back on the ePO server in question and policy updated, we could no longer save.
5) We imported the global agent configuration from one of our functioning servers to the trouble ePO server, and we still could not share even after policy refresh/reboot.
6) We disabled all the computer assignment groups on one machine, and rebooted, and could not save.
7) We disabled the only "module" of DLP we are utilizing (DCM): Removable Storage Protection. We rebooted, and COULD save directly to the network share. Turning it back on and rebooting gave us the same problem.
Our policies on the other ePO servers are identical and no machines on them are experiencing this issue. It is not every machine on this specific server experiencing the issue.
Below is a piece of the DLP debug logs we pulled on a machine experiencing the problem. It is replicated every time we attempt to save the a spreadsheet to a network share.
Imagine the "FILESHARE SERVER NAME" is a machine name.
14:23:30:291 [ODEBUG] (5652-5656) [DNS Service][DNSResolvingService::translateServer2KeyServerName] resolve alias *FILESHARE SERVER NAME* as server *FILE SHARE SERVER NAME*
14:23:30:291 [OERROR] (5652-5656) [File Handler][FileFilterHandler::onClose] We don't have open info on this file (1251223)
I tried mapping the share directly to an IP address and received the same error in the debug log, except obviously the server name was replaced with an IP address.
I currently have an SR open with McAfee at Tier 3, but we have found no joy yet on a way forward with the issue.
Has anyone seen anything similar?