views:

18

answers:

1

Hi,

I have a rather complicated toolchain so prepare for a lengthy post until getting to the problem:

I managed to get PDFCreator and a virtual PDF creating printer under Windows 7 running in server mode as a service. Next step in the process is PDFCreator calling a VBScript after the PDF is created. The script uploads the PDF to our server via WebService and polls the server for a resulting PDF. When the resulting PDF has been downloaded, the VBScript needs to print it to a confiured printer.

Now for printing I was using the integrated COM object of PDFCreator which gives access to GhostScript. This worked perfectly onder Windows XP for any account the PDFCreator service was started. For example as a domain user to have access to shared printers from the VBScript, as the user context is the same as the PDFCreator service.

Now I tried the same for Windows 7 and used the "local system" account as before, because my test printer is a local one (and works, i.e. TestPage). Effect is that the wscript stays in the task manager and never finishes. Next I activated Interactive mode for the service and a saw Ghostscript asking for the printer to print to. The Printer does exist as I checked before calling GS within the VBScript, but out of any reason GhostScript does not see the printer although in the dialog opened to select the printer, the printer is there.

After days long searching and unsuccessfully trying even a dedicted new administrator account for the servive with no success I finally came up with a way to get it working. Changing the user for the PDFCreator service to "locale service" I first got an error that the PDFCreator COM object creation failed. Okay I thought this makes sense, as "locale service" has less rights that "locale system". I got around this limit by changing the access right under comexp.msc and granted "locale service" rights for local and remote COM and Script access. Voilá, everything worked.

What I do not understand: Why is Ghostscript under the "locale service" account capable to find the printer although the account has less rights that "locale system"?

And: Which access right do I need to set for "locale system" or any other user account to make it work?

Or: Is there a comprehensive list of detailed differences between these accounts?

Thank you very much and greetz, GHad

A: 

The answer can be found here: KB184291

It's about ASP/IIS running under "local system" account and cannot print because the printers are not available under the .DEFAULT user. Copying over registry entries helps.

Greetz, GHad

GHad