I am new to this comuunity so I hope I have the right community.
I work with a federal government organization that is implementing McAfee DLP 2.2. DLP was recently installed (no policies have been established yet) on all workstations. When it was installed it replaced the Windows XP Postscript driver (pscript5.dll) with fc_pscript5.dll as expected. Printing through fc_pscript5.dll and on through pscript5.dll appears to work fine for printing to a printer.
However we also use these postscript printers to create postscript files that we then use Acrobat distiller to convert to PDF. Most of the PDF features work fine and the file distills to PDF.
However there are several features that don't appear to show up in the Postscript file. This is includes PDF structure and PDF Meta data. The common theme appears to be that these capabilities are implemented using the Postscript PDFMark command (I believe). It appears as if all PDFMark commands are missing from the Postscript files.
I am not in the IT shop and I am not involved with setting up DLP. I can only ask those guys about DLP and they don't know much. All of my info comes from reading docs.
Is it possible that DLP (without any policies) may not be passing the PDFMark through to the Postscript Printer driver? I use Framemaker to print from (which creates the PDFMark commands). Am I doing something wrong?
Would adding this printer to the whitelist fix this (and disable monitoring at the same time)?
Would disabling the DLP Printer Handler fix this?
Thank you for any ideas.
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:
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.
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