Not printing when running as service

[dregad]

We're trying to setup alma-print-daemon to run on a server (Windows VM), and are having trouble with printing when the program is running as a service (under local SYSTEM) account. See also #44 for additional context.

Everything works fine when the program is running interactively in the user's session on the server.

Configuration file was generated as follows:

• logged in to the server (over RDP) as a normal user,
• configure print queues, etc
• save and exit
• copy config from %APPDATA%\alma-print-config.json to C:\Windows\System32\config\systemprofile\AppData\Roaming\alma-print-daemon\alma-print-config.json
• restart the service

This is the log file:

2023-06-08T08:57:08.673Z:  Alma Print Daemon/Service startup at 2023-06-08T08:57:08.672Z.
2023-06-08T08:57:08.673Z:  Configuration Parameters:
2023-06-08T08:57:08.673Z:  Region = eu
2023-06-08T08:57:08.674Z:  API Key = hidden
2023-06-08T08:57:08.674Z:  Interval (minutes) = 0.5
2023-06-08T08:57:08.674Z:  Auto Start = true
2023-06-08T08:57:08.674Z:  Print Daemon Active Hours = 00:00 to 24:00
2023-06-08T08:57:08.675Z:  Alma Printer Profiles = [{"almaPrinter":"606173990005524","localPrinter":"%5C%5Csrvimp01p%5C60830_UPCL","orientation":"portrait","color":"true","letterFormat":"A5","borderUnits":"mm","borderTop":"0","borderRight":"0","borderBottom":"0","borderLeft":"0","pageHeight":"","pageWidth":""}]
2023-06-08T09:02:48.744Z:  Printed document 4732165140005524 on \\srvimp01p\60830_UPCL.
2023-06-08T09:02:48.915Z:  Service: Printing document 4732165140005524 failed on 606173990005524. Skipping to next document.
2023-06-08T09:02:48.916Z:  Service: Print error Failed to perform action. Error: PrintedStatus (40166412)
2023-06-08T09:05:26.098Z:  Printed document 4732169820005524 on \\srvimp01p\60830_UPCL.

Note the error at 09:02:48.916 - we don't know what to make of it... What is this error code and where is it coming from ?

There was another print at 09:05:26.098 without an error message.

In both cases, nothing was actually printed. Do you have any ideas of what could be causing the problem, and how to troubleshoot ?

Thanks in advance.

[mgobat]

@dregad, I suspect the problem is the service doesn't have access to the printer. We are using an open-source library to do the printing. Let me see if I can track down the details for this error. Do you have the same problem when running the service as a logged in user rather than the Local System account?

[dregad]

Do you have the same problem when running the service as a logged in user rather than the Local System account?

I did not test this scenario as it is not acceptable under our policy to have a service running under an end-user account, but I can certainly try it out for the sake of troubleshooting.

I'll get back to you with the results ASAP.

[dregad]

I suspect the problem is the service doesn't have access to the printer.

This is certainly a plausible cause. I'm also following up on that with our infrastructure/system team. Will keep you posted.

[mgobat]

@dregad, we appreciate very much your willingness to test the other service scenario. If the logged in user scenario works, we may need to engage your IT staff to learn how to make the printers accessible to the "Local System account". Meanwhile, I will continue to research the root cause of the error.

[dregad]

Thanks.

FYI, I'm also investigating the possibility of using another service account, but according to my colleagues (if I understood correctly what they told me) there are some technical restrictions on those, one of which is the absence of a local profile which may prevent this from being an option (unless #44 is fixed).

[dregad]

@mgobat I apologize for the delay

Do you have the same problem when running the service as a logged in user rather than the Local System account?

We have now tested this.

If the NSSM service for the print daemon runs under a regular user account instead of the SYSTEM account, then printing works normally.

This confirms your suspicion that the SYSTEM account can't access the printer.

I am now following up with our Windows sysadmins, to see if a dedicated service account with access to the printers can be used instead of SYSTEM to run the print daemon service. I'll keep you posted.

[mgobat]

@dregad, thanks for the update. I'm glad you were able to determine that the SYSTEM account is the issue.

[dregad]

To clarify, after further testing and investigation, I now believe that the problem is not with the SYSTEM account itself, but rather due to the fact that the printers were installed on the server over a RDP connection, so they are actually configured for the connected user's session only, and not as a local resource on the server itself.

Working with our sysadmin team to try and find a solution to have printers installed on the server so they are available both to local and (all) RDP users.

[dregad]

As mentioned in #44 (comment), we are still facing the issue with shared printers setup.

So far the only workaround we have is running the APD as a service under an end-user account (against corporate security policy). I'll be resuming tests for that soon, will keep you posted.