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 know who printed the document?

PaperCut figures out who printed a document by checking the Owner of the print job as it moves through the print spooler.

On a Windows print server, you can see this yourself:

1. Pause the printer.
2. Check the queue to see the Owner of the job.

In the example screenshot, the print job owner is “tim”. If you navigated to the Job Log in PaperCut (Logs > Job Log) and found this particular print job, you would see “tim” listed as the user associated with the print job.

The exemption to this would be if you were printing via one of our BYOD Print enablement solutions, such as Mobility Print, Web Print, Email to Print, etc. In those cases the job owner on the operating system might be “SYSTEM” or the username that the service is running as.

What determines the job owner?

The job owner is the user, system, or process that sent the print job to the Print Spooler. Here’s how it’s usually decided:

• On a domain-joined Windows computer – The job owner is typically the logged-in user.
• On a WORKGROUP (non-domain-joined) computer – It’s the user credentials used to set up the printer connection.
• When a server or system process submits a job – The owner could be SYSTEM or the service account running the process.

Which scenario describes your issue best?

• 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?
• 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 . Here’s a rough overview:

1. Configure the shared user account or printer in PaperCut for Unauthenticated Printing.
2. When a user prints, PaperCut will pop up an authentication prompt.
3. The user enters their PaperCut username, so PaperCut can track the job to the right person.

This ensures PaperCut knows who’s actually printing, even if everyone is using the same login.

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 explains where the PaperCut User Client stores usernames and how to clear them.

If credentials are being saved, follow the steps in that article to remove them. Then, the next time a user prints, they can re-authenticate with the correct account.

Is this a WORKGROUP computer?

A user brings their own laptop and wants to connect to the print server. No big deal, right? The admin browses to the printer share (\\printserver\), double-clicks the print queue, and installs it. When prompted, they enter their own credentials—without thinking much of it.

Later, when checking PaperCut, all the user’s jobs are tracked under the admin’s account. Oh no!

To check for this issue:

1. On the user’s computer, right-click the printer and select See what’s printing.
2. Print a test page.
3. Check the Owner column in the print queue. If it shows the admin’s username instead of the user’s, you’ve found the problem.

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:

1. Press the Windows key on the keyboard or click the Windows Start icon.

2. Start typing Credential Manager, and select the Credential Manager icon.

3. On the resulting screen you will see the choice to manage your Web Credentials or you Windows Credentials.

4. 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’.

   

5. The next time the user prints, they’ll be prompted to enter credentials. Make sure they enter their own username—this will ensure their jobs are tracked correctly.

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’?

If you see ‘Local Downlevel Document’ or ‘Remote Downlevel Document’ as the job name, it likely means the job was printed using a command line or batch script—something like:

copy document.pdf \\servername\printername

In these cases, the job owner is usually the service account running the script or application—often SYSTEM or an administrator account.

For more details and troubleshooting steps, check out the Remote Downlevel Document article.

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 enterprise application is using.

To correctly attribute jobs to individual users, you can use Extract usernames in enterprise print environments ** ** (e.g., SAP, Unix). This works if your printing system can embed the username in spool files as a PJL Header.

As a real world example - imagine 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’.

Is the job being printed through Mobility Print or Microsoft Universal Print with a 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.