NAS and BullZip/bioPDF problem (Windows Server 2003 64-bit)

dorenthas

I created a Codeunit to automate the generation and emailing of PDF reports based on NAS Job Queue scheduling. I used info and code snippets from the following thread by ara3n: How to save Navision Reports as PDF (viewtopic.php?f=5&t=18331&hilit=bullzip+nas)

After struggling with PDF Creator that had a tendency to hang and behave unpredictably, I switched to bioPDF (we have more than 10 users). The code is much simpler, the printing is faster, and best of all, it behaves predictably.

The problem I have is that it only works perfectly when I run the codeunit from a NAV client; when the NAS runs it, the following can be verified, but no PDF is printed:
- A runonce.ini file is created somewhere under the "Local Settings" folder of the NAS service account.
- A PostScript file containing the report to be printed is created somewhere under the "Local Settings\Temp" folder of the NAS service account.
- A port.log file (some kind of bioPDF execution log file) is created in the same folder as the PostScript file.
- A Windows System Event Log entry is created, indicating that a document was printed (e.g. Document 11, Available Resources owned by sa_nas was printed on PDF Writer - bioPDF via port BIOPDF. Size in bytes: 95224; pages printed: 4)

But...
- No PDF file is generated.
- The runonce.ini file is not deleted.
- No trace of any kind of error in the Windows Application Event Log, the Windows System Event Log, or the port.log file.

We're running Windows Server 2003 Enterprise 64-bit Edition, and NAV 5 SP 1. The service account is part of the Domain Users group and has the Allow Print permission on the bioPDF printer. We even tried adding it to the Power Users group as a test, to no avail. Any ideas what could be going wrong?

---

EDIT (Solved) 2010-07-09: In the end, we solved the problem by adding the service account to the local Administrators group. It's definitely not the best solution, but we don't want to spend hours trying to look for that single server policy or permission setting that is preventing the non-admin service account from printing to bioPDF (and to that one only). Our sys admin approves the solution as a temporary measure since it is a dedicated service account, and very few people have direct access to the server and/or to the service account credentials in the first place.

ara3n

take a look at this post
http://www.mibuso.com/forum/viewtopic.php?f=23&t=28820

dorenthas

Thanks for pointing it out, Rashed, but I already had In fact, I carefully checked all posts from this search.

The issue that Luc had is not quite the same as the one I have. In my case, the runonce.ini file is properly generated (at least, it seems to be) and the properties set in it are apparently used by bioPDF because they are all mentioned in the port.log file. The runonce.ini file ends up in "Documents and Settings\sa_nas\Local Settings\Application Data\PDF Writer\PDF Writer - bioPDF\" while the port.log file and the PostScript file are located in "Documents and Settings\sa_nas\Local Settings\Temp\bioPDF\PDF Writer\"

dorenthas

In case I missed something, here's the code I use, in case I missed something or am misusing the PDF printer.

fPrintReportToPDF() : Boolean
// Ensure bioPDF is the default printer
IF NOT lrPrinterSelection.GET('', giReportNo) THEN BEGIN
  lrPrinterSelection.INIT;
  lrPrinterSelection."Report ID" := giReportNo;
  lrPrinterSelection."Printer Name" := 'PDF Writer - bioPDF';
  lrPrinterSelection.INSERT;
END;

// Initialize PDF Writer
IF ISCLEAR(gaPDFPrinter) THEN
  CREATE(gaPDFPrinter);

gaPDFPrinter.Init();
ltIniFilePath := gaPDFPrinter.GetSettingsFileName(TRUE);
IF FILE.EXISTS(ltIniFilePath) THEN
  FILE.ERASE(ltIniFilePath);
gaPDFPrinter.SetValue('Output', gtPDFFilePath);
gaPDFPrinter.SetValue('ShowSettings', 'never');
gaPDFPrinter.SetValue('ShowPDF', 'no');
gaPDFPrinter.SetValue('ShowProgress', 'no');
gaPDFPrinter.SetValue('ShowProgressFinished', 'no');
gaPDFPrinter.SetValue('SuppressErrors', 'yes');
gaPDFPrinter.SetValue('ConfirmOverwrite', 'no');
gaPDFPrinter.SetValue('GhostscriptTimeout', '10');
gaPDFPrinter.WriteSettings(TRUE);

REPORT.RUNMODAL(giReportNo, FALSE, FALSE);

lrPrinterSelection.DELETE;

liTimeout := 0;
WHILE FILE.EXISTS(ltIniFilePath) AND (liTimeout < 10) DO BEGIN
    SLEEP(1000);
    liTimeout := liTimeout + 1;
END;
EXIT(liTimeout < 10); // TRUE indicates success

ara3n

i see that after init you are missing loadsettings.

gaPDFPrinter.Init();
gaPDFPrinter..LoadSettings;

dorenthas

I was under the impression that LoadSettings would fetch the default config in the registry. That might be the problem, but currently our testing shows that if we log into the server with the sa_nas account, it cannot even print a Test Page on bioPDF unless it is part of the Administrators group. Our system admin thinks this may have to do with weird impersonation black magic in bioPDF's logic...

So once we solve the permission/policy issue, I'll look at the LoadSettings line.

I'll keep you updated.

dorenthas

A note on the LoadSettings function...

According to the API documentation (http://www.biopdf.com/guide/dotnet/chm/ ... ttings.htm), using LoadSettings will read the configuration and load it into memory, but if the config file doesn't exist, it will load an empty configuration.

Actually, an empty configuration is okay, because we build it dynamically (through the SetValue calls followed by WriteSettings), therefore I'm fairly certain that the LoadSettings call after the Init call is superfluous.