We have a small RDS farm running on Windows Server 2012 R2.

All the RDS hosts and related servers are virtual servers running on vSphere 5.5 (hardware version 8 if that makes any difference).

I've seen various articles about configuring RemoteFX in Group Policy, but they are confusing.

I'm not asking about improving things like watching YouTube videos etc., I'm asking about improving graphics in general, like screen redraws and displaying mouse movements, keystrokes, etc.

What are the best things to do to improve these things within an RDS farm??

I will try increasing the video RAM within the host servers' VM settings but this is a guess, and these hosts are logged into by multiple users over VPN connections...

Thank you, Tom

Hi Tom,

Here is a blog below I suggest you refer to, there are a few suggestions within it to improve graphical performance such as update drivers and increase frame rate on the client side:

Terminal Services and Graphically Intensive Applications

http://blogs.technet.com/b/askperf/archive/2009/04/17/terminal-services-and-graphically-intensive-applications.aspx

Best Regards,

Amy

Unfortunately not only is this article over 5 years old, it was not helpful because it does not even tell what settings to look at or change other than the frame rate registry setting. Windows CE?? I think it's not very much used nowadays...

These are all virtual servers btw.

Hi.

RemoteFX won't work as your Hypervisor host is VMWare, not Hyper-V.

RemoteFX works by taking the hardware graphics adapter and allowing the Virtual guests to utilise the power of the card directly, not through rendering at the hypervisor layer, but requires the host and guest to be running 2012 R2 (and a compatible graphics adapter)

Have you installed Desktop Experience? this can improve matters

• Edited by russgs Friday, January 30, 2015 1:53 PM

Yes, Desktop Experience is installed.

Thank you for clarifying on RemoteFX.

Thank you, Tom

If you are seeing noticeable slowdowns just on screen re-draw and laggy mouse etc id put my money on it being a bandwidth \ networking issue. Are your users local running over ethernet or are they remote workers?

Disk IO contention can also have odd effects on RDS, what kind of storage are you using under the hood? What version of RDP client are you using? If you are using an RDP client which is RDP8 or above is the client running in UDP or TCP mode (look for the "signal" bars - clicking it will tell you). Some Cisco hardware is known to have issues with RDP8 in UDP mode.

They are all remote workers...over VPN/WAN.

Various different network connections, speeds, etc.

Neither vCenter nor Windows report anything unusual networking-wise.

Disks are all 600 GB 15k SAS drives managed by HP Virtual Storage Appliances.

The firewall/UTM in front of the vSphere hosts is a SonicWall NSA 3600.

Most of the computers are Windows 7 running RDP 8+.

On my own connection, I have 3 bars and UDP is enabled.

Thank you, Tom

OK, next thing is Bandwidth and UDP as suggested

EDIT...What bandwidth do you have at the server end? how many users? Also VPN will add overhead (encryption/decryption)

• Edited by russgs Friday, January 30, 2015 2:26 PM

Server end is 60M/60M where the hosts are.

30-some users max to that particular site, from all over.

Site with complaints is 10M/10M dedicated fiber, soon to be upgraded to 20M/20M.

Other sites have apparently complained too.

Unfortunately none of the users has given specific details beyond "It's slow."

VPN can be worked on a bit but not during work hours :) :)

What's the effect of UDP vs. TCP?? Which is better??

Thank you, Tom

100% certain its a networking issue now!

Can you get one of your remote users to do a constant ping from one of their machine?

ping yourrdsservernamehere -n 100 -l 1400 -f

this will ping the server 100 times with a packet size of 1400 bytes and will tell you if the packets are being fragmented or not (down to MTU size). Start at 1400 and work your way up to 1600 until you get something like Packet needs to be fragmented but DF set. if you make it all the way up and still recieve this message then start working down until you get a reply. Post the max packet size back.

Please post your ping results back.

how big is your UPLOAD and DOWNLOAD at the central location? how many users are connected concurrently? Have you got UDP 3391 AND TCP 3389 both open to your end users?

• Edited by Microsoft Jim Friday, January 30, 2015 2:54 PM missed out the bit about changing packet size

Agree with Jim, definitely bandwidth

Run both TCP and UDP. In simple terms UDP 'fills the gaps' in TCP connections and smooths out laggy connections

What desktop OS are the clients running? Make sure all are running RDP 8.1

You may want to use NirSoft SmartSniff on your server to check clients are using UDP sessions.

VPN tunnel will add up to 20% overhead, thereby eating into your bandwidth

The central location is 60M down 60M up.

All clients Windows 7, WSUS shouls have put RDS 8.1 onto them, I'll have to look for that KB and make sure it's approved.

My connection uses UDP so I know 3391 is allowed, I can't imagine 3389 is disallowed, at least not explicitly (I do the SonicWall management).

As I said, 30-some users max but this could increase over time.

I did today remember upon seeing the MTU item that I never did get around to adjusting MTU on the central SonicWall...I have instructions for doing that where you start with 1500, then change the # downward until something changes etc. I should do that over the weekend...

Thank you, Tom

• Edited by tlyczko2 Friday, January 30, 2015 2:58 PM

You need to test the ping trail from one of the clients not the local LAN buddy, chances are there is an MTU issue either their end or in the middle somewhere... MTU1500 is default for LAN based connections but as newer RDP clients set the dont fragment flag and most home routers are MTU 1400 i suspect you will have issues when running with VPN overhead as well :-)

Daft question but would you mind pinging google from your central location also?

Where I stand typing this response, I am one hour away from the central location.

I myself am connecting over a VPN to the central location whenever and however I connect to it.

I used the RDP client itself, logged into rdfarm.domain.local as normal domain user, did the requested ping.

I can still manage things at the central location -- remotely via web, rdp, vpn, etc.

Thank you, Tom

Can you try without VPN, how many 'bars' do you get?

Another thing worth checking would be the network stats on one of your RDS servers when it starts to slow down a little... I have noticed that with around 40 users working in word \ excel I hardly push 4Mbits on the server, but when they start doing something a little more graphically intensive (PDF viewing, bitmaps, flash, surfing the net etc) then bandwidth usage can rocket. (not uncommon for my servers to hit 20Mibits outbound - depengdng on what the users are doing at the time.)



Those ping times look acceptable... Are all your remote sites using the same router hardware and ISP as you?

I'd recommend dropping the MTU on server and client side down to 1400 (a little low) but for RDS it doesnt need to be higher than that. do you get fragmentation with a packet size of 1472?

This is what I'm talking about wrt MTU on the central SonicWall:

http://carltonit.wordpress.com/2013/08/09/how-to-optimize-bandwidth-on-sonicwall-nsa-2400/ -- see the ping command for figuring out the best MTU, then configure it on the WAN interface, advanced settings

http://www.firewalls.com/blog/sonicwall-throughput/

Can change MTU on central SonicWall, it's already been configured in the SonicWall 3500 in my building (1468) but I can't change all the other places (3 other agencies) that touch the central servers, they all use different ISPs and firewalls and routers etc.

However knowing about MTU is a good thing.

Checking network usage etc. -- I'm usually not with the person(s) when they say things are "slow," I usually find out 'after the fact' or through someone else, sigh...

I'll work on MTU over the weekend...

Thank you, Tom

• Edited by tlyczko2 Friday, January 30, 2015 3:30 PM

Can you try without VPN, how many 'bars' do you get?

Not from where I am, I'd have to be onsite...connected to the switch...

Set it to 1400 on your RDS server and take it from there. Good luck, will check in on Monday with you!

Set it to 1400 on your RDS server and take it from there. Good luck, will check in on Monday with you!

Do you have any good references about where/how to do this?? -- registry?? GPO?? magic spells??

I must adjust 5 servers...

Thank you, Tom

TO SHOW
netsh interface ipv4 show subinterfaces

To AMEND
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1400 store=persistent

• Proposed as answer by Microsoft Jim Thursday, February 05, 2015 2:50 PM

TO SHOW
netsh interface ipv4 show subinterfaces

To AMEND
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1400 store=persistent

I've worked on MTU for the SonicWalls but not yet the above for the host servers...hope to do this today.

Thank you, Tom

Good luck! Hopefully the server change will sort you out... Keep us informed.

Do you have any update on where you are at? hopefully we have your issues resolved now?

Do you have any update on where you are at? hopefully we have your issues resolved now?

The one Great Plains application is still not behaving to people's satisfaction, I don't think it is a network issue but I don't have any good ways to prove this other than PRTG's collection of historical data, sigh...

I did reconfigure and verify the SonicWalls at each end are 1468 MTU, one of them would prefer 1440, but OTOH 1440 + 28 overhead bytes is 1468. Opened SonicWall ticket, no reply, don't know why.

On the RDS hosts I haven't yet tried changing MTU to 1400, I will do that now and see if I get more complaints or not, but I don't always know if people are having problems, sometimes I am the last person to know, sigh...

I'll try to remember to update again later this week or early next week.

Thank you for asking :) :) :) :) :)

did you ever manage to test MTU size on the Server(s)?

did you ever manage to test MTU size on the Server(s)?

Thank you for asking, I did set it to 1400 on the host servers, I haven't really gotten any useful feedback other that what happens now for some people working from a particular site over a particular VPN is they will be working in Great Plains 2013 and be suddenly disconnected -- this is an active session!! -- and we don't know why that happens. Early tomorrow AM I hope to have installed some monitoring software that will watch those RDS hosts and perhaps say/tell why those sessions get disconnected.

Thank you, Tom

So lowering Server MTU did improve things? Do you have any further feedback \ Questions? Can this thread be marked as resolved?