In short, the solution was to instead use the Shared Printer Item in GPP instead - which distributes the shared print queue on the server as intended. There’s a good conversation on Technet that illustrates this bypassing the print server behavior. What happens is that the printer is actually deployed as a direct print queue - enabling the workstation to print directly to the Print IP address, rather than through the Server print queue. Some customers have experienced issues when using GPP to deploy the printer connection. If the printer is deployed through Group Policy… It is possible to monitor workstation attached printers by installing the PaperCut secondary server on the workstation, but shared network printers are best hosted on a print server and shared to client workstations.Ĭheck out the Secondary Server Help Center section for more information on secondary servers.Ī great test to check you are printing to the server based print queue is to access the server side print queue and pause printing, on Windows this is done from the Printer menu on a print queue. Users should not be printing directly to the IP address of the printer - everything must pass through a print queue that PaperCut is monitoring. If you have printers installed as local print queues on one or more print servers then the print queue should be shared and your users print to the share. Now you have checked the print queues are setup correctly you need to make sure your users are printing to the correct print queue. For more information concerning adding print queues see here. Please double check the print queue on the print server is installed as a local print queue. Local print queues may include networked printers, such as those with their own network cards using a local TCP/IP port or physically connected printers attached via LPT or USB. You’ll have already seen this if you’ve checked that the service is running on the server, in the step above. PaperCut can only track these print queues by having the Print Provider (or ‘Secondary server’) running on the same server or machine that is hosting the print queue. printserver1\ LibraryPrinter and also printserver2\ LibraryPrinter and even testserver1\ LibraryPrinter. You might have more than one print queue configured to point to the same physical printer - which is why you may see the same printer listed under e.g. Within the PaperCut Admin Interface, under the Printers tab, you’ll find a list of all the Print queues being monitored. PaperCut monitors ‘Print queues’ rather than the actual physical printers. If this is the case, you will see a telling error message when you try to start the service. The other reason is that the PaperCut Print Provider Service has been configured to run as a service account, but this account has been disabled or the password expired. One is that the Windows Print Spooler Service was stopped and started for troubleshooting, this also stops the PaperCut Print Provider Service which is dependent on the Windows Print Spooler. There are two common reasons why this service is not running. ![]() See our article on Stopping and Starting PaperCut Services to learn how to do this on other operating systems. Below are the steps you would follow on a Windows machine running the Print Provider. If it’s not running, you’ll still be able to log into the web interface of your PaperCut server, but new jobs will not appear in the logs.įirst check to make sure the Print Provider service is running on the affected server (or workstation in the case of the Direct Print Monitor). This service pauses and analyzes print jobs. The Print Provider is a critical service used to connect to the printing system on the server (the “Print Spooler” in Windows or “CUPS” in macOS/Linux). Is the PaperCut Print Provider service started?
0 Comments
Leave a Reply. |