Failed to send a print job to LPD Service. System reports error: 'TCP/IP Print Server refused a print job.'

Problem:

We are seeing the error "Failed to send a print job to the Pharos LPD Server. System reports error: "TCP/IP Print Server refused a print job." which produce an Alert 29100.  

Possible Steps for Resolution:

1. Check to ensure that the Server has not run out of hard drive space.

2. Check to ensure that the Pharos Print Queues are configured as "Shared".

Additional Details on how it works:

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.  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.  Windows' event log 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.

The Print Server log likely has the correct hostname as it works most of the time so it looks like we're using GetComputerName. This normally isn't needed, but you could push aside DNS queries and the like by populating the HOSTS file with a static entry for the server (but map the host name to its external IP address, not 127.0.0.1).

**It is therefore necessary to look at the Windows Server Event Logs (PrintService Event Log as well) around the failure occurrence to see if there is a dependent failure. If there is, then the dependency must be resolved. In short, it is not a defect/bug in the LPD Service, but a known result for a variety of network or service-related causes.

Note: Some additional registry keys that might help, we don't provide them as a "fix" but only mentioning them as they have been mentioned in a number of forums across the internet for some DNS related problems with the Windows Print Spooler service.  

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print
Value: DnsOnWire
Type: REG_DWORD
Data: 1

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value: DisableStrictNameChecking
Type: REG_DWORD
Data: 1

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value: OptionalNames
Type: REG_MULTI_SZ
Data: yourservernamehere

Once applied restart the server.