I got dem Ol’ Slow Terminal Server (2012) Blues!

l have been fighting with a new RDS (terminal server) install at a big customer for the last few months.  They run a line of business app that is written in Visual FoxPro9 and it has some quirks, to say the least.  They were running the app on an older Server 2008 terminal server on top of VMware ESXi and we migrated them to a Server 2012 R2 RDS server on top of Hyper-V (again, Server 2012 R2).

The Hyper-V host had been built with a Tiered Storage Space on an Dell T620 configured with as much shiny “go fast” hardware as we could stuff into the box.  I built out the RDS server VM using best practices and the thing appeared to be smoking fast.  User acceptance testing was performed on the VM (or so I thought) then we picked a weekend for the big bang migration to the new box (did I mention that the whole blasted company runs off the terminal server??? and that migration was essentially one way???).  Then production starts on the box and the LOB app is a dog.  Uggghhh!

To make a long and painful story short, let’s just say that I tried everything under the sun to get the blasted thing to work better and failed.  I also have to say that all efforts were focused against the VFP9 application which, in the end, was actually something of a red herring.  The key to solving the problem was to NOT look at VFP9 issues and focus on the terminal server itself, instead.

What finally tweaked me to the fact that it wasn’t a VFP issue is when we started trying things on the same test VM in terms of test without RDS role enabled then test again with RDS role enabled.  Doing this lead to very clear results – soon as RDS role was enabled the performance, specially for the VFP9 app, went into the basement.  With that in mind I spent a little time with my friend Mr. Google and soon came up with an answer!

It seems Microsoft has “quietly” slipped into RDS server environments a technology that they call “FairShare”.  FairShare was originally enabled in Server 2008 R2 at the CPU level and then expanded with the release of Server 2012 to include disk and network, as well.  In a nutshell, FairShare is a set of filter drivers that “throttles” CPU, disk and network at the user level so that no one user can hog resources on an RDS box.  As soon as the RDS role is enabled in 2012 or 2012 R2 the FairShare filters kick in and they can be a performance killer to things like my clients VFP9 app!

Thankfully, it is reasonably easy to “fix”.

The FairShare CPU settings can be turned off by a GPO setting that you apply at the machine level –> Computer Configuration, Policies, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Connections: enable Turn off Fair Share CPU Scheduling.


The disk and network settings are a tad harder to change as you have to make REGISTRY changes on the RDS server itself:







Make the registry changes and reboot and you should be good to go!

Be aware that you have now removed the constraints that Microsoft put in place to keep user sessions form going crazy BUT it is probably a good trade off if you need to get your speed back for particular applications.  My customer saw certain functions go from taking over 10 minutes to taking under 2 minutes after we made the changes.  And other functions that had taken  multiple seconds became “immediate”.

I hope this saves you from hours, days, even months of agony!

13 responses to “I got dem Ol’ Slow Terminal Server (2012) Blues!

  1. We genuinely Thank you Robert for sharing this article. Your solution saved us incredible amount of time, money and effort for our Delphi based commercial product. Cheers.

    1. Boris:

      Thank you very much for your kind comments! I’m very happy that I could save you from the grief I went through!


  2. Would these setting fix a published remoteapp program using RDS? I have a published app that is slow and sometimes locks up while the user is working…

    1. Victor: If the underlying app fits the same parameters as I have described then there is a good possibility that all of this would help. The app is still being served up via RDS and all of the issues that I highlight would come into play. Best bet is to try (but backup first, of course)!

    1. Will:

      You are very welcome! Glad to be of assistance!

      Robert (aka The Beagle)

  3. I am also suffering with the same problem as soon as I enable the remote desktop role application is slow and if I disable RDS roles application performance is normal. I tried all the above steps but no luck. It will be great if you could suggest me some solution or workarounds .

  4. Hi,

    We have an issue with RDS 2012 R2 where when a user tries to copy a file to \\tsclient it gets to 6kb in size and then just hangs and does no more. We’ve ran tests to take firewalls and different networks out of the equation, we ran your suggestions above just as a test but it appears no matter what, when saving a file to \\tsclient it hangs at 6kb.

    Have you seen this before? Anything you can suggest?



    1. Steve:

      Sorry, I’ve not come across this particular issue so I really have nothing of use to suggest. If the issue is widespread I suggest you open a support call with Microsoft as it may well be worth the couple of hundred dollars that they will charge to solve the issue.


  5. Robert-

    Thank you so much for this article, I had admitted defeat and started building a 2008R2 VM when I came across this fix.


  6. Do you really think disabling CPU FAIR SHARE will not cause any issues. I have slowness issue with one of our client with 50 users on RDS 2012 server and I remember reading about this ages ago and disabled NEtwork and disk fair share but not CPU fair share.

    This is because from what I read, the CPU fair share was part of RDS 2008 and enabled by default. They never had any issues on RDS 2008 that they were using on an old physical server, but now that we are using RDS 2012 with 30 VCPUs applications at time run like a dog.

    Also wondering how many vcpus did you allocate at your clients site. I thought 30vcpus is too much for a 50 user site but it has made some improvement in performance.

    1. Max:

      I can only tell you what our experience has been. Disabling CPU FairShare solved the issue for my customer with their ancient application. Is it best practice? Probably not but it hasn’t caused them to fall over at this point. As for vCPU’s, the most we have allocated to any given VM is 4, we did not find any particular improvement to a VM performance going over that count. Most users tend to overallocate vCPU’s.


Comments are closed.