Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2694
  • Last Modified:

Can't print to tcp/ip printer through remote desktop

I am having trouble printing to a local Kyocera Mita CS-2050 MF printer through remote desktop. In the past I have resolved this problem on different workstations in the same office by using the regedit FilterQueueType setup, but this isnt working on any new computers i try to setup. Of course this is the worst kind of problem: same actions, different outcome - but I have no ideas what to try next and am hoping you guys have some ideas.
One thing I found that did seem to work was sharing the printer from a working machine and connecting to that printer through the LAN. In that scenario I was able to print locally through the print serving PC, but try as I might, if I install the drivers locally, the Kyocera does not show up.
I have the exact same problem at two different offices who are logging into the same server through Remote Desktop and use the same model Kyocera printer.

Any other ideas to get this PC printing locally through RDP ?

thanks in advance
0
DotFoil
Asked:
DotFoil
  • 4
  • 4
1 Solution
 
gsgiCommented:
so it doesn't work in the office where the ts lives, and it doesn't work in either remote site?

and all three are directly attached to the network?

and how are the remote offices connected to ts?  is 3389 pin holed, or do you establish a vpn?

for the one at the office where the ts lives, create a local printer for the laserjet 5 and when it asks lpt1 etc choose tcpip port and enter the ip address of the Kyocera.  See if you can print to it via this driver (the laserjet 5)

-gsgi
0
 
DotFoilAuthor Commented:
TS server lives in location A. It is behind a firewall with port forwarding on 3389.

At location B i have a Kyocera cs-2050 printer and 3 XP workstations. They are connected to the Kyocera via IP printing and have the FilterQueueType fix, so they can print locally when they are looking at the TS server via Remote Desktop Connection.

At location C I have an identical Kyocera cs-2050 printer and 3 XP workstations. They are connected to the Kyocera via IP printing and have the FilterQueueType fix, BUT the printer doesnt show up locally through RDP on 2 of the XP workstations, it only shows up on the 3rd XP workstation.

The workaround at location C is to share the working printer and connect to it on the other 2 non-working XP stations. In this case, the shared, identical (as far as i know) printer shows up through RDP. So how can I get the 2 XPs to print without a shared printer? Thats the big question. It seems very strange that some stations have a hard time pulling the printer through RDP and others dont.

You are suggesting I mask the Kyocera driver as a HP Laserjet 5? Why is that?
0
 
gsgiCommented:
Basically I try to avoid printing through RDP.  What I do is install basic pcl printers (lj 4, 4 plus, lj 5) that are compatible with most printers.
Then I open a pin hold, port 9100 at the remote locations is for hp print servers.
Then I just tell the print driver to print to locationB_ip:9100
Then I just tell a 2nd print driver to print to locationC_ip:9100

Then I disable printer redirection for RDP.

-gsgi




0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
DotFoilAuthor Commented:
when you say "pin hold," are you referring to port forwarding? If so, do you mean internally point port 9100 to the server's IP of 192.168.1.2?
additionally, you suggest that I install a generic hp print driver, but on which port? LPT?

TS Server has an ip of 192.168.1.2
Location B Kyocera has an IP of 192.168.8.11
Location C Kyocera has an IP of 192.168.15.11

So youre saying I setup an HP printer on one of the XP workstation at location B on port 192.168.8.11:9100 and then when I log in via RDC to the server,  send a print command and this command will somehow be routed through to a different subnet (from 192.168.1.1 to 192.168.8.11) and back to my Kyocera printer?

...Thanks for this dialogue BTW. I am eager to find a more reliable printing solution, but the routing of the printing information in this scenario isnt clear to me yet.
0
 
gsgiCommented:
I was assuming the the three kyocera's were at different physical locations with individual access to the internet.

The at the site with the local TS it is easy, just install the basic printer driver that works for the Kyocera, and set it to 192.168.1.2 port (whatever it is for the kyocera print server, 9100 is used by hp jet direct print servers)

For the next 2 sites, you add two more versions of the basic driver and put in there ip address and yes, use port forwarding to the local ip and port of the kyocera print server.

-gsgi
0
 
DotFoilAuthor Commented:
You are correct that the 3 Kyocera locations are different with individual access to the internet and I think I understand what you are saying, except for the port forwarding.

If the server is on 192.168.1.2 and I forward port 9100 from anywhere outside to 192.168.8.11 on the server's firewall, the routing will be lost because x.x.8.11 is a different subnet that x.x.1.2 - isnt that true? So how could forwarding that port get a print command back to my local printer? I think that packet would be lost...
0
 
gsgiCommented:
You put the public ip of the site b and site c addresses in the printer driver.
then on the router at site b, you forward port 9100 to 192.168.0.11:9100
and on the router at site c, you do the same.

-gsgi
0
 
DotFoilAuthor Commented:
aha! I see! okay, well that is an interesting idea and sounds pretty solid. Im going to accept and give it a try. thanks for the help.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now