Print job accounting tells me wrong code - for only one user!

[Koldov]

On the server we have set up a print server, in the drivers we have ticked 'JOB ACCOUNTING' - this prompts the user for an I.D. before they print, all the I.D.'s are programmed into the MFD (KYOCERA TASKalfa 5550ci).

 

Today, the Headmistress comes to me complaining she cannot print! But it is only her, all the other admin staff that use the same code can print and I can print while signed on as her from another machine.

 

So does that mean it is machine specific and not server/permission related?

 

The only thing I did yesterday was add her personal office printer using the 'Samsung Universal Printer Driver' - seems to have gone wrong from then on, but I have uninstalled that and no change!

 

Anybody got some ideas? I do remember the Samsung driver messing up things at another school I did IT for, but it was a long time ago. I think it involved removing the printer entry from the registry...

 

Kol.

 

Edit: OK so I've definitely narrowed it down to this laptop/printer combination - I have logged on as admin and cannot print to this printer, but both accounts can print to other printers.

 

Edit 2: I've also narrowed it down to Office documents and PDF's - Pictures, notepad files, photos all print ok!

Edited February 4, 2015 by Koldov

[Koldov]

Ok so after spending most of the day on this, uninstalling, reinstalling, deleting, registry checking, trawling through printer properties on the client and server - I've finally found something...

 

This:

 

"This is an old one, but I thought I'd post the resolution.

 

If you are having the issue, where when Job accounting is setup on the printer, a user is added and then on the server Job accounting is enabled under the tab Device Settings->Administrator->Job Accounting and an identical account is added.

 

When the queue is shared to a computer. The computer prints and you will get an unknown ID error on the screen. SNMP is enabled in the driver with the right sting.

 

To resolve the issue, go to the advanced tab under the printer queue on the print server and set the option to print directly to the machine rather than for the server to spool the document. The Print job will now go through correctly. "

 

Source: http://community.spiceworks.com/topic/357270-kyocera-print-accounting-and-shared-queues-issue

 

I have no idea why this client laptop could no longer print as it's been fine for a while, none of the other printers or clients need this option ticked - It's not a resolution I'm happy with as I do not have the logical explanation that I need to explain it, or for future reference if it impacts anything else...

 

If anyone has a reason/explanation why the client gets a 'wrong' job accounting code when spooled at the server, but prints fine when directly printed please feel to chip in even if it's 'solved' for now!

 

Kol.

[Koldov]

*UPDATE*

 

Just to add something to this if anybody ever gets a similar problem - and just to clarify a few points...

 

There are 2 Lenovo laptops with this problem (I'm not sure the brand is a contributing factor) the only other thing that links them is that they are the only 2 on my network running Windows 7 64bit - also the printers are Kyocera (that may be the issue, but I have no other printers on-site that I can enable job accounting on).

 

Thing is after a network re-configuration last week, I have had to change all the printer static I.P. addresses and inadvertently wiped the printers off the server in the process and had to reinstall... Cue Monday morning and the same 2 laptops cannot print!

 

I remember this post and what I had to do, but I thought I would search for a better solution. I didn't really find anything else specific to this problem, however some troubleshooting tips from other printing related problems suggest NOT adding the printer from the server, but doing a 'manual' stand-alone install - choosing the TCP/IP port and adding I.P. address manually and finding the driver (not the server version - although I haven't tried that) to install.

 

This has solved the problem for now and the driver on the laptop does not need the 'Print Directly To Printer' option ticked (I just needed to remember to enable 'Job Accounting' in the driver on the laptop) and I can leave that option off in the server driver so I can use the print server to spool instead of changing a global setting for everybody...

 

Maybe this is a problem with the interaction of the 64bit drivers and the server and how the job accounting code is transmitted? Strange though, because I presume that the driver installed on the machine is the same 64bit driver I have on the server but now it transmits the code just fine when installed locally and not from the server.... (I will investigate and update this thread if/when I get time) just happy it's working for now to be honest!

 

Kol.

Edited February 24, 2016 by Koldov

[browolf]

Every time I have to move a print queue I get this problem. We have Taskalfa 3011i KX copiers

 

What the engineer has suggested in the past was set the account code on the server

Device settings > administrator > job accounting, tick job accounting to 0000 and then put in the correct code on the laptops in properties > preferences > job > settings

 

And make sure the users have only print permissions in security

 

I had to move all the print queues from the old 2008 server to a new 2016 virtual server. Now all the copiers don't work again. Tried updating to the latest driver. messing with all the settings - haven't got it working this time yet - it's so freaking annoying.