Troubleshooting jobs attributed to the wrong user or wrong owner name

“Help! I’m a PaperCut administrator and users are reporting that they don’t see any print jobs to release (because they are associated with the wrong user account), or jobs have printed but they were logged/tracked as printed by the wrong user. What should we check?” This article dives into some possible reasons for the job printing successfully, but it gets tracked or recorded in the job log under the wrong username. It can also mean that a user can’t release ‘their’ jobs, since the job is held under a different username. Related articles: Troubleshooting missing or disappearing print jobs Print jobs are not being tracked by PaperCut How does PaperCut find out who printed the document? First, let’s understand how PaperCut figures out who printed what in the first place. To do so, PaperCut pauses the print job as it passes through the system to determine who the ‘Owner’ is. You can see who the job owner is yourself on your Windows print server by pausing the printer, and looking at the queue: Normally the username tracked in PaperCut will match the print job ‘owner’ name seen in the queue at the OS level - which will also normally match the username of the user logged into the OS at the time of printing. For example in the screenshot above, you’d normally see that if you logged into Windows as the user ‘tim’ and then sent a print job. What normally determines the job owner? This is the user, system, or process that submitted the print job to the Print Spooler. For example: On a domain-joined Windows computer, this is generally going to be the logged-in user. On a WORKGROUP (non-domain-joined) computer, this will reflect the user credentials used to create the printer connection. When a server or system process is submitting a print job, the job owner could even be SYSTEM or whatever service account that service is running as. What kind of behavior are you experiencing? Are users printing from a shared computer? Is unauthenticated printing already enabled, but the wrong username is cached? Is this a WORKGROUP computer? Is the job name ‘Local Downlevel Document’ or ‘Remote Downlevel Document’? Is the Print Job coming from a SAP or UNIX server? Does this only happen when printing through Google Cloud Print (GCP)? Is the job being printed through Mobility Print with the Canon driver? Is the job owner recorded as ComputerName$? Are users printing from a shared computer? Are users logging into a shared workstation, lab computer, or public kiosk all users happen to be signed into the operating system with the same credentials? If so, all jobs may be owned by the shared account logged into the computer - e.g. ‘lab1’ or ‘lobby-guest’ etc. The solution is to run the PaperCut Client on the shared workstation and then configure the guest user account or printer in PaperCut for Unauthenticated Printing. When you do this, PaperCut will send an authentication pop-up to that workstation to figure out who’s really doing the printing. Then the user just needs to sign into the client with their PaperCut username. This will let PaperCut identify who is doing the printing, even when all the users are log in to the workstation with the same user account. Is Unauthenticated Printing already enabled, but the wrong username is cached? If you’re using unauthenticated printing with pop up authentication, but you’re getting all jobs appearing from the same user and it’s not asking each user to authenticate, take a read through the Why is my username saved? article. It has a lot of handy info on where PaperCut saves usernames. If you do indeed find that the credentials are being saved in this way, follow the advice in that article to clear these, and then re-authenticate with the correct account when you send a further job. Is this a WORKGROUP computer? The user brings in their own laptop and wants to get connected to the print server. ‘No big deal’ the admin says, I’ll just browse to the trusty printer share, \\printserver\, and double-click on the print queue to get it installed. When prompted for credentials, the admin types in their own username and password but doesn’t think too much about it. Later, when these jobs are tracked in PaperCut, the job owner is the user account of the administrator instead of the end-user. Doh! How can you be sure this is the problem? From the user’s workstation right click on the printer and choose “See what’s printing”, then try to print a test page. In the animated example below, you’ll see the Owner for the print job is the same as the username for the Workgroup computer. Then a second job spools with the same document name but a different owner! To fix this remove and re-add the printer or clear the cached credentials for this printer using the Windows credential manager. To remove previously cached/saved credentials on your workstation using the Windows Credential Manager under Windows 10 (might be slightly different on other OS versions), perform the following steps: Press the Windows key on the keyboard or click the Windows Start icon. Start typing Credential Manager, and select the Credential Manager icon. On the resulting screen you will see the choice to manage your Web Credentials or you Windows Credentials. Delete any credentials under the ‘Windows Credentials’ grouping that refer to ‘servername’ (or whatever your print server name is). To do this, click on the down arrow associated with the saved credentials and if you see an entry with ‘servername’ and admin, choose the option to ‘Remove’. The next time you print, you will probably be prompted to enter valid credentials - whatever you enter here will impact the job owner name when the job arrives on the print server. Make sure this user account is valid for the print server and is unique to the user. Alternatively, if this user doesn’t have a domain user account (and you’d rather not create one) then we recommend setting up PaperCut Mobility Print to share printer connections with BYOD users. Simply Install Mobility Print on your print server, and follow the prompts to get users connected post-haste. Is the job name ‘Local Downlevel Document’ or ‘Remote Downlevel Document’? When the document name is ‘local downlevel document’ or ‘remote downlevel document’ this suggests the job was printed via a command line or batch script with a command like copy document.pdf \\servername\printername. There’s more information for troubleshooting that on the Remote Downlevel Document article. Usually the job owner for one of these documents will be the service account that the script or application is running as, commonly ‘SYSTEM’ or an administrator account. Is the Print Job coming from a SAP or UNIX server? Like the scenario above, the job owner for these print jobs could be logged as Administrator - or as the service-account that the application is using. The somewhat-advanced solution here would be to leverage a PaperCut feature called Extract usernames in enterprise print environments (e.g. SAP, Unix) to attribute these print jobs to individual users. This assumes that your SAP/Unix/Other printing system has the ability to write the username into spool files as a PJL Header. As a real world example - suppose you have a payroll system that always prints jobs as the owner ‘payroll’, but you really want these to be owned by the person initiating the job. In most SAP/enterprise systems, there is a way to configure the print jobs so that even though the jobs are still owned by ‘payroll’ at the O/S level, the username of the actual user can be embedded within the job information (the spool file). That part is outside of the scope of this since it will depend on exactly what system you’re using, and whether it can do that or not. Once you have that working, you can use the link above to configure PaperCut to then extract that same username which was embedded with the job. Result? In PaperCut, your payroll jobs go from being tracked under ‘payroll’ to being tracked under ‘chris’ or ‘alex’. Does this only happen when printing through Google Cloud Print (GCP)? Note: If it’s going to take you time to try and troubleshoot this, with Google decommissioning GCP this year, it’s worth looking at our Mobility Print feature as an alternative.If that’s not an option, then read on! If the Google Cloud Print printers are actually being published through the Chrome browser, or if you’ve installed the Google Cloud Print Connector to publish your print queues, there isn’t a way for PaperCut to see who the actual owner of that job is. The reason is that all of the jobs from Google Cloud Print will be charged to whichever service account that the Google Cloud Print Connector is running as (usually SYSTEM) or whichever user shared the printers through the Chrome browser. We really recommend unpublishing those, and/or uninstalling the connector - and then Publishing your Google Cloud Print printers through PaperCut. It’s also worth reviewing the ‘What do I check if the GCP jobs are logged as the wrong user?’ section, from our Debugging GCP Issues article, which has troubleshooting steps for this scenario. Is the job being printed through Mobility Print or Universal Print by Microsoft with the Canon driver? If so, there’s some information on why the username can sometimes get set to ‘SYSTEM’ on the Canon System Username when printing page. Is the job owner recorded as ComputerName$? We’ve seen in rare and fleeting cases that sometimes the print job Owner is recorded as ComputerName$ (ComputerName being the name of the Windows machine). We believe this happens if a Windows Print server is temporarily offline when users send print jobs. Thankfully this condition is a bit like lightning in that it rarely strikes the same spot twice, but if you’re curious you can check out our article: Job owner is ComputerName$. Still have questions? Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.