Resource Sharing in Windows Remote Desktop Services

** Please be sure to check out the updated version of this article for Server2016: Link **

Resource sharing is at the crux of every virtual environment and is ultimately what makes a shared environment feasible at all. A very common pain point in Remote Desktop Services/ Terminal Services (RDS) environments is the potential for a single user to negatively impact every other user on that RDS host. Server 2008 R2 includes a feature called Dynamic Fair Share Scheduling (DFSS) to balance CPU usage between users. This is a proactive feature so it is enabled by default and levels the CPU playing field at all times depending on how many users are logged in and CPU available. In Server 2012 the fair share features have been expanded to include network and disk as well.
From the Server 2012 RC Whitepaper, the 2012 fair share experience:

Network Fair Share. Dynamically distributes available bandwidth across sessions based on the number of active sessions to enable equal bandwidth usage.
Disk Fair Share. Prevents sessions from excessive disk usage by equal distribution of disk I/O among sessions.
CPU Fair Share. Dynamically distributes processor time across sessions based on the number of active sessions and load on these sessions. This was introduced in Windows Server 2008 R2 and has been improved

Cool! New features are great. Fair sharing has been traditionally an on or off feature, this is where the extent of the configuration ends. From what I can see in the 2012 RC, that doesn’t appear to have changed. Of course if you are running Citrix XenApp, you would want to disable all Windows fair share features and let XA take care of those functions. Fair sharing can be controlled via Group Policy or registry but only the CPU piece is visible in the RC GPOs.

It is also stored all by itself in the registry under \Quota System.

I do see the additional fair share elements in the registry, however, so the missing GPO elements should appear in the RTS version of the product. Obviously, 1 = on, 0 = off. Looks like there is some registry organization work that still needs to happen.

In an environment where 100% of the users run 100% of the same applications with 100% predictable usage patterns, this model works fine. The trouble begins when you need to support an environment the requires some users or applications to be prioritized over others. There is also nothing there to deal with application memory usage. You could make the argument that this is the point at which these special users should be carved off of the shared session host and given VDI sessions. Luckily, WSRM is available to provide tighter controls in a shared session environment.
Windows System Resource Manager (WSRM) is a tool that has been around since Server 2003. It’s purpose is to granularly define resource limits as they pertain to specific users, sessions, applications or IIS app pools. WSRM’s use isn’t limited to RD Session Hosts, it just happens to be very useful in a shared environment. It should be noted that WSRM is a reactive tool, so you have to cross a certain threshold before the limits it imposes kick in. In the case of CPU, the host has to reach 70% utilization first, then any defined WSRM CPU limitation policies would begin to ratchet down the host. Best practices call for the use of targeted CPU limits to restrict resources, not memory limits. Use memory limits only if an application is exhibiting a memory consumption problem.
Here is a quick example of an allocation policy limiting IE to 25% CPU. This policy would need to be set as the managing policy for it to take affect after the host’s total CPU reached or exceeded 70%.

Another simpler option could be to use weighted remote sessions, categorizing users into basic, standard, and premium workloads to appropriately prioritize resources.

In the Server 2012 RC Add Roles and Features wizard, it is clearly called out that WSRM is now deprecated. Server 2012 will have the tool but the next server release in 4 years will not. Hopefully Microsoft has something up their sleeves to replace this tool or bolster the configurability of the fair sharing features.