I have a client with 4 XP SP3 thin clients (HP t5740) that act as shipping stations. They have a scale hooked up to the serial port used to weigh packages. They RDP to a 2008 r2 server (with all the updates). Now, 2 of these thin clients are on the lan, and work just fine. The other two come across a wan/vpn connection and the only thing that doesnt work is the serial port redirection. The funny thing is that they (the wan and lan tc's) worked when they connected to a 2003 TS box (which we have not been able to decom.

• Drive Redirection Rdp
• Rdp Com Port Redirection

COM Port Redirection: How to map a client COM port to a server COM port. Or from the Remote Desktop (Terminal Services) Configuration tool. For information about policies, see the XenDesktop or XenApp documentation in edocs. When a Device is connected to a Serial COM Port, a registry key is created on this hive.

Because of this). All 4 thin clients are identical, have the latest firmware, etc etc. The connection is a 10mbps down/2mbps up and we're using the same username to test all of them. The only difference is the wan. Is there some sort of latency requirement for serial port redirection or anything else causing this, usually in the past with issues like this it either works or it doesn't. I've not had some working and some not working like this.

Thanks for any help! Hi, Thank you for posting here. This is possibly a known issue due to application design and the redirected serial device. In detail, each WriteFile request on the virtual RDP serial port on the server will result in an RDP packet sent to the client; while each ReadFile request on the server will result in 2 RDP packets. As the result, if the application reads or writes 1 byte at a time by design, so each byte transferred will create one or two RDP packets. This is the underlying cause that serial communications to be significantly slower. As the issue is only occurring in WAN environment,i suspect whether it is a network issue.And the only difference is the wan.

Regards, Clarence Forum Support Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support,. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Thanks for thre reply, I wish it was better news! How is it possible that on the wan clients remote desktop works, printer redirection works, everything except the serial port redirection works?

It all worked with 2003 server, I find it hard to believe we're taking a step back with 2008r2 rdp unless some sort of change was made to this feature in the newer rdp clients. The network is not dropping any packets, and the latency is under 90ms. Do you have any documentation or links to show this is a known issue?

I am in no way a RDS expert, so don't let this side track you if totally off base, but to me I would suspect the WAN or in this case the VPN. I am assuming you have some encryption as well as possibly a firewall on the VPN connection. Again, I don't know the communication process of RDP, especially on the serial port re-direction (who initiates the communications on that port, what ports and what protocol are being used, or even if it is any different then the user session) but it might be interesting if you have no other leads to look at monitoring the packets over that WAN/VPN; Either for blocked ports, blocked protocol+ports, or latency on the encryption/decryption of the packets causing issues. Is everything over TCP or is UDP used in the redirection?

Same ports as user session? Who opens the connection the client like in the user session or the server for the re-direction and is your firewall ok with this? Thanks for your proposed answer - I am having pretty much the same problem, and I tried this solution, but it did not improve the serial com port communication.

Drive Redirection Rdp

Here is my scenario: I am trying to use a signature capture pin pad for my point of sale software. The pin pad driver creates a virtual COM port. When communicating with the local computer directly, it works absolutely fine - communication is very quick. When I do an RDP session to a local server and share the COM port, there is also no problem - communication is very quick. However, once I try to reach a remote server and share the COM port, the communication is terribly slow and more often than not, the POS software ends up timing out. I have tried using an RDP session to the remote server over the WAN IP address of the server and using a VPN connection to it's local IP address, but both produce the same slow results. I'm using a Windows 7 (also tested with Windows XP) client connecting to Server 2008 R2 Server with remote desktop services.

Rdp Com Port Redirection

I made sure that all windows updates are installed to latest version. I also checked with the hardware manufacturer of the pin pad and I have the latest device drivers. I also tried using a different serial pin pad (not using virtual com port drivers) but had the same result, so I don't believe it's a driver issue. I've seen that slow COM port redirection seems to be a fairly common issue, but I don't see any clear resolutions. Any help you can provide would be great!