Posted on 07-13-2016 12:55 AM
My company is looking to implement PaperCut print monitoring.
At present, all Macs print direct to the printer (over LPD), but in order to implement PaperCut print monitoring we have to re-point the Macs at a Windows print server. However, in tests we're finding that printing directly, a file may take 15 seconds to print, when going to the Windows print server it's taking around 1minute 50 seconds. This for us is a reduction in QoS and will be noticed by the business. I am looking to circumvent this delay, does anyone have any experience implementing PaperCut or printing through Windows print servers?
Posted on 07-13-2016 01:53 AM
I recently started pointing at a Windows print server and too have noticed a considerable increase in time taken to spool, though it is varying hugely between a few seconds more to over a minute.
Would be very interested to hear of any ways to increase the speed.
Posted on 07-13-2016 02:23 AM
That's caused entirely by having an SMB based print share on the windows print servers. See if Papercut has an LPD service you can use, then set up mac print queues to use that instead. I worked with a competing product a while back and that was the basic solution.
Posted on 07-13-2016 04:42 AM
@franton You are correct. :D
I had forgotten to change the port protocol on the server queue. I even added the role / feature to enable LPD but overlooked changing it on the one port I was testing. Thanks for the spark to go check.
Now prints in a couple of seconds.
We are looking at adding Papercut soon and just checked and it supports this option.
Posted on 07-13-2016 07:33 AM
At my last company, we used PaperCut with a CUPS server on Ubuntu. I don't remember it taking any longer than printing directly, but it's been a while.
Posted on 07-18-2016 05:38 AM
Not Windows server, no. I've only ever used PaperCut with Mac OS X servers and using the 'FollowMe' function where after printing the user had to log onto the printer (high end Ricoh MFP) to release the job.
Have a look at print retention. There's an option in PaperCut to keep a copy of each print which goes through the system. This slows things down quite a bit as well as bloating how much space it needs.
Some logging options also affect print spool speed, as do automation workflows.
It may take a while to tweak PaperCut, I know it took me a good few months.
Posted on 07-18-2016 10:35 AM
This is an interesting conversation. We recently implemented PaperCut on a Windows 2012r2 server and we seem to be running alright (normal release, fast release and soon, follow me printing). I'm slowly working up to adding a Mac secondary PaperCut print server to help with iOS printing and the like. Given the experience of those here, what have you noticed to be the most successful server OS to handle cross-platform printing? While we're 100% Apple during our fall/Winter/Spring term, but we do have a handful of users and lots of visitors that are using Windows. Not to mention a few random Windows boxed for various development projects.
Posted on 08-31-2016 12:35 PM
The question that I have regarding the slowdown of your print queues, is when you configured the printers on the Windows Server, are you spooling the job on the server? or are you rendering the print jobs on the client computers before they're sent to the print server?
The first image is on the "Sharing" Tab for the printer in Windows Server, the second image is on the "Advanced" Tab. Try setting your printers up in this manner and see if the print jobs run faster.
Posted on 02-13-2019 09:26 AM
@cddwyer Can I ask how you set up Jamf to deploy printers which still ask for credentials when going through paper cut? Been having issues trying to get this to work... Thank you in advance.
Posted on 02-13-2019 09:45 AM
As a district we struggled with this for a long time, after the switch was made to hosting an LPD service rather than SMB on our Windows Print Server we were able to make it work. The printer is hosted as a virtual queue with all of our MFPS selected as destinations. We created one package within Jamf Pro to install and configure this printer, 1. installs printer driver package 2. Installs Papercut Client software 3. Install correct LaunchD so application will start upon login 4. maps correct printer into CUPS 5. Script to auto open Papercut client after install(open /Applications/PCClient.app). This 100% works and allows users to release jobs at any MFP(Findme), If anyone has any questions I would be happy to reply.
Posted on 02-14-2019 11:17 AM
Here is a follow up to my previous post,
“Best Practices for Deploying PaperCut with Jamf”
Initial Setup: Virtual/Physical queue in PaperCut MF software is setup and pointing to correct location on print server, creating a Null local identifier port works if using a virtual hosted queue. We utilize this to enable print jobs to be released anywhere in the district(“FindMe”). SMB creates a lot of issues when deploying so it is HIGHLY recommended you use an LPD/LPR to host the printer.
Jamf Deployment: First you will need to determine what driver/software is required for users to add/print to the desired device, Konica Minolta requires a software package be installed prior to adding the print device, this was downloaded from their site as a .DMG, ran through Composer and a .PKG file was created for deployment purposes. Next, we installed the driver package on our host machine and added the printer via LPD/LPR port using the CUPS service built in to Mac OS. Filling the field with the name of the print server, followed by the name of the desired hosted printer/queue. I will include a picture below;
After you add the printer to your host machine and ensure everything is setup as desired you will need to add this printer to Jamf Admin to make it accessible to your Jamf Pro server.
After the printer is added to Jamf Admin you will be able to create a policy within Jamf Pro containing this printer, therefore mapping the device to the client Mac.
Next you will need to download the PaperCut Client application and create a .PKG install package similar to the print driver package before. This will install the client software to track jobs and handle authentication. In our case we have users authenticating with AD credentials when the pop-up window appears. Something at the OS level looks to the current account name of the user logged into the Mac, if this matches the credentials to authenticate to PaperCut it will automatically login. There is a LaunchD within the package contents of the client application and this can be used to auto start the process upon login if you desire.
The last step to this process is putting all this created work together into one singular computer policy that will install the required driver, client software, and map the desired printer to CUPS. There are some important priority options that need to be set on each package after uploading them to Jamf Admin, the driver package needs to be set to “1”, the other pieces can happen after this in any order needed depending if you are including the LaunchD piece. Your policy will look something like this,
We have this policy available to users within Self-Service giving them the opportunity to add this whenever convenient or needed. The last finishing touch is creating a script that will open the PaperCut app when the policy finishes running, we use the following “open /Applications/PCClient.app”
This gives a rough outline of the workflow we used to create a policy to deploy this capability to our users.
Posted on 11-05-2019 10:55 AM
By following everyones advice here, I was able to successfully get PaperCut going - Thank you for sharing! But now we have our first bill from our printer management company and it looks like we set this up using the top quality setting. Anyone know how to change the print quality? I'm thinking it would be on the print server, but no one will give me login credentials to edit that. Booo!!! Server admins want me to pull the policy and rebuild it to see if this changes anything. Advice? Comments?
Posted on 11-06-2019 12:40 PM
I run our print system which has over 100 MDF's and thousands of users. We had long print delays after a temporary network change in one of our office locations. The cause was due to the print port setting being set to LPR instead of RAW.
With LPR it one job could take multiple minutes to complete a print job, from what I gathered the network changed added some additional latency and I guess it didn't like that. RAW on the other hand was really fast, and it was as simple as changing the setting from LPR to RAW on the printer port in the Windows Printer Server to fix that issue.
Example Times: LPR: 1.35 mins | RAW: 21 seconds