Job Owner "System"

Copper Contributor

Hello There,


When passing through the PrintConnectorApp to a local printer, the username is passing through as "System"


Is there any way to change this to correct username?

16 Replies
I got the username to pass through, initaly thought it was down to selecting"Print directly to printer" on the local queue, But cant replicate it now.
After a reboot of the spooler/print connector service its back to SYSTEM
best response confirmed by Saurabh_Bansal (Microsoft)
Sorted, the machine needs to be joined to the local AD

@ManagedPrintMax   Thanks for the update

@ManagedPrintMax Could you please clearify if the end users device has to be joined to the local AD or just the machine that has the connecter installed?

@SimonHessBZPI havent tested, but I would expect only the machine with the connector installed.

@SimonHessBZP For the username to be associated with the print job on a Connector, you would need to have an AAD/AD Hybrid configuration, and the Connector server would need to be AD and AAD joined. Provided everything is set up correctly in regard to AAD/AD, the Connector will try to impersonate the user by converting the AAD UPN used to submit the job to UP to the associated on-prem AD account and submit the job to the spooler and the print queue using that user's name. 



@Philip_Demaree   Thank you for this information.


I hope all is well.



Hi Phil,


Is there any desire to change this so an AAD joined machine can pass the UP through to the spooler? We use papercut and need the names passed through for follow me printing. It works currently as the connector is domain joined. We are trying to go full cloud and printing is one of the main things holding us back. Kind of defeats the purpose of cloud print when we need a connector to be domain joined.

@DonzaMac Based on my understanding, the issue is that Windows as an operating system still only understands Kerberos (AD) validation, so the Spooler needs to be provided the AD user account associated with the AAD account. Papercut should be able to use the AD account as this is how the legacy Windows Point and Print works. The tricky part is having your AAD/AD Hybrid environment configured correctly so that the association between the AAD account that UP uses and the AD account that Windows uses succeeds. 


The Dev team is currently working on how to address this moving forward in regard to a server-less environment that would be AAD-only. Part of this is that the printers themselves need to be able to connect to AAD as AAD-joined devices. The Connector is part of the transition to allow legacy printers to communicate with Universal Print. 



I made sure my Print Server (Server 2019) is hybrid (local AD domain joined & AAD joined)

Also using Papercut.

But all jobs sent to local printers (physical or virtual queue) are SYSTEM owned, hence no user can actually release them.

It worked fine with one early version of connector (0.30.??????)

Never again. Means nobody can print!

"Print directly to printer" on the local queue, is NOT possible for virtual queue that holds the jobs till user releases is!


End user devices are ONLY AAD joined

AAD is SYNCED from local AD, so the whoami always shows the user as it it were AD logged in - MYDOMAIN\myusername

@Sebastian Cerazy 



@Alan Morris 


The 'system' user name is currently expected behavior. Please see that topic in the troubleshooting guide:


Then the design is wrong if that is expected!

@Sebastian cerazy - Universal Print connector provides base level functionality to let printers talk to Universal Print.


Partners like PaperCut (that you use) implement advanced functionality on top of Universal Print and use additional attributes like USERNAME. They have built integrations such that you can replace Universal Print connector with a their (PaperCut) connector or equivalent. Check out following link for more detail:


Let us know if connector from PaperCut meets your expectations.






Sadly Papercut own connector does not work at all with Sharp drivers.

And I do not have the time to be they tester

@Sebastian cerazy 


Thanks for giving our preview connector a try!
We're currently working on driver attribute bugs with a few manufacturers as we're getting more preview feedback from customers.
In the mean time, have you tired the Global Postscript Driver driver with your Sharp devices? I'm curious to know which specific Sharp models and drivers you're working with, so our team can take a more detailed look.
1 best response

Accepted Solutions
best response confirmed by Saurabh_Bansal (Microsoft)
Sorted, the machine needs to be joined to the local AD

View solution in original post