1 of 1 people found this helpful
Well if this is a new implementation of DLP the first thing I'd suggest is using DLP 3.0 rather than 2.2.
DLP should not be stripping data out of a document being sent to a printer. By design it either blocks/monitors/ignores but it does not modify so the first thing I'd try is uninstalling the DLP agent from a client | reboot | retest and see if the issue persists.
If your confident that DLP is the culprit then certianly uninstalling the print handler would be good troubleshooting step. This has the consequence of disabling all print protection rules. If you are not interested in using any printer protection rules then this would be a good solution.
Thank you for your reply.
The first thing I did was to have the network administration people remove DLP from 5 affected workstations and it fixed the problem. I have no control over the version of DLP that they are using, so I can not change to 3.0. 2.2 is the current mandated version on several million workstations.
From your answer and what I am seeing I am confident that it is DLP that is causing the problem. I normally check the printer drivers on these workstations every day and it was the day that the fc_pscript5.dll appeared that the problems started.
The issue that I may be facing now is to try to recommend a solution short of uninstalling DLP. The installation of DLP on all hosts in this organization is mandated without exception. So I am trying to identiify other potential solutions that don't involve uninstalling DLP. It is possible that this organization is not interested in printing rules and that their interest is only in other DLP features.
Do you know if it is possible to just uninstall the "print handler"? Or is that same thing as uninstalling all of DLP? From the documentation it looked like you would "disable" the "print handler? or is it an actual uninstall?
It may be more acceptable if I could add the printer to the "whitelist"? Do you think this would pull fc_pscript5.dll out of the path?
As I mentioned before I don't know anything about the software so I apologize if these questions seem a little funny.
I have been tasked with putting together a recommended solution without having access to McAfee support, without access to the software, without documentation, and without any local administration rights, and provide it to an organization that doesn't want to do anything about my problem.
Thanks for your help.
You can uninstall the printer handler without uninstalling the entire product; however, it must be done via a policy change in the DLP console and it requires a reboot on the client machine. Here is how:
- Logon to the ePO console
- Select Systems | DLP Policyfor ePO 4.0 or Menu | Data Protection | DLP Policyfor ePO 4.5
- Select Agent Configuration | Edit Global Agent Configuration
- Click the Miscellaneous tab
- De-select Printer Handler
- Click OK | Apply
- Send the client a wakeup call and after the client successfully reports back to the ePO server reboot the client.
Those steps should disable the printer handler. If you do not have access to the DLP policies I do not have a solution for you.
Thank you for your answer. I can make a recommendation as to how they do a policy change, so this should work.
We have followed all of the suggestions so far. Thank you. Nothing has corrected the problem yet.
I have some follow on information that I wanted to share related to my original questions.
Currently we do not have any printer policies enforced. In our case, it appears that McAfee DLP is inserting fc_pscript5.dll between our application and actual pscript5.dll printer driver (Windows Postscript printer driver). fc_pscript5.dll appears to pass viewable content to a printer without problem. However when the postscript print stream is used as
the basis to create (distill) a PDF file, information is missing from the Postscript file (and the PDF file). This includes hypertext links and PDF structure information.
I have attached 4 files for comparison (with and without McAfee DLP). The first two files were produced on a workstation with McAfee DLP installed. The second set of files were produced on a workstation that did not have McAfee DLP installed. I have provided both Postscript files and the resulting PDF files. You can see in the PDF files that there are no "tags" (PDF structure required for Section 508 compliance) or "annotations" (hypertext links). These files were created with Adobe Framemaker.
C1TOC Created with fc_pscript5.dll.ps - Postscript file created on a workstation with McAfee DLP installed
C1TOC Created with fc_pscript5.dll.pdf - PDF file created from "C1TOC Created with fc_pscript5.dll.ps" using Acrobat Distiller
C1TOC Created with pscript5.dll.ps - Postscript file created on a workstation without McAfee DLP installed
C1TOC Created with fc_pscript5.dll.pdf - PDF file created from "C1TOC Created with pscript5.dll.ps" using Acrobat Distiller