2

Our setup is as follows:

Two offices (A and B) connected with OpenVPN Access Server.

One Windows Server 2008 R2 Standard

  1. Housed in remote datacenter.
  2. Terminals at both offices connect through RDP in order to use a particular piece of software concurrently.
  3. Network Connected printers (Deployed with GPO) that are connected to separate terminals at each office (and shared) are used with this software to print things throughout the day.

We are experiencing extremely slow printing times. Opening printer properties can take 30-60 seconds and printing times range from 30-180 seconds with no apparent reason. File sizes remain < 1mb.

This happens with each of our printers. All different models.

The server massively underutilized with a 6-core AMD, 16GB ram, 4x 120GB SSDs, and a 100 megabit port. Our VPN does not seem to be a bottleneck either.

I've been attempting to find ways to increase print speed. So far no success. What can you advise?

Improve this question
3
  • Clarify the print job flow: Are there print queues on the Terminal Server computer that send jobs to the printers, or are the print queues on the RDP clients (and you're using RDP printer redirection to print to those queues)?
    – Evan Anderson
    Jan 2, 2014 at 21:41
  • The printers are shared through physical machines connected to the VPN server directly. And the win server is using gpo to deploy the connected printers to each rdp session.. There is no use of RDP printer redirection at all.
    – James
    Jan 2, 2014 at 21:47
  • I would suspect either some kind of name resolution problem or some issue with MTU / fragmentation etc. You could try a network capture using wireshark
    – lacasitos
    Jan 2, 2014 at 22:28

2 Answers 2

Reset to default
2

I don't have any advice to offer on root cause. Nothing jumps out.

If I were troubleshooting this I'd sniff the traffic. Nothing beats seeing the packets on the wire.

I would capture network traffic between the Terminal Server computer and one of the computers hosting the shared printers while the problem is occurring. Since you're seeing "slowness" just opening the Properties sheet for the printer I think capturing the traffic generated when you try to do that should at least generate a lead.

Minimally, you'd do a capture at a time when traffic between the Terminal Server and the PC hosting the shared printer would be at a minimum, so that you can use a simple capture filter like host <ip of print server PC> (assuming pcap filter syntax). It would be even better if you could find a time when you're the only use on the Terminal Server such that you can capture (and feel confident that your actions are generating) all non-RDP traffic to/from the Terminal Server just to make sure you're not missing attempted DNS resolutions, IPv6 connection attempts, etc.

If you're uncomfortable putting third-party sniffer software on the server grab Microsoft Network Monitor. (I'd like to recommend the new Microsoft Message Analyzer but I just haven't had enough time to get comfortable with it yet.)

Improve this answer
2
  • Sorry! I forgot about this question and your answer. The problem mostly lied with DNS resolutions. Dropping WINS/DNS from the equation, I was able to drastically reduce print time. Thanks for your answer!
    – James
    Jun 26, 2014 at 17:06
  • @James - Glad to hear it's working.
    – Evan Anderson
    Jun 26, 2014 at 17:17
0

It's been a long time. However, I would like to encourage anyone who is having such an issue to ensure their VPN is a site-to-site setup. After switching to UBNT EdgeRouter with Site-to-Site OpenVPN, printing time is practically instantaneous.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .