Using WSRM to control RDS Dynamic Fair Share Scheduling

Using WSRM to control RDS Dynamic Fair Share Scheduling

  • Comments 4

With Windows Server 2008, it was possible to use Windows System Resource Manager’s (WSRM) Equal_Per_Session policy to control CPU allocation of sessions. This ensured that no session would hog CPU and affect the performance of other sessions on that server so that all sessions on a TS Server would get an equal share of CPU. However, in Windows 2008 it could take up to several seconds before a runaway process was throttled, meaning that users would be adversely impacted until this throttling occurred.

In Windows Server 2008 R2 Remote Desktop Services, we have added kernel-based dynamic fair share scheduling (DFSS) to control CPU allocation. This system is able to throttle runaway processes in a matter of milliseconds, ensuring that the impact of runaway processes on users is immediately minimized.

By default DFSS gives equal weights to all sessions, i.e. all sessions are given equal share of CPU.

But what if an administrator wants to give different CPU shares to different user sessions?
For example, assume an RD Server running 50 sessions and every session is taking 2% of CPU (i.e. total CPU usage on the server is 100%) and the administrator wants to do some important maintenance work at that time. Because of the heavy load on the server, the admin will end up spending more time in doing this. This can be avoided if administrators are assigned Premium priority in WSRM’s “Weighted_Remote_Sessions” policy. Other scenarios can be: in an organization executives are given higher priority over other workers, or the Sales department has higher priority over the Manufacturing department, etc.

The administrator can allocate different CPU shares to different sessions using WSRM (Windows System Resource Manager). WSRM is an optional server feature used for managing system resource (processor and memory) usage. This feature has been part of the operating system since Windows Server 2008.

WSRM has a new built-in policy called “Weighted_Remote_Sessions”. This policy allows an administrator to categorize users into one of three priority groups: premium, standard and basic. WSRM ensures that users belonging to the premium group will get more CPU resources than those in standard, who will in turn get more CPU resources than users in basic.

You can use this feature by following the steps below.

  1. Open WSRM MMC (WSRM.msc). The “Weighted_Remote_Sessions” policy is listed under the “Resource Allocation Policies” node in the left pane. clip_image002
  2. To assign Users/Groups to different priority levels, right-click the “Weighted_Remote_Sessions” node and then select Properties. The Properties dialog looks like this:clip_image004
  3. Click Add to assign a priority to users or groups.
  4. In the next dialog, click Add to get the “Select Users or Groups” dialog.
  5. Choose the appropriate priority for selected users or groups, and then click OK:
  6. The added users are then listed in the Properties dialog:
  7. The Edit and Remove buttons are self-explanatory. Clicking OK saves the configuration created on the WSRM server.
  8. This information is not used unless “Weighted_Remote_Sessions” is set as the managing policy. If it is already set as the “Managing” policy, then new changes will take effect immediately. When you click OK in the Properties dialog, the new information is communicated to the service and WSRM updates the weights of only those sessions that are run by users whose category has been modified. If you want to update the weights of all running sessions on the server, select the “Update priority for all remote desktop sessions” check box.
  9. To set the Weighted_Remote_Sessions as Managing Policy, right-click its node in the left pane and select “Set as Managing Policy.”
  10. If some other policy is in the managing state, then setting “Weighted_Remote_Sessions” policy as managing shows you a dialog stating that you will need to restart the WSRM server to make this policy active. If you click Yes, the WSRM server is restarted.
  11. If Weighted_Remote_Sessions is in a managing state, then setting some other WSRM Policy in managing mode again requires a restart of the server.
Leave a Comment
  • Please add 5 and 6 and type the answer here:
  • Post
  • PingBack from

  • We've had some bad experience with WSRM, with the overhead of WSRM taking way too much cpu time, so we disabled it.. This was in VM's with one CPU, so we need to do some additional testing and with more CPU's in a VM.

    My questions after reading this article are;

    - can you say something about the recommended hardware configuration of Terminal server?

    - are there methods of limiting the amount of overhead WSRM creates on CPU cycles? Like a method where WSRM shuts itself down if it takes too much?

    - is WSRM recommended in a VM environment? Are there big differences between HyperV/VMware VM's in combination with WSRM? How does HyperV/WSRM handle VM's with WSRM? When HyperV handles/schedules the CPU load per VM and WSRM handles the priority within the VM, does that not create a CPU cycle war?

  • I am not sure if that is affecting you but WSRM had a performance bug in Windows Server 2008, which has been fixed in Windows Server 2008 R2. You can use Windows Server 2008 R2 RC build for your tests. Hardware requirement of Terminal Server depends upon the number of sessions you want to run on the server, please check if this link helps( You cannot control WSRM CPU usage. WSRM for CPU distribution (for non “Weighted_Remote_Sessions” policies) considers available CPU as 100% and then distributes that by continuously watching CPU usage of the running processes. So it doesn’t really matter how much % of CPU Hyper-V is giving to VM.

  • Fix for the above mentioned performance issue of WSRM in Windows Server 2008 is available. Follow this link for details

Page 1 of 1 (4 items)