PDA

View Full Version : Kyocera Taskalfa 3051c/4550ci Private Print from Windows 8.1 through Print Server


Custom Search


swood
01-17-2017, 02:31 PM
Good Morning,

I have been working on this issue for the past couple days, and have been unable to figure it out. When trying to private print to any of our Kyocera Taskalfa MFPs from any Windows 8.1 computer, through our Windows Server 2008 (not R2) print server, the access code set by the user is not retained. I have found that if someone goes to print, the access code set by the user shows as invalid, but if we enter "0000" it accepts it. Through my testing, I have discovered the following:

- The private print access code set by the user is retained from Windows 7 machines, even when going through the print server
- The private print access code set by the user is retained from Windows 8.1 machines if adding the printer manually by IP address, bypassing the print server
- The private print access code set by the user is retained from Windows 8.1 machines if on the print server, I go to one of the Kyoceras and select, "Printer Properties" > "Advanced" and select "Print directly to the printer"
- We have some newer Canon ImageRunner C5235's and their secure print feature retains the access code from any of our computers. They go through the same print server, and are setup in the same manner, with sharing/security settings the same as the Kyocera's
- I tried updating the print driver to the latest on the print server for the 3051ci, and I am getting the same results (Kyocera TASKalfa 3051ci KX driver, version 7.0.24.15, driver date - 12/19/2016).

So basically the private print access code set by the user is always retained besides when we are using a Windows 8.1 machine, and printing through the print server, to a Kyocera Taskalfa MFP. I tried searching the Internet, and only found a couple similar instances where people ended up using other methods besides private printing. I would really like to get private printing working properly, and appreciate any suggestions you may have.

Thanks!

qbert69
01-17-2017, 05:14 PM
Is the print driver being pushed down to each computer from the print server computer? If it is, more than likely this authentication issues is being disabled/overridden by the print server computer. If the print driver is installed individually on each pc, then the authentication code should work correctly. You might want to check your print administrator settings on the print server to see if there is something that is being disallowed to keep users from using their own code at each individual pc.

:cool:

darry1322
01-17-2017, 06:03 PM
Under printer properties -> advanced tab -> click on "print directly to printer" ..... see if that helps

swood
01-18-2017, 04:26 PM
Thank you for the replies!

darry1322, I did try that and it does work when I choose that option. Isn't this not ideal though, as it ends up bypassing the print server for printing?

qbert69, Those were my thoughts to, it is almost as if the print server is not accepting/receiving the code from the computer, or that it is not sending it to the printer. Not exactly sure at which point this occurs. I have gone through the settings on the print server a few times and am unable to find any security settings that seem related to this. I also find it strange that a security setting would be affecting only Windows 8 machines, and not Windows 7, unless there is some sort of restriction in place in Windows 8 that I am unaware of. Then again, it is still working on Windows 8, if bypassing the print server. When a machine adds a printer from our print server, it downloads the corresponding driver from the server and installs it itself. What I find interesting is that it does accept the setting from the user that you want to private print, or else it would just print out normally, it is just not passing the user's inputed code along with this.

Still kind of at a loss for this, but I am really starting to think that this is more of a bug than an actual configuration issue. Hopefully I am wrong though.

darry1322
01-18-2017, 06:59 PM
Thank you for the replies!

darry1322, I did try that and it does work when I choose that option. Isn't this not ideal though, as it ends up bypassing the print server for printing?




Your print job still goes through your print server, it just doesn't spool on the local machine.


The data transfers directly to the printer queue ( in this case the print server ) instead of being stored in the spooler on the hard drive of the originating PC.

swood
01-18-2017, 07:57 PM
Well, I definitely did not think that one through haha. Of course it must still go through the print server, as the computer only knows the printer as shared by the print server.

So now this makes the issue even more confusing to me. If with both ways it is still going through the print server then to the printer, why would it only keep the user's entered access code when the user's computer does not spool it first? Also keeping in mind, it is correctly passing on the entered access code when the printer is added as a network printer by IP address, with spooling on the local machine still enabled.

Are there any disadvantages to setting a printer on our print server to the "Print directly to the printer" option, rather than having end-user's machines spool it first?


Thanks again for the help!

darry1322
01-18-2017, 08:09 PM
Well, I definitely did not think that one through haha. Of course it must still go through the print server, as the computer only knows the printer as shared by the print server.

So now this makes the issue even more confusing to me. If with both ways it is still going through the print server then to the printer, why would it only keep the user's entered access code when the user's computer does not spool it first? Also keeping in mind, it is correctly passing on the entered access code when the printer is added as a network printer by IP address, with spooling on the local machine still enabled.

Are there any disadvantages to setting a printer on our print server to the "Print directly to the printer" option, rather than having end-user's machines spool it first?


Thanks again for the help!

I wish I knew. It could be an issue with the data being spooled twice. Once by local and once by the server. I just don't know. This was the fix passed on to me and I keep passing it on. As fas as I know the only draw back is that since the job isn't being spooled local, the program that is printing keeps control until the job is completely sent to the server. When local spools the file, the program relenquishes control as soon as the job is spooled on the HDD. Without printing through a print server, the program could keep control while a large job is being fed slowly to the printer.

Dag0n
05-17-2017, 03:33 PM
Hate to bump and old thread but thought you might be interested to know that I found out how to get around this, from the print server, bring up printer properties, advanced, uncheck "enable advanced printing features", this should sort it, I no longer have to print direct to printer or have the '0000' default issue.

Custom Search