Knowledgebase: PaperCut > Administration
Is Cross-Server Redirection Possible Without Local Administrator Rights?
Last modified on 12 August 2020 02:13 PM

One of the requirements for enabling cross-server job redirection in a Windows printing environment involves setting up a domain user service account especially for PaperCut’s use. The PaperCut Print Provider service on each Windows print server is then configured to run using this service account, and the service account is given network level permissions to print to the printers hosted by these servers. This way, no matter which instance of the Print Provider needs to redirect a print job to another server’s queue, it will have the required rights to do so.

Normally, the PaperCut Print Provider service runs under the SYSTEM account, which allows it to interact with the local Windows printing subsystem to the full extent required for proper functioning. To maintain this level of access when configuring cross-server redirection, we strongly recommend that the service account is granted local administrator rights to the server; this is the only way to absolutely ensure that the Print Provider can perform every action required of it!

However, some users have encountered specific circumstances which make it difficult to grant the service account local administrator access. For example, one such deployment needed to deploy PaperCut to their Domain Controller. We would always recommend that a new server or virtual machine be provisioned for PaperCut as opposed to having it share a host with a Domain Controller, but in this instance, putting in a new server was a path of higher resistance.

Depending on the version of Windows used, Domain Controllers are unable to grant domain users local administrator rights. Hence, their service account was unable to be provided the access the Print Provider required to function normally within their environment…

However! They were able to workaround this limitation by instead creating a domain user in the “Print Operators” group. In their own testing, this user was able to be employed as a service account for the Print Provider, proving to have sufficient access to both the local printing subsystem, and the remotely hosted print queues.

Whilst we cannot guarantee this level of access will prove sufficient for other deployments, and would suggest that an account with local administrator rights always be the foremost consideration, we did feel that this solution was an excellent find, and well worth documenting!