
- #WINDOWS CONNECT TO MAC SMB UPDATE#
- #WINDOWS CONNECT TO MAC SMB MANUAL#
- #WINDOWS CONNECT TO MAC SMB PATCH#
- #WINDOWS CONNECT TO MAC SMB WINDOWS 7#
- #WINDOWS CONNECT TO MAC SMB FREE#
#WINDOWS CONNECT TO MAC SMB MANUAL#
#WINDOWS CONNECT TO MAC SMB WINDOWS 7#
The windows 7 computer I need to connect is in another part of the office. That may be using some type of alias or a similar mechanism that may show the same problems.The Mac mini server is set up in our server room connected to a windows desktop via ethernet. One of our sites has two printers, but you print to the "building" and then swipe your badge at any printer and the job will be printed at wherever you swipe your badge. It may be using an alias to redirect to our printer. Interesting note about aliased URIs since we are using PaperCut to manage prints. Anybody know a way to speed that up? Printing straight to the printer IP with LPD only takes about 2 seconds. But that went away when I added the domain name into the printer server path and they started working - however it takes a good 30 seconds to a minute to connect to the server.
#WINDOWS CONNECT TO MAC SMB UPDATE#
Then I ran the update to 12.2 (from 12.1) and after the update, it stopped printing and showed the same signs as other fully patched Macs. I had one test machine that was not updated and had no problems printing with just the server name (not FQDN). I am running patches on it now to get it up to 11.6.3 and see if that helps. I also tried the "?encryption=no" switch in the URI and it still attempts to print, then pauses the queue. But now MY Mac is not printing - even with the fully qualified domain name being used. Update - after doing about 12 test prints across 4 Macs that were not working and now seemed to be working after using the FQDN, I hopped to my Mac to set up the printers and add them to JAMF. The more customer impact data the better.
#WINDOWS CONNECT TO MAC SMB FREE#
Feel free my reference my own open case 101616149128. If you have a support contract with them I'd ask you open a case. What version of Windows server are you running? Fully patched?Īpple is fully aware of the issue and collecting impact data from customers. There's some anecdotal evidence the problem is with aliased URIs, but I don't have enough first hand knowledge to know if that's true. Obviously not secure and not a long term solution. For example, use smb:///queuename?encryption=no. What were you using previously? smb://printserver/queuename? The only solution (which I hate) I've found is to turn off encryption with a URI parameter.

I'm curious to hear if you found it was resolved by switching to FQDN as the print queue URI. "Resolves an issue that prevented authenticating to a Windows print server with increased RPC authentication level."
#WINDOWS CONNECT TO MAC SMB PATCH#
All of these have the patch Apple describes as. Nothing to do with Jamf or MDM in general. This is directly related to RPC changes in 12.2, 11.6.3, and Catalina security update 2022-001 (build 19H1713) in response to PrintNightmare. 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. My coworkers think it is JAMF "JAMF-ing up the Macs". Address: (IP or FQDN of print server), Queue: (PaperCut Printer Name). 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). 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. This is happening on both our Prod and Dev instances of JAMF. JAMF shows "ProfileList" updated just before it stopped working. One Mac on 11.6.0 was printing yesterday, but stopped printing today.

One Mac that was able to print, stopped printing immediately after upgrading from 12.1 to 12.2. However, we don't have the server updates referenced in the thread or PaperCut advisory.Īffected systems are running Monterey, Big Sur, and Catalina. The issue looks very similar to this one:

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. 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. We are printing via PaperCut, so using SMB on a printer installed via JAMF and no changes to the setup. Just this week, we are noticing that many Macs, but not all of them, are not able to print via our Windows print server.
