alanmorris

One last note, when you have any problems with Windows Point and Print, then it is time to switch to PaperCut Mobility Print. You may find Windows authentication does not work for shared queues. If you need advanced finishing options for Mobility queues, then PaperCut Print Deploy can deliver vendor drivers with the Mobility queues.

I think one challenge for most locations that have had PaperCut for years with AD / On premise printing is that now they have new names for the same people, and these new strings, it is just a string to PaperCut, do not match to the name in Azure. Locations new to PaperCut with Azure do not have the AD print baggage where the old names are either not in use any longer or still in use by Windows. For print job tracking, the default method is to use the name the Windows print system reports as the job owner. What I have seen with Azure joined machines is that the Windows job owner is NOT the name which is Azure. At device authentication is for alanmorris but Windows tracks the job as alanmo. PaperCut aliasing can track job created by multiple Windows Owners back to one user in PaperCut. People have been using this method for the past 15 years in locations where there are a mix of MacOS and Windows. Print Deploy can also be used to track the job to a different string than the one Windows provides as the job Owner. It all depends on what works best for your situation. I definitely know there have been a few locations which have torched all the AD usernames moving to Azure so the AD strings no longer exist in PaperCut and they track new jobs using the strings from Azure and set up Azure as the authentication authority for users logging onto devices. Thanks

Hi @Danny11717, An upgrade of the PaperCut application service has no impact of the version of Mobility Print. The two services are independent. Did the operating system also receive an update? Mobility Print runs a utility to determine what paper sizes the driver, and thus any printer using that driver, will support. We then make a nnnnn.printer.toml file located in c:\Program Files (x86)\PaperCut Mobility Print\data\spool\printercapabilities If for some reason we cannot generate a printer.toml file, the printer cannot be published by Mobility Print. Have you added a test version of the virtual queue using that same driver? If you see that appear within 5 minutes, we run the tool every 5 minutes, it is possible the printer registry is corrupted in Windows. I have spent too many hours attempting to track down Windows registry corruption, no PaperCut required. If this is the case, it is time to rebuild the queue and remove the corrupt entry. The printers' Availability time of 4am is a setting PaperCut configures to prevent Windows from scheduling jobs to the Windows nul port used for this queue. Thanks

Are the jobs landing on the print server? The queue view on the Windows machine is a mix of the local view of the spool files and the spool files that are sitting on the server in a Paused status. Make sure you are only reviewing the queue when logged onto the print server. When the files are not copied to the print server, then the expectation is that there will be nothing for PaperCut to monitor and you will not get the account selection dialog. Now the expectation is that Windows will be copying these files to the server so finding out if that occurs is the first task. For connections to shared printers, the client system creates spool files in c:\Windows\System32\spool\SERVERS\ If there are no files here, check Windows PrintService / Admin events on the client system for any rendering failures. Event 372. If there are no failures, then enable the PrintService / Operational logs and see if Windows believes the job was successful, Event 307. If you see event 824 that's not good. https://www.papercut.com/kb/Main/LogPrintJobsInEventViewer/ Thanks

Please check the setupapi.dev.log file. For most driver installs, Windows adds additional logging. C:\windows\inf\setupapi.dev.log Thanks

@Jaan , to answer this specific question: Anybody else seen this behaviour? Yes, I have seen this behavior since 2011 with the first Windows 8 / Server 2012 preview builds. It's been the design for the past 12 years. With Type 4 print drivers, software is delivered to the client system using Windows Update and never the print server. I have seen the WU path not working recently so I am guessing that Microsoft broke the behavior or "designed" the behavior so it's not longer working. Thanks

@Jaan, this is by Microsoft design. The driver used on the client system when you set up a shared printer using a Type 4 print driver will never be copied from the server. We discuss this behavior in this article. https://www.papercut.com/kb/Main/WindowsType4PrintDrivers/ [h=3]Type 4 drivers on the print server are never downloaded to the clients[/h]This is by design and expected. When the Type 4 driver used on the server does not exist on the client system, Windows will use the client’s preinstalled “Microsoft enhanced Point and Print compatibility driver” to build the connection to the shared printer. This driver may not have the same feature set as the Type-4 driver that is on the queue on the server.

Hi @mmoseley, PaperCut Print Deploy does not support Universal Print printers but Microsoft will handle adding the UP printers using Intune. If the UP printers are hosted and tracked by PaperCut, then we will handle the jobs when we copy and print the PDF file from Azure. Do not forget, Microsoft requires administrative access on the client system in order to install and update Type 3 print drivers shared from a print server. There is a Windows policy to allow Standard users the ability to get this software from the server. You need to make the call on the policy when the users on the client system is not admin on the machine. If the Azure printers are not being tracked by PaperCut, then the PaperCut Direct Print Monitor software will track jobs sent to UP printers but the Direct Print Monitor software can't be the version installed with Print Deploy. I've thrown in some what ifs but the main answer to the question, does Print Deploy handle deployment of UP hosted printers then that is a no. Thanks

Super. I'm glad that worked out in your environment.

Hi IT_Man_Dan, Maybe it's time to use a print driver for the shared printer which does not install from the Print Server is in order. If the print server is 2012 or greater, you can use a Type 4 driver for the share. In this case Microsoft will set up the connection using the basic Microsoft compatibility driver. No dlls are copied from the print server. I expect connections to the shares to work as expected. On the client system, if the driver files on the server are different than those on the client, they can be mismatched even though you added the connection as an admin previously, check on the client in the C:\windows\inf\setupapi.dev.log file. If there is some file that is different on the client, the setupapi.dev.log file should indicate this.

@Sonic007, A connection to a shared printer is only added in a user's security context. For "computer" connections ALL users who log onto a computer should receive the printer as long as they are admins or you configure the policy to allow the software installation by standard users. For "user" printers, the printer will be added for the user no matter what machine they log onto as long as they are admins or you configure the policy to allow the software installation by standard users.

Hi, The new default to install the software from the server, you know this as the print driver, requires administrative access on the client system. Microsoft does have a policy if you which to revert this behavior to good old 2020 days. Microsoft documents the policy in this KB. https://support.microsoft.com/en-gb/topic/kb5005652-manage-new-point-and-print-default-driver-installation-behavior-cve-2021-34481-873642bf-2634-49c5-a23b-6d8e9a302872 To allow non admins to install the software you would need to disable this policy or set the registry value to 0 [h=2]Set RestrictDriverInstallationToAdministrators using Group Policy[/h]After installing updates released October 12, 2021 or later, you can also set RestrictDriverInstallationToAdministrators using a Group Policy, using the following instructions: Open the group policy editor tool and go to Computer Configuration > Administrative Templates > Printers. Set the Limits print driver installation to Administrators setting to "Enabled". This will set the registry value of RestrictDriverInstallationToAdministrators to 1.

Hi, Do you know if the update had any impact on the new protocol requirement from Microsoft for Windows to Windows printing? The behavior in some cases is that the Windows clients can no longer copy the spool file to the print server. I guess the question is, had you disabled the protocol prior to the update? It's registry setting so you would if someone added the key for the protocol in order to disable it. In January of 2021, Microsoft added a security protocol requirement in order to connect to shared printers. This protocol was disabled by default and if one wanted to enabled the protocol, you followed Microsoft guidance here: https://support.microsoft.com/en-us/topic/managing-deployment-of-printer-rpc-binding-changes-for-cve-2021-1678-kb4599464-12a69652-30b9-3d61-d9f7-7201623a8b25 Microsoft turned on this protocol in September 2021 with unintended behavior by some version of Windows. The intention of the protocol is to block non Windows connections to shared printers and create a more secure connection when the client system is Windows. Take a look for this registry setting on your print server. If it is not there, then you may wish to add the setting with a value of 0. This reverts the protocol to the behavior prior to September 2021. At PaperCut, we have lots of people with Macs connecting to Windows and suggest the setting. We list the solution on a couple links to Known Issues. https://www.papercut.com/support/known-issues/#mf Add a new registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\RpcAuthnLevelPrivacyEnabled (type DWORD) Set the new key value to 0. Restart the Print Spooler service. This should allow Windows clients and macOS clients to print to the Windows Print Server, as before. If by chance, the application on the client system hangs when submitting the job, the file is also not copied to the print server, I worked on an issue and Microsoft suggested disabling the protocol on the client systems which got them printing again. Thanks

No, PaperCut Print Deploy is not the same as Microsoft's Universal Print. PaperCut Print Deploy is used to install local printers on client systems as well as printers which send files to PaperCut Mobility Print. Mobility Print is the PaperCut feature to use when you get tired of dealing with the new default requirements from Microsoft and decide to dump Windows Point and Print

@woreilly I have no guidance with regard to deploying a UP printer using Intune. The requirement for account selection will be challenge and will work best when you have printers that support account selection on the device. This configuration works for Mobility Printers as well. With Universal Print, the clients can print from anywhere. We do not retain any IP address data since this can be Starbucks and not relevant to the local users. The new default from Microsoft when adding a connection to a Windows shared printer is that the client user MUST be local administrator or have administrative credentials to install the software from the print server. This is now a Microsoft default. It is configurable if you have solid control of the software you added to the print server. You know this as a print driver. For decades, the Windows print server has acted as a software distribution center with policies to notify the users that they were downloading software to their systems. As you point out with the guidance to install connections using PowerShell, turning OFF all that protection is the driving factor in the new administrative default from Microsoft. You can allow user access to installing all that software, Microsoft publishes the registry setting for this configuration, if that is the way you would rather go. PaperCut links to the Microsoft configurations on our Known Issues page if you wanted to review our thoughts on the topic. Here is the MS information we link to. https://support.microsoft.com/en-gb/topic/kb5005652-manage-new-point-and-print-default-driver-installation-behavior-cve-2021-34481-873642bf-2634-49c5-a23b-6d8e9a302872 Thanks