Enterprise Mobility and Security Blog


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.