Shared printer not processing jobs for non-admin users

[lravelo]

so I've installed the printer as documented in the wiki and it works if the user sending the print job is an admin. any print jobs sent by regular users errors out on the client machine and don't generate any logs on the print server. Not seeing any documentation here on any troubleshooting steps so not sure where to look.

[lravelo]

Tried this with both a local account on the print server as well as a domain account (neither of which have admin privileges) and the end result is the same.

[lravelo]

@lravelo Unfortunately, I cannot reproduce this behavior. Have you tried to connect the shared printer manually under the Non Admin User?

yes I have. the printer installs just fine if I install it as a shared printer (i.e., specifying in the \server\printer format) but once I go to print, anything sent to it from a non-admin account immediately errors out. nothing is sent to the print server so there are no logs generated on that side.

the one thing I do see in the event viewer, however, is a DistributedCOM Event ID 10016 warning any time I sent any sort of print job.

[clawsoftware]

@lravelo Can you please enable print logging on a client and let me know the possible error output.

https://www.manageengine.com/products/active-directory-audit/how-to/how-to-check-print-server-logs.html
https://www.papercut.com/kb/Main/LogPrintJobsInEventViewer

[lravelo]

@lravelo Can you please enable print logging on a client and let me know the possible error output.

https://www.manageengine.com/products/active-directory-audit/how-to/how-to-check-print-server-logs.html https://www.papercut.com/kb/Main/LogPrintJobsInEventViewer

so just did another test print and there are no error messages in that printservice operational log. log basically says that the print job went through successfully. that DCOM 10016 error message still pops up any time I attempt to print to that shared printer. Let me try switching the printer back to a domain account instead of the local user I created and check to see if the logs show something different.

EDIT: can confirm that the behavior is identical regardless if using a local account on the print server or using a domain account.

[clawsoftware]

@lravelo Thx. What server and client version are you using and is the client x86 or x64? I will set up a new test environment.

[lravelo]

@clawsoftware the server is Windows Server 2019 Version 1809. Client machine is a test Windows 10 x64 Build 21H1 virtual machine

[ft3pierce]

i am getting the same issue, I am using a windows 2019 server system as network print server. I think it is a permissions issue on the server it self. i have tried giving the non-admin user full permissions on the printer and in the clawpdf directory in the program files (x86) directory, but that made no difference.

[ft3pierce]

i get this in the printservice logs "The document Print Document, owned by XXXX, failed to print on printer pdfcreator. Try to print the document again, or restart the print spooler.
Data type: NT EMF 1.008. Size of the spool file in bytes: 6784340. Number of bytes printed: 0. Total number of pages in the document: 1. Number of pages printed: 0. Client computer: XXXXX. Win32 error code returned by the print processor: 1006. The volume for a file has been externally altered so that the opened file is no longer valid.

[clawsoftware]

@ft3pierce @lravelo The client and print server are in the same domain and the printing user is also a domain user in the same domain?

[lravelo]

yes same domain. as mentioned as well I created a local user on the print server itself and that didn't work either. I'm working on enabling the print logging to get more info.

[ft3pierce]

yes, same domain

[ft3pierce]

client is x64

[ft3pierce]

client is windows 11

[clawsoftware]

@ft3pierce @lravelo Ok, thx. My print server is Windows 2022, I will configure a Windows 2019 Server and test it. Have you made any hardening regarding the PrintNightmare vulnerability that is causing the problem? Do other shared printers work on the print server?

[lravelo]

@ft3pierce @lravelo Ok, thx. My print server is Windows 2022, I will configure a Windows 2019 Server and test it. Have you made any hardening regarding the PrintNightmare vulnerability that is causing the problem? Do other shared printers work on the print server?

I do have the point and print restrictions GPO configured for all of my endpoints.
These are the items configured there:

• Users can only point and print to these servers = Enabled
• Enter fully qualified server names seperated by semicolons = (my print server name is listed here)
• Users can only point and print to machines in their forest = Disabled

Security Prompts

• When installing drivers for a new connection = Do not show warning or elevation prompt
• When updating drivers for an existing connection = Show warning and elevation prompt

All my other printers have installed fine with this config

[ft3pierce]

other shared printers work fine

[ft3pierce]

i have done a test and made it work, this is what i did

non admin user could not print to networked shared klawpdf
until i did this

step 1 - i put the non admin user into the domain admins group and then logged in to the windows 11 system and printed a test page
this printed. (as expected)
step 2 - logged out of windows 11 system and then removed the user from domain admins group
step3 - logged back into window 11 system and printed test page.
this printed

hope this helps

[clawsoftware]

Since I can't reproduce the problem yet, it would be interesting to know if it's enough that the user is temporarily added to the Local Computer Administrators group instead of Domain Administrators.

[ft3pierce]

do you local admin group on print server? my print server is also a domain controller, so it does not have a local admins group, hence why i added to domain admins group. adding to local admins group on end point system had no effect.

[lravelo]

Since I can't reproduce the problem yet, it would be interesting to know if it's enough that the user is temporarily added to the Local Computer Administrators group instead of Domain Administrators.

I just did this test and it still had the same issue.

[ft3pierce]

did it work when the user was in the local adminstrators group on the print server?

[lravelo]

did it work when the user was in the local adminstrators group on the print server?

it did not, unfortunately.

[clawsoftware]

Guys I need your help @lravelo @ft3pierce. I have now installed a new test environment and everything works as it should. I have done the following steps:

• Clean Windows 11 and Server 2019 install
• Updated both to last patch level
• Installed AD, DNS, DHCP and Print role on Server 2019.
• Joined Windows 11 to the domain
• Installed clawPDF on the Server 2019 with the domain admin
• Created domain user srv_clawpdf and a test user (both domain users)
• Allowed user srv_clawpdf to log in locally on Server 2019 in the GPO "Defualt Domain Controller Policy".
• Stored srv_clawpdf with clawPDF.Bridge.exe
• Print Profile created in clawPDF with srv_clawpdf and assigned to the printer
• Shared the printer with default settings
• Logged on to Windows 11 with the test user and connected the shared printer (driver was installed with authentication of the local Windows 11 admin)
• Printed a test page with the test user without problems

[clawsoftware]

Yes, my other test environment is a 2022 server with only the print server role in a 2022 domain, as it is best practice to separate the roles. However, since @ft3pierce has all roles on one server, I wanted to test this scenario as well.

[lravelo]

So I've removed everything and started from scratch

• Installed clawpdf 0.92 on my print server using a domain admin account (originally I installed this using the local administrator on the print server)
• I have a domain service account and a test domain account. Neither have domain admin nor local admin privileges in either the print server or my test client device
• I ran the following to enable the network printing clawPDF.Bridge.exe /networkprinter=enable /username=clawpdf-svc /domain=domain.local and entered the credentials
• Created a test profile
• Created a new printer and attached the profile
• Shared the printer via the print management mmc console
• Logged into the test VM with my test user account and installed the printer
• Sent the test print job

Unfortunately the end result is the same.

[lravelo]

also tried to deploy via GPO to the machine itself rather than the user and the result is the same.

[clawsoftware]

@lravelo @ft3pierce I think I have found the problem. This appears only in some cases. I will get back to you as soon as I have created a patch.

[ft3pierce]

ok thanks

[clawsoftware]

@lravelo @ft3pierce Thanks again for your help! It was unfortunately not easy to find the problem, but with the version the issue should hopefully be resolved: https://github.com/clawsoftware/clawPDF/raw/master/src/_MSI/clawPDF_0.9.3_setup.msi

[clawsoftware]

@ft3pierce @lravelo

The driver does not need to be removed from the clients. A manual variant on the print server is:

• uninstall clawPDF
• stop the print spooler
• delete or rename the files "C:\Windows\System32\clawmon.dll" and "C:\Windows\System32\clawmonui.dll
• Start the spooler
• Install clawPDF

Normally the installer did that itself. I am surprised that there are problems.

[lravelo]

So this fixed it for me for at least one end user and my test environment:

• Fully removed clawPDF from my print server
• Stopped and started the print spooler and removed the clawPDF driver from the print server
• Reinstalled clawPDF 0.9.3
• Recreated the profile and printer
• Shared the printer
• Installed the shared printer on end user's machine and sent a test print
• Success

[clawsoftware]

Very good. Sorry for the trouble it has caused.

[lravelo]

Very good. Sorry for the trouble it has caused.

no trouble at all. thank you for creating this product! it has solved a pretty big and long outstanding issue for me.

[clawsoftware]

@lravelo Thanks, I'm glad it is useful. For bugs or feature requests feel free to report.