Print server changed, cannot remove old printers
Hi there.
We're running an old install of Automation with 5 licenses, on a Server 2008 R2. We've got an ongoing renewal project, and this will be getting replaced later in the program, but we've recently replaced the old file & print server with a new one.
However, the software (Automation 10.0 SR1 and accompanying modules) still sees the printers on the old print server, as well as on the new one. This means each printer consumes two licenses, kicking us into the 30 day grace period (which incidentally we didn't even realise until everything stopped working 30 days after the migration).
In the Seagull License Server I can see the printers listed, with varying "last used" timeframes. But I cannot edit or de-license a printer from there. It seems to be populating this list automaticall.
I've tried repeatedly to figure out what functions are printing to the old queues but am unable to locate them. Something is keeping these old printers active and consuming a license, then we come to a screeching halt when we exceed the license count.
Is there any way to see what jobs are being pushed through a particular printer so that I can determine what's keeping it licensed and active?
I know we're talking about an old product but I hope someone still has the relevant knowledge.
Thanks in advance.
-
Opening memory banks for v10.0 as it is very old and has been out of support for quite a while now!
In Licence Server you should be able to tick the correct printers so that they remain (Keep) on the licence and will lock the licence slots to them so that the faulty printers cannot grab one of the licence slots. I dont think there is a way to clear the printer list manually, without intervention from Seagull Tech and as v10.0 is out of support this may no longer be possible either.
I seem to recall that there was a Users and a Printers tab in the Licence server application. If you check this can you see an unexpected users on there?
Do you have any automated printing applications running? I would suggest opening Commander on the old server and see whether that is running as if it is not a user who is selecting those printers then something else must be that is using BarTender.
If all else fails, you could go radical and delete the printers from the old server and wait for a user to start screaming that they cannot print and then correct their PC so that they are pointing to the correct drivers.
0 -
Hi Peter, thanks for the reply.
The checkbox is there but as you speculated it won't stop a printer from consuming a license, merely expiring off the list if unused, I suspect. That's what pushed us into the grace period. The new queues on the new F&P server started getting used, but traffic kept coming through the old queues too. The license utility still shows "last used" as today or yesterday for the old queues even now.
The users tab merely shows me (I sometimes print manual labels off the software) and "System", both on the Barcode server. No individual users are named.
Just to clarify, Bartender is on a standalone server so the actual install was untouched during this migration.
Commander shows a couple of tasks that are active, but I can't confirm what queue they're printing to. The properties of the task show they fire on detecting a file, and the command is type "Commander script", command is "%Trigger Contents%" and the handler is "BarTender1". I can't seem to bring up the details of any of these things to see if an old queue is embedded anywhere. Though I can see with the Commander window open that there's a logging pane. I'll monitor that and see if I can see it triggering a job that prints to one of the old queues. So far all the jobs I've seen going through while typing this have been to the new queues.I've enabled "keep printed jobs" on the old F&P server to see what kind of jobs are running through there, see if I can track down where they're coming from. Funnily enough, it seemed that even with the queues disabled or renamed, merely sending a label job to it and failing was still causing it to hold a license. That's why I was hoping to delete the queues directly through Bartender somewhere.
I'm very much looking forward to bringing this all up to date but the timeline calls for that to be when the ERP it services gets updated as well which won't be until next year.
Thanks again.
Sebastian.0 -
My guess is the Commander Script file has a \PRN= settings in it that is specifying the printer to use and so it looks like you will need to modify your system to change this output and make sure it sends the new printer names instead (#). If the file appears in a folder on the server that is being replaced then you will need to allow for this too.
If you temporarily stop the Commander string from running and triggering you could then open one of the trigger files, with say Notepad and check what it says and when you restart it the process would pick up the files again including any that appeared whilst you had stopped it.
Saying that, I thought there used to be a pane at the bottom of the Commander window that shows you what is going on and if you watch that or, if you can (been a while so cant remember) scroll back down and you may see the printer names.
# An alternative to this would be to upgrade and deploy BarTender 2022. This uses Integration Builder rather than Commander and has more options including a Search and Replace type feature and so you could set this to look for the old printer name in the trigger file, replace it with the new one and then let it process the print run.
0 -
Hi Peter.
Yeah we're definitely going to upgrade but sadly that won't be until next year, so I need to work around this for now.
Will have a look through the scripts. Thanks again.
Sebastian.0
Iniciar sesión para dejar un comentario.
Comentarios
4 comentarios