Terminal Services vs. Native Clients and Your Experiences

(0) Share

Report

Posted on by Community Member Microsoft Employee

We are looking to expand usage of SL to a remote location and there is concern about terminal server usage from both a performance and functionality perspective. Any help or insight on the questions below you can give would greatly help. Thanks in advance.

1. Do you use terminal services extensively within your organization, for local and/or remote clients? (How many clients, locations ?)

2. Have you experienced any performance issues with terminal services, and what was the cause and/or resolution?

3. Do your users experience any loss of functionality when using the SL client within terminal services versus a native client on their desktop?

4. An insight on the amount of bandwidth and latency required for an acceptable terminal services SL client end user experience?

5. An alternate option being explored is getting a very large pipe in between the remote location and the main location where the SL system is located and running native clients remotely. Has anyone done this and can you speak to the bandwidth and latency required to make this work?

Thanks!

*This post is locked for comments

All responses (2)

Answers (1)

Community Member Microsoft Employee on at

Like (0)

Report

RE: Terminal Services vs. Native Clients and Your Experiences

Thank you so much for this response! This is a big help.

Regards,

Anthony
Verified answer

Erich Strelow F 1,642 on at

Like (0)

Report
RE: Terminal Services vs. Native Clients and Your Experiences

We use terminal services extensively. We have 160 clients, but the concurrent users are steady on around 60. We have 18 locations. We are on SL 2011. We use mainly RemoteApp.

We've had some performance issues:

On locations with higher latencies the user experience sucks.

For some reason, the Crystal Report engine loader takes longer on our terminal server. There is a particular operation on AP module called "Reprint AP Batch Control Reports" in which the reporting engine gets loaded once for each voucher. Each voucher takes 25000ms to print, that being measured under different load scenarios. This wasn't network related, has more to do with our server. For some reason, that times shortens to 5000ms on a local installed client, so we kind of forceably had to setup local installations on our AP staff..

About loss of functionality, some users get confused in processes that involve local files. Since we use RemoteApp, the users that generate files for bank electronic payment do a "Save As..." to the desktop folder and expect the file to appear on their local desktops.

I don't have much insight on latency or bandwidth. I know that latency is more important on this kind of setup, so I focus on that. Please note that we have very small branch locations, about 5-10 users each.

Both images above show latency measures based on ms on 100 sampled packets. The more left the better. The upper is cable based internet and the other is DSL based. SL works about right, the users perceive no difference. Both measures are 99% below 50ms.

This other was another location with a faulty DSL connection. See that even the scale is different. The user experience sucked.

This last one is headquarters where we did the large pipe thing. The SL implementation project was the first time we vendorized our servers to an external datacenter. Both our offices and the datacenter are in a big city and there's plenty of access to network resources on a competitive market. I didn't want to get booed because "the older system were faster". So, hiring a large pipe was a no-brainer. We have a 100Mbs switched but private fiber optics between both ends.