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.

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

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

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.

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.

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.  

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.

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

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

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

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.

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.

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.

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.

Checkout this fix https://community.jamf.com/t5/jamf-pro/smb-printing-to-windows-print-server-failing-to-connect-to-server/m-p/257697/highlight/true#M238586

Adding the printer with encryption=no is working my Macs for now

We are experiencing the same issue. I found in testing that if you enter your credentials in the format of domain\\account jobs will go through. This only works in the betas, I can confirm this with the most recent beta of 12.3. It doesn’t seem to work with a Kerberos ticket.

I’ve enabled debug logging in cups but, haven’t been able to find anything useful. I can see jobs go through but, not how the username entered gets translated. At one point I did see an escaped version of the credential: DOMAIN\\\\\\\\account in the logs.

We are still deploying the URI modification in the interim.

In 12.3 if you destroy your kerberos ticket, and send your credentials across using domain\\username, it will work. We're still struggling in our environment as well. Prior to that folks could enter just their username and the translation would happen.

We still seem to have "RpcAuthnLevelPrivacyEnabled = 0" required on our windows print servers. 
Anyone have SMB kerberos printing working without it?

We still have it set in our environment. We're also deploying a krb5.conf file as well, I recall this was to address a Kerberos issue we had with JC at the time. Not sure if it's still needed, we've not stopped the deployment since setting it up in 2022, and it's not hurting anything. It was needed then. To answer your question no, we still have it set to "0".