May 06 2020 07:41 AM
May 06 2020 09:32 AM
May 11 2020 02:08 AMSolution
May 13 2020 03:01 PM
@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.
May 28 2020 12:48 AM - edited May 28 2020 12:51 AM
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.
May 28 2020 04:45 PM
@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.
Jul 15 2020 10:25 AM - edited Jul 15 2020 10:30 AM
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
Aug 20 2020 10:41 AM
The 'system' user name is currently expected behavior. Please see that topic in the troubleshooting guide: https://docs.microsoft.com/en-us/universal-print/fundamentals/universal-print-troubleshooting-suppor...
Aug 27 2020 11:50 PM
@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.
Aug 28 2020 02:20 PM
Sadly Papercut own connector does not work at all with Sharp drivers.
And I do not have the time to be they tester
Aug 31 2020 04:58 PM