GaryPad

Could be an MS Update; could be something within the PDFs - so often a quick fix is in Print dialog of Acrobat to go to Advanced and then choose "Print as image" (note - this WON'T be accessible if you have "Print as greyscale" in Acrobat's print dialog). Foxit used to (I don't know if it still does) print as an image.

I'm not sure if the Toshiba MFDs come with PostScript (some manufacturers charge extra for it) but if you're doing a lot of PDF printing, or just having problems printing PDFs, then use a PostScript driver. The Tosh Universal hides this in the Device Settings menu for the queue properties, under Customisation - you can change the PDL in PDL Settings, I suggest from PCL6 to PostScript, and ensure that the queue Sharing is set to Render on the client. Another thing you could try is the Tosh Universal XPS driver - especially if you want to print from Edge. It seems to have the same settings as the usual Universal driver.

You should only need to make changes to the Follow Me queue, not the actual output queues; the print job will have already been formatted by then. I would recommend PCL-XL over PCL5c but just check in the Device Settings for the properties of your Follow Me queue that it is PCL-XL (PDL button) and ensure that "GDI compatible" is turned off and also "Smart duplex printing" is off. If you do make changes then I'd also recommend removing the queue from a client and reinstalling it to ensure the settings are applied and then print your tests. Also on the Sharing ensure that Render print jobs on client computers is enabled.

As a workaround until they do resolve it what you could try is add the LPD feature to the server (if it isn't already), create a new queue on that server (don't share it) using the same driver as your Follow Me queue, configured for Standard TCP/IP but use the server's own IP address, then (I'm assuming Windows here!), go into the Properties and switch the port protocol from RAW to LPR, set the queue name to be your "Follow Me" queue, tick the box to enable "LPR byte count", then change your redirect script to go to this new queue instead. What should happen is the redirect script bounces jobs to the new queue which LPRs it over to the Follow Me and hopefully PaperCut will see this as a new job in the system and will hold it as normal. Depending on the volume of jobs going this way, you might have to create a new DWORD registry key called: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\LPDSVC\lpr\UseNonRFCSourcePorts And set this to 1 (there's more detail on why here).

There are a lot of suggestions of things to try on this page on the PaperCut website: https://www.papercut.com/kb/Main/MissingOrDisappearingPrintJobs

Sounds like your redirect action isn't set to hold. You probably want it to hold and reprice too - something like this: actions.job.redirect("Follow Me", {allowHoldAtTarget: true,recalculateCost: true});

Most laser printers don't offer it because you get really poor quality at the edges (perpendicular to the paper feed path) due to the toner not adhering to those edges very well, but sometimes you can get edge to edge on the leading / trailing edges. The printers don't like it because in order to get it onto the very edge that assumes some will spill over causing mess and blockages inside the engine; plus it's costly and wasteful. The same applies to inkjet devices. If you log into the web server on the device as admin sometimes there is a configuration option for edge-to-edge, and you might have to go into a driver setting too in order to access it, but I would suggest only playing with this rather than leaving it on! Also if the device supports it then you're better with a PostScript driver rather than a PCL6 one as they are better for addressing the whole page (PCL6 drivers tend to follow the convention of their PCL5 predecessors - albeit completely different print language - in having approx. 1/2" non-printable area around all edges.)

You need and print it yourself!

According to the Brother site, under o/s it does list CUPS: https://www.brother.co.uk/printers/mono-laser-printers/hl-l2350dw and there are downloads for Linux (Debian and RPM) but on page 3 of the Datasheet under Print it only shows supporting GDI https://www.brother.co.uk/-/media/pdf/buk/product-downloads/datasheets/hl-l2350dw_datasheet.ashx?la=en - which should make it a Windows only device. However I did find suggestion that the hl7x0 driver "most probably" works so maybe try that? https://www.openprinting.org/printer/Generic/Generic-GDI_Printer PostScript definitely won't work, and neither will PCL (which should be either PCL5e for a monochrome device or PCL 6/XL; PCL5c is for colour devices) I'm afraid.

If the MFD releases the first page and then drip feeds the rest, the problem won't be your print server or PaperCut - it's the MFD. MFDs typically buffer Mbs of print job so the vast majority of jobs should disappear straight from the Windows queue and get sucked into the machine. You can increase the storage on your MFD with an internal HDD, so there is only 1 instance of the job sent to the MFD which it caches and reproduces X times (depending on your collated copy count). Whilst I say this is the MFD it can also be the print job itself. So if the driver thinks the MFD has no storage for that 1 original the driver creates a concatenated number of copies, e.g. 10 copies produces a print job 10 times bigger than 1 copy (so storage on the MFD is critical). If that's the case then the job in Windows could be massive, take ages to spool, the transmission to the MFD will back up - and the whole process is painful. Check the PaperCut logs for the jobs that are slow and look at the size (attribs value). Look at the driver settings on the Find Me queue - do the Accessories match what the MFD has in terms of internal HDD? The driver might be creating concatenated copies instead of 1 original which the MFD multiplies. I would also avoid "Generic" drivers like the plague; look for monolithic drivers specific to that device, assuming that Canon do one for the iR-ADV C5560 III. Lowest common denominator drivers are always the least efficient.

Did you try logging in as a different user and did they also get those print queues deployed to them? Just a thought - are you testing PaperCut's Print Deploy by any chance as this could push queues out (but then it would have the Print Deploy Client installed)? There's an archaic way of adding Windows which might be in play here. Open a command prompt as Admin and run this command to delete a globally assigned printer: rundll32 printui.dll,PrintUIEntry /gd /c\\%computername% /n\\server\printername Where "server" is your print server and "printername" is one of those print queues - repeat for all 6. It's interesting that your log has 6 entries - I presume each one is for your 6 rogue queues?

Open the Event Log and expand out Applications and Service Logs | Microsoft | Windows | Print Service. You should see Admin underneath with a red dot (meaning it's enabled) see if there is anything useful in there. You can also right click on Operational and choose Enable Log (so it gets a red dot too!) and try your delete trick again to see if it logs what's happening. Printer deployment can also be a login script so try logging in as a different user to see if they get the printers installed.