The issue isn't in the driver, it is on the Konica-Minolta box itself. In the accounts that have had LPR-sending issues, we've converted to using RAW (Port 9100) instead, and the problem has gone away.
I hope that this helps,
Here are some thoughts on drivers for Konicas, but not an answer to the specific LPD error your getting. I've found that it's best to install the driver for each model of Konica in your fleet onto the server, then configure each print queue with the correct settings for each device. That way, each print is sent with the correct driver and settings to each Konica device. We have about 65 KMs in our fleet, but only about 5 different models. So I installed the 5 drivers, the configured each queue in Windows Server Manager with the correct settings.
Here's a post that Scott answered years ago about configuring the print drivers on each print queue that's still accurate:
Basically, you assign the driver to the queue in Pharos, and set "Copy Printer Settings" to Yes.
Then in Windows Server Manager, you find the print queue and set the Default options under the Advanced tab. There you can specify all the model-specific options like stapler, hole-puch, paper trays, color, double sided, etc.
Then build the installer package in Pharos and it will get all the default settings.
For Mac, it's a little more involved, as it does not get the default settings from the server, but you have to configure them in the PPD file you use during installation. My university has started using JAMF, which has made managing Pharos printers much easier. If you use Mac and I can give you some pointers there, too.
The error you mentioned happens on 'Job Submission' where the job is going to the server, not when the job is being sent to the device.
"Failed to send the print job to LPD service - The TCP/IP Printer Server refused the print job"
We have a KB Article on it Failed to send a print job to LPD Service. System reports error: 'TCP/IP Print Server refused a print job.'
The problem is that the LPD Service gets bad response from the Windows Print Spooler so the client is not able to send the job to the server.
How it works:
"The LPD Server attempts to "open" the printer via the Windows OpenPrinter function (http://msdn.microsoft.com/en-us/library/windows/desktop/dd162751(v=vs.85).aspx) before receiving a job for it. This call then goes to the server's Spooler service, which either gives us a "yea" or "nay" return (it is actually a little more than that, but sufficient for this discussion).
If this function above returns "INVALID_HANDLE", we will report this error. We query the printer in the form \\machinename\printer, where machinename is the internal value that can be overridden with the MachineName registry value for Uniprint. Since this works most of the time on this site, it's unlikely there's a problem with the name, so it's more likely there was an RPC or spooler issue at this particular time. The Windows event log(s) might have some insight into what was failing at that time, but our logs are unlikely to.
The LPD service gets the value of "server" by either consulting the MachineName value in the Registry (HKEY_LOCAL_MACHINE\Software\Pharos), or issuing another Microsoft Windows command, GetComputerName, which returns the NetBIOS (host) name of the server. It is in the server name that we usually find the problem: Spooler cannot resolve the name as a valid one.