Skip to main content

Just this week, we are noticing that many Macs, but not all of them, are not able to print via our Windows print server. Nothing has changed on our Mac side.
We are printing via PaperCut, so using SMB on a printer installed via JAMF and no changes to the setup.
Macs not joined to the domain and not using the AD Username as the machine or profile name in many cases, but likely in many others.
I can add PaperCut LPD to the print server and print via LPD - but no authentication, so the job gets stuck with no way to get it to print from Papercut, unless the users profile on the Mac is named the same as their AD username.

The issue looks very similar to this one:
https://community.jamf.com/t5/jamf-pro/mac-printing-issue-after-microsoft-windows-print-server-update/m-p/246842
However, we don't have the server updates referenced in the thread or PaperCut advisory.

Affected systems are running Monterey, Big Sur, and Catalina.
One Mac that was able to print, stopped printing immediately after upgrading from 12.1 to 12.2.
One Mac on 11.6.0 was printing yesterday, but stopped printing today. JAMF shows "ProfileList" updated just before it stopped working.
This is happening on both our Prod and Dev instances of JAMF.

Workarounds

I am able to set any Mac up to print straight to the printer using LPD protocol and the printer IP address with the correct driver.

If the user profile on the Mac is named after the AD profile, then I can use LPD to print to Papercut on the print server (after loading the PaperCut LPD service). Address: (IP or FQDN of print server), Queue: (PaperCut Printer Name).

My coworkers think it is JAMF "JAMF-ing up the Macs". But I can't see anything on the JAMF side that has done anything to the Macs, and no changes to printing have happened lately.

For those seeing issues with slow print jobs before or after macOS changes for smb printing, recommend turning off SMB Multichannel on Windows Server: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn610980(v=ws.11)#disable-smb-multichannel

This is a better solution for macOS clients, especially if that server is only hosting smb print queues and it's not being used for smb file shares.

 


@davidhiggs wrote:

For those seeing issues with slow print jobs before or after macOS changes for smb printing, recommend turning off SMB Multichannel on Windows Server: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn610980(v=ws.11)#disable-smb-multichannel

This is a better solution for macOS clients, especially if that server is only hosting smb print queues and it's not being used for smb file shares.

 

Last month we turned off SMB Multichannel on our Windows print servers, so print jobs not only on managed Macs are processed quickly (again). Thanks for the hint!

I have recreated the printer on my Mac, added it to JAMF and replaced the self service policy printer with the new one I just created that has the FQDN and ?encryption=no. But now I see a new problem.

The Mac I created the new printer on, then uploaded to JAMF (freshly imaged) will print a document in about 4 seconds. But the Macs I added the printer to via Self Service take about 50 seconds to print the same test page.


@VintageMacGuy - seeing the exact same thing for the Ricoh SMB printers here!

Our first print job goes right through, and all subsequent print jobs take ~45-60 seconds.  Makes no sense. 

Made two different printers - one normal, one I turned off encryption.  I'm at a loss as how to fix this...

Printers in Self Service seem to have this behavior.  If I make them programmatically and then wrap in a .pkg, they work fine ¯\\_(ツ)_/¯ 

Incase people missed it: our print provider advised encryption=no basically un-obfuscates the username of the job. Which is how printing has operated for decades.

Password is still encrypted.

I've tried every combination offered up here with no luck. The Print Server is on 2019, the desktops are all on Monterey. Our Macs are not in AD, just using Kerberos for authentication. It fails by asking for authentication. It should not require authentication to the Print Server. That doesn't matter anyhow since entering the information still doesn't allow a print. It will sit there in the local queue with "ready to print" and paused. I've had to move people over to direct printing just so they can kill trees. 

Open to more suggestions.

Bob 

UNCC


The script I wrote and posted months ago is working in our environment for smb printing.

it basically checks version of MacOS and adds the printer via command line.

Ignore? I found out my customer has different spool that has the same printers installed. They did some maintenance on it last week and the other spool works without encryption=no and just with ad username and password. Happy days!


Sorry I missed your reply.
One year later - still an issue. I'm curious what kind of maintenance they did?
We still need this:
Add ?encryption=no

Set: AuthInfoRequired negotiate (for Kerberos)
Disable SMB multichannel
Don't use UPN for login (!?) 

We came up with a solution using LPD that seems to work when SMB did not. So picky with drivers!!!

 

Bob

I have noticed with our printing system that this problem reappears with macOS 14.0rc (23A339) and can be solved as described.

Terms & ConditionsCookie settings