This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
We run a POS service through an RDP Client that runs on AWS, and we are experiencing slow network printing. When the document is supposed to print it will spool and display "Printing" but nothing is spit out (later shows failed). It will take anywhere from a couple of seconds when it works properly into the tens of minutes. We have firewall rules in place that take the incoming Ip addresses and only accepts those from AWS and the remote services we require. We have also checked SNMP, DNS, DHCP, Port #s, Drivers, etc. Any follow up questions would be great!
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
Not a problem. I did get support in this issue. Our response times are good with only 2% drop. I did also find that our IP from AWS is correct and only one was is required. However no software changes have been made in the firewall.
Thanks for your reply!
Hello,
Regarding the timeout issue, if you want to investigate further, you may need to capture a full network log using Wireshark. I apologize that I am not a network expert, so this step might require additional technical knowledge.
For other aspects of troubleshooting, this link may be of assistance: https://learn.microsoft.com/en-us/troubleshoot/windows-server/printing/troubleshoot-printing-scenarios#slow-printing-or-unexpected-output
Other reference: Slow performance when you print - Windows Server | Microsoft Learn
To my knowledge, this started happening when our firewall failed and we did not have a successful backup. There is packet inspection and the firewall rules to my knowledge are pretty simple. All ports but required are blocked. We are filtering the traffic per our vendors request to two IP addresses. Port forwarding for our printers is simple send data to WAN:PORT. Within our fire wall LAN IP corresponds with it’s appropriate port.
How can I further investigate those time out in response. For as much as out IT help desk says it’s normal.
I did notice however when a printer got deleted and defaulted to our 8x11 printer, it printed immediately if it were not the printer needing to warm up and spoil each time. Is there some clues there that I am not aware of? Our vendor also says that they can not replace PS drivers with PCL, period. But they did once before and it fixed our 8x11 printing.
Much thanks for your reply.
Hi,
The timeouts in the traceroute results suggest that there are issues with some of the intermediate routers or network segments. You might want to look into these specific hops to find any bottlenecks or congested links.
Make sure your firewall rules are not too complex. Also, ensure that your firewall rules are not accidentally blocking necessary traffic. Sometimes, overly strict rules can cause delays or failures in network communication.
Since the issue involves AWS, it might be helpful to consult with AWS support or a network specialist. They can help optimize your AWS environment for better performance.
Hey Karlie, thanks for answering to my problem. I did do what you recommended. Since we have two IPs set as Main and Backup/2nd i have two different yet similar results. I am starting to see a possible issue?
On the First IP (Main) I ran "tracert" with no additional options. My results looked good at the beginning. Hops one through seven started off with one millisecond of latency to as high as four milliseconds by the time it reached hop seven. Hop eight through twelve, "Request Timed Out", and finally hop thirteen it reached its destination (AWS) with 31ms. I did run a second test just to see if results varied but the were consistant.
On the Second IP (Backup/2nd) I ran the same command with no options. The results were the following; Hops one through four increased from one millisecond to four. Hop five through eleven, latency increased from 17ms, sky rocketing to 53, and back down to 40 before hops 12 through 18 timed out. The trace was complete by hop 19 with 70ms.
