Server printer suddenly stopped working in live


(James McKinnon) #1

We are unable to print any report from live via print | server printer. My initial thoughts were that it was a windows printer share issue or a physical printer issue and I spent a load of time debugging fault finding around this, creating a new queue, new printer port etc all to no avail. I also tried creating a brand new printer in Epicor printer maintenance pointing at the same physical hardware/ip address again with no success.

The same reports all work ok printing from Epicor server printing to other printers.

On a whim I tried doing the same thing from our E10 test system, which is a recent copy of live and which is hosted on the same server and it all works ok, any report will print without issue to that server printer.

I have started and stopped the task agent numerous times. There is nothing in the windows server event viewer. I am the only person with admin access on the servers and no permissions changes or updates have been applied since this was last working.

So in summary I cannot print via the server printer option to one printer from our E10 live instance, I can from test and I can to other printers. I’m thinking this is possibly IIS getting itself in a knot so was going to cycle the IIS instance for live at the weekend but in case that doesn’t fox I was wondering of other folks have seen this…

Error message is

    Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask: Settings to access printer '\\xxxxxx\despatch' are not valid.
   at System.Drawing.Printing.PrinterSettings.GetHdevmodeInternal(String printer)
   at System.Drawing.Printing.PrinterSettings.GetHdevmode(PageSettings pageSettings)
   at PdfPrintingNet.PdfPrint.Print(String fileName, String password)
   at Ice.Core.SsrsReporting.PdfReportPrinter.Print(Byte[] reportBytes, String printerNameParameter, EpiPrinterSettings printerSettings, EpiPageSettings pageSettings)
   at Ice.Core.SsrsReporting.ReportProcessorBase`1.RenderReportForPrintFaxOrEmailReport(SysRptLst sysRptLstRow)
   at Ice.Core.SsrsReporting.ReportProcessorBase`1.ProcessReportPart(String reportLocation, Action`1 modifySysRptLstRow)
   at Ice.Core.RptBase.ReportSsrsDatabaseBuilder`1.ProcessReportWithDataInPlace(SqlConnection connection)
   at Ice.Core.RptBase.ReportDatabaseBuilder`1.XMLClose()
   at Erp.Internal.OM.OMR50.RunProcess(Int32 instanceTaskNum, String outputFileName)
   at Ice.Hosting.TaskCaller.ExecuteTask()
   at Ice.Services.Lib.RunTaskSvc.RunTask(Int32 ipTaskNum)

(Tanner Post) #2

We see this error message all the time. For us, it happens when our AP clerk prints checks to a server sided printer (which she needs to do because client side printing doesn’t recognize the manual tray). Every time she prints checks to the server printer she needs to print them twice. The first time will crash the report with an error like above and the second time works (but she needs to reset the check sequence number so the correct check number is printed on the checks). Our problem is reported as PRB0190007 and target version is 3.2, and target service pack is 3.2.300. I have been trying to request a fix for 10.1.600.X but sounds like I have to wait about 6 more weeks to see if that is possible.


(James McKinnon) #3

That’s interesting as whilst we are doing something different, printing despatch notes, we are also doing something similar, printing two copies - we have a bpm that does this all automatically when the shipped box is checked. Our issue was that this stopped working on Friday, but even doing the same thing manually did not work and gave the same error.

As I didn’t think it was an Epicor problem initially, I thought it was a windows server problem, as test was unaffected, so created a new printer share, uninstalled/reinstalled the printer etc all to no avail - I also restarted the epicor task manager. I recycled IIS at the weekend and it worked straightway after doing this but as I had done so much else to try and fix I’m not sure if just doing the IIS recycle would have fixed.

We are on version 10.0.7.4, and this is the first time this has happened in the 16 months since we went live.