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.

Mac printing issue after Microsoft Windows print server update - KB5005623

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

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.

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.

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

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-3aba-6ba4-a5b6419b6349)
-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:

Right-click Start, click Run, type cmd in the Run box, and then press Ctrl+Shift+Enter.
At the Administrator command prompt, type regedit and then press Enter.
Locate the following registry subkey:

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Print

Right-click Print, choose New, and then click DWORD VALUE (32-bit) Value.
Type RpcAuthnLevelPrivacyEnabled and then press Enter.
Right-click RpcAuthnLevelPrivacyEnabled and then click Modify.
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-2021-1678-kb4599464-12a69652-30b9-3d61-d9f7-7201623a8b25

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.

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.

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-3aba-6ba4-a5b6419b6349)
-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:

Right-click Start, click Run, type cmd in the Run box, and then press Ctrl+Shift+Enter.
At the Administrator command prompt, type regedit and then press Enter.
Locate the following registry subkey:

HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Print

Right-click Print, choose New, and then click DWORD VALUE (32-bit) Value.
Type RpcAuthnLevelPrivacyEnabled and then press Enter.
Right-click RpcAuthnLevelPrivacyEnabled and then click Modify.
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-2021-1678-kb4599464-12a69652-30b9-3d61-d9f7-7201623a8b25

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.

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

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.

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.

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

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.

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

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.

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.

@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?

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 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?

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.

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

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

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?

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.

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.

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

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

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.

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?

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?

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.

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

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?

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?

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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded