Mac printing issue after Microsoft Windows print server update - KB5005623

[rcorbin]

After installing KB5005623 on our Windows print server it seems to have broke printing from macOS to our SMB queues. Windows machines seemed unaffected as were macOS clients printing via LPR. We have heard that uninstalling it will restore printing from Macs. But we do have print servers at 50 sites and each would require an uninstall and reboot. If the Windows machines are still printing I'm wondering if there is something that can be done on the Mac side that will allow them to print as well. 

[plarkin]

We had the same problem.  We rolled back KB5005573 which is the update applied yesterday to Windows Server 2016 and now printing works again.

[rcorbin]

Thanks for the reply @plarkin It's odd that many of our windows clients don't seem to be affected. We did a test of rolling back the update on one print server and yes it did get the Macs printing again. But we have 50 sites so we won't be able to roll them all back right away. It requires a restart after the roll back as well and it take a while. For now we have just set up a bunch of direct print queues until we are able to do the rollbacks. 

[plarkin]

Yes, it took about 30 minutes to roll back the update and we had 5 to do.  Not an ideal solution because now we need to keep those servers from updating.

[ccsshelpdesk]

We have also noticed this today, as the server got the latest updates over the weekend from SCCM. its not impacted our windows fleet just the Mac side. Hopefully a tweak from windows side might be possible.

Nice one Microshaft

[craigo]

UPDATE:

We opened a case with Microsoft, submitted requested logs and they confirmed this was a macOS client issue...

"Cause:  This confirmed printing is failing due to an auth failure, as the printer sever installed with 9B determines the level of RPC authentication required on the client side. MacOS does not use the higher level of authentication methods required by Windows Printer Server since 9B.

Based on the ETL, It seems Mac OS client using SMB/RPC printing from MacOS to Windows. If this is the case, the MacOS needs to fix the RPC auth level issue.

From our side, we made a test in our lab:
-Found another printing method of LPR
( https://support.microsoft.com/en-us/topic/how-to-print-to-a-windows-printer-from-a-mac-12e43e7e-0433...)
-Setup local lab to use Windows with LPR.exe to simulate the MacOS client. 
( https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/lpr)
- Local tests shows LPR.exe works fine. This may be a solution for consideration.

*Prerequisites: install LPD service in the print server:"

OR you can reduce the authentication level requirements on your print server. I haven't tried this yet but rather than uninstalling the update you can disable the increased authentication level requirement on your print server via registry key settings.
NOTE: this still leaves your server vulnerable to the issues the security update address, but it allows you to easily switch it back and forth should you need to.

To disable the increased authentication level requirement on your print server, follow these steps:

1. Right-click Start, click Run, type cmd in the Run box, and then press Ctrl+Shift+Enter.

2. At the Administrator command prompt, type regedit and then press Enter.

3. Locate the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print

1. Right-click Print, choose New, and then click DWORD VALUE (32-bit) Value.

2. Type RpcAuthnLevelPrivacyEnabled and then press Enter.

3. Right-click RpcAuthnLevelPrivacyEnabled and then click Modify.

4. In the Value data box, type 0 and then click Ok.

NOTE: You will need to restart your print spooler service, in complex print environments you will need to restart all print related services or restart the server.

Referenced from here:

https://support.microsoft.com/en-us/topic/managing-deployment-of-printer-rpc-binding-changes-for-cve...

You could disable the setting while you implement the LPD service on the print server and change all your macOS client printer setups, then re-enable it again once you've fixed your macOS clients, or hopefully Apple will release a patch to increase the security settings used by macOS to print to windows print queues.

[rcorbin]

Thanks very much for the reply and great information @craigo  We are going to look into that. Much appreciated. 

[cas1831]

Can also attest to having this problem.  Currently running Windows Server 2019, and everything was working until middle of last week (9/15/2021).

I have almost 100 users unable to print, and I tried the fix suggested by craigo, but unfortunately hasn't bore fruit.  Going to keep troubleshooting, but this is an issue that is frustrating and causing real problems, as staff members are starting to get antsy.

On my site we use Server 2019, and use NoMad to connect to it.  The printers are deployed via Jamf Pro, and are mapped via smb://servername.ad.companyname.com/Printer_Name/    Once trying to authenticate a job sent via NoMad, job gets sent and just says, "Connecting to printer"  and nothing happens.

I might need to solve this by circumventing the print server all together, but I don't want to do that as I won't be able to cancel jobs that get stuck in the printer.  I really hope something is released by either Microsoft or Apple, as this issue that started out as a minor nuisance is swiftly becoming a big problem.

[craigo]

Do you have LPD printing enabled on your print servers?

Our testing so far has been successful with LPD printing so we didn't have to make the registry edit and compromise security.

Details on activating LPD are here: https://support.microsoft.com/en-us/topic/how-to-print-to-a-windows-printer-from-a-mac-12e43e7e-0433...

Once LPD is enabled you have to change the Macs print queues to use lpd://servername.ad.companyname.com/Printer_Name instead.

I wrote some code to do this and put it in a policy in Jamf Pro.

[craigo]

Hi @cas1831 

Did you restart your print spooler service after creating the registry key? In complex print environments you will need to restart all print related services or just restart the server if that's easier.

Cheers

CraigO

[craigo]

Incase it's of use to anyone else here's the script I used for changing the URI for our mac print queues.

#!/bin/sh

IFS=$'\n'
oldPrefix="${4}"
newPrefix="${5}"
errors=0

if [ -z ${4} ]
then
oldPrefix="smb"
fi

if [ -z ${5} ]
then
newPrefix="lpd"
fi

# Get a list of print queues
for pq in $(/usr/bin/lpstat -v | /usr/bin/cut -d ' ' -f 3- | /usr/bin/grep "${oldPrefix}://")
do
queue=$(/bin/echo $pq | /usr/bin/cut -d ":" -f 1)
uri=$(/bin/echo $pq | /usr/bin/awk -F ": " '{ print $2 }' | /usr/bin/sed "s/${oldPrefix}/${newPrefix}/")
/bin/echo "New Queue:  /usr/sbin/lpadmin -p ${queue} -v ${uri}"
# Change the URI for the specified print queue
if /usr/sbin/lpadmin -p ${queue} -v ${uri}
then
/bin/echo "Queue updated successfully"
else
/bin/echo "There was an error changing the queue configuration"
errors=1
fi

/bin/echo

done

exit $errors

[hpham]

I have the same issue in our labs.  The issue is with Microsoft LPD/LPR (

Microsoft deprecated LDP service).  Up date LPD/LPR service in the server

will fix the issue.

[craigo]

@hpham can you elaborate more please? What where you using for your print queue device-uri on your Macs, was it smb://server.host.name/sharename or lpd://server.host.name/sharename? What steps did you take to fix it?

[hpham]

Hi Craigo,

Most of the time the problem is on the mac.  Please check if window can print to the same printer.  Some time odd occasion Mac can not print to the windows share printer has the "-" in the share name.  Stop and restart the LPD print service on the print server.

Let try this first:

-update the latest print driver on your mac

- reset/delet all printers on mac

-run on terminal

#!/bin/bash

# This payload-free package will configure a printer with the following options:

# Printer Queue Name:  SOD_printing  ( change to your share queue name)

# Printer Display Name:  Color_Printing

# Printer Address:  lpd://server.local  (your full FDN server address)

# Printer Driver:  /Library/Printers/PPDs/Contents/Resources/VersaLinkC9000.gz    ( your printer driver location/name)

# Printer Sharing:  Disabled

# Remove existing printer queue if one exists.

# /usr/sbin/lpadmin -x SOD_printing

# Add new printer queue with the specified options

/usr/sbin/lpadmin -p "SOD_printing" -L "" -D "Color_Printing" -v "lpd://server.local" -P "/Library/Printers/PPDs/Contents/Resources/VersaLinkC9000.gz" -o "printer-is-shared=false" -E

Let me know if you can map

[hpham]

For our situation, we determined that The issue is with the server LPD service from Microsoft.  We are using Papercut printing system from Xerox.  So we replace Microsoft LPD service with Papercut update LPD service and the issue resolved.  

[craigo]

Thanks @hpham, we don't have a problem printing via lpd it was with printing via smb.

It's interesting you had problems with printing using lpd when I didn't, I'm curious if you're running an older version of windows server? We're running windows server 2019 on our print servers.

Kind Regards

CraigO

[jameson]

I may be a bit late for the party, but first today we saw the issue - propably because we are running little delay on patching before releasing them to windows servers.We use safecom - the ID card pickup. I made the package through Jamf and tried to re-install - but still not work. can any give some advice on this?

[craigo]

Hi @jameson, I'm not familiar with safecom print solutions but I imagine the same principles apply, You'll need to either ...

A) Uninstall the KB5005623 patch from your safecom print server and configure your print server to ignore it so it doesn't reinstall, This option is NOT recommended for security reasons.

or ...
B) Hopefully safecom support LPD printing. Enable LPD printing on your safecom print server and configure your Mac print queues to use LPD instead of SMB. If you're already using LPD you may need to upgrade the version of the LPD service running on your server.

[jameson]

OK - so that LPD is what microsoft officially say should be the solution, as I will never be allowed here to just uninstall this patch from one of our servers

[jameson]

But is LPD still active - can find some articles that it say that this service is depreciated.

If looking at our service on the windows 2016 - it just seems unable to enable this it is all just greyed out

[craigo]

Hi @jameson,

You may need to enable LPD from within the safecom management interface (Sorry not familiar with safecom), we use papercut as well as standard windows server print queues so for our standard servers we added the windows feature for LPD in the control panel, but for our papercut servers we had to enable LPD via the papercut management console.

In regards to LPD being deprecated, yes that is our concern also, does safecom support "AirPrint" ? Thankfully papercut support AirPrint (ipps://) so morning forward we will likely move our Macs to AirPrint.

Hope that helps.

[JCS_Blue]

SMB to Win Print servers is pretty ruined if you want to apply required security, LPD / IPP (via ISS) are installable but kind of deprecated, CUPS is being suggested by vendors (kind of deprecated by Apple but happy via the open source project it was anyway or vendor versions), Wonder has anyone got the Ricoh version working ok and what was involved server side if anything?

[hicksmat]

don't really see the point of moving from SMB to some other legacy solution...... not a long term solution really.

[hansjoerg_watzl]

We are also affected by this problem. (SMB Printing Queue)

Fortunately, we have LDP installed and enabled on the print server. We have now tested a printer with the same printing queue (lpd://server/queue instead of smb://server/queue) and this worked.

Unfortunately there is still a problem. We use local accounts with SSO Kerberos extension. No matter how the local account was named, printing worked in the past with SMB printing queues (it used Kerberos for the domain account).

However, with LDP, it seems that Kerberos is not used anymore, but the LOCAL account is taken. Most users have the same local account name as the domain user. So it works here, as the account matches with the domain user. But the users who have a local account like "John" can't print via LDP now. This is not about the authentication, but only about the assignment of the print job to a domain user.

Is there a way to define a user with the lpadmin command so that the logged in user is not taken?

[craigo]

I'm no expert with SSO but if you have a kerberos ticket then printing to a windows print queue via any URI supported by the server should work so long as the print queue on the Mac is configured to use kerberos.

I'd start by double checking the Macs which are having trouble printing and check the following:

1. The user has a kerberos ticket when trying to print.
user the "/usr/bin/klist" command or look in the "Ticket Viewer.app"

2. The print queue is setup to use kerberos.
Check in http://localhost:631

3. LDP uses a different port than SMB, check your firewalls are not blocking the LPD port.

4. Network access? Are you on the local network or VPN? Can you actually communicate with the print server?

We use the lpadmin command to create out print queues on our Macs with these options for kerberos.

-o printer-op-policy=kerberos -o auth-info-required=none -o printer-error-policy=retry-job

So as an example to add one of our printer queues we would do something like this:

/usr/sbin/lpadmin -p "print_queue_name" -D "Queue Display Name" -L "Location of printer" -E -v lpd://server.fqdn.name/shareName$ -P "/path/to/driver" -o printer-is-shared=false -o printer-op-policy=kerberos -o auth-info-required=none -o printer-error-policy=retry-job

Hope that helps.

[hicksmat]

be careful if you have also applied the new monthly roleup KB5006672 as this re-breaks printing, so you'll need to roll this back as well. anyone know what the future of smb printing to Microsoft shared print queues is? or is that now not possible any more?

[snowfox]

It's dead Jim!

Papercut have an open known issue for broken SMB printing here:

https://www.papercut.com/support/known-issues/?id=PO-522#mf

They give you the option of installing the LPR service:

https://www.papercut.com/kb/Main/LPDLPRwithNGMF

Or they push you towards their Print Deploy and Mobility Print (& cloud print) services.

That's it otherwise uninstall the security patches.

The options at the moment are limited.  Microsoft have washed their hands of it and say Apple need to patch macOS to support the new enhanced secure authentication requirements.

[JCS_Blue]

Yeah, SMB looks a goner and either skipping patches or lowering the security options there aren't going to be good for many. Have seen similar MS guidance. 

Could really do with Apple or JAMF owning this and providing something new but wont hold breath.  IPP/CUPS look best bets to pursue.

[hicksmat]

anyone made any progress on this? I am about to move to LPD printing for my Mac estate, but I was hoping by now MSoft might have fixed this all sufficiently to reinstate SMB printing from Microsoft shared print queues. anyone got any update? thanks

[plarkin]

Good question. Our Apple Systems Engineer told us Apple was aware of the issues and we've been waiting to hear from him.  (Implying that it may be an Apple fix.). But no, we still have our servers set to not update.  Not ideal.

[JCS_Blue]

SMB to LPD turned out to be fairly painless, enable the role on the Windows server and point print mappings to LPD:/ rather than SMB:/

The more concerning part seems to be that most methods have some kind of asterisk against them as deprecated or not recommended. The print Vendors should be doing a much better job in most cases although driverless client printing may be the way it all goes eventually.

[plarkin]

Our printer guy said he had to touch each client to do lpd.  No idea if thats accurate.

Regarding the second part, thats sort of why we're not doing anything yet.  

[JCS_Blue]

We just made the "new" printers available in self service but no reason why you can't push them. 

I get the second part but leaving SMB as is with no patch or the settings lower isn't a great option in some environments.

[plarkin]

We never put printers in Self Service.  I'll have to look into that.

[steepndeep]

We switched over to LPD a few months ago and it's worked great for us...until today. Over the winter break a Windows update (KB5008218) was applied to our Windows Server 2019 Print Server. It caused a number of printing issues with our Windows users so we rolled back the update. However, after doing so, it completely broke LPD printing from Macs. When users try to print, the queue automatically pauses and the job just sits there. Clicking "resume" just repeats the same behavior. If we connect the Macs via IP address, it prints fine. On the print server I have reinstalled LPD services and rebooted. On the clients I have removed the printers, reset the printing system, rebooted and reinstalled printers. No luck! I am lost...

[steepndeep]

Oddly enough, LPD printing started working again today. I don't understand it, but I'll take it!

[VintageMacGuy]

I am experiencing a very similar issue on my Macs, but it is not affecting all of them. I was able to test with four of them where two were having the issue and two were not. One of the ones that did not have the problem started having problems after moving from MacOS 12.1 to 12.2. I was able to resolve the issues on all four Macs by updating to the latest OS and then using the Fully Qualified Domain Name for the print server.

Unfortunately, when I went to add this fix to my Mac so I could build a new printer with JAMF, my Mac would not print at all. I have tried everything I can think of to get it printing through the server, but no luck. The only thing that seems to work is LPD straight to the printer.

[jonifast]

We are seeing the same problem as @VintageMacGuy . As of now it affects only M1 Macs and Updated to 12.2

I can build a new printer with LPD and deploy it through JAMF and the intel MacBooks will be able to print but not my own M1.

[JeffBugbee]

Resolved Issues in macOS 12.3 Beta

• (Beta 2) Resolves an issue using NTLM authentication on SMB print servers that also allow Kerberos.

I tested this out with a 12.3 Beta machine and SMB printing is still broken.

[vogel]

I can confirm that my campus is also having this issue - we can't unpatch the Windows server, nor do we have plans to turn on LPD. We are a Papercut environment using the Windows print server with SMB printers deployed via Jamf. Everything worked dandy before the 12.2 and 11.6.3 updates. Our System Engineer said this was to be fixed in 12.3 Beta but I tested that yesterday and it is still broken.