DFSS doesn’t work as expected

Posted on Updated on

ATTENTION: this blog post is a replacement for a previous blog post about the same topic (https://windoh.wordpress.com/2012/01/24/dfss-gets-disabled-automatically). In my previous blog post not every piece of information was correct. I’ve done some more research and I have new information about this topic. That’s why I have written a completely new article. Please ignore my previous blog post completely!

Dynamic Fair Share Scheduling (DFSS) is a new feature for a Remote Desktop Session Host (RDSH) (so only on Windows Server 2008 R2) and is enabled by default when the RDSH role is installed.

DFSS can be controlled in 2 ways:

  • Through a named value in the registry
  • Through a group policy setting, which is actually represented by another named value in the registry

This is the non group policy way of controlling DFSS:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SessionManager\Quota System
Named value: EnableCpuQuota
Possible values:

  • 0: DFSS is disabled
  • 1: DFSS is enabled

If the named value isn’t created, this has the same effect as having it the value 1. By default the named value isn’t created, so by default DFSS is enabled if it would be based only on this named value.

As just said, it is also possible to control DFSS through a group policy setting:
Path: Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections
Setting: Turn off Fair Share CPU Scheduling
If this setting is disabled, DFSS is enabled; if this setting is enabled though, DFSS is disabled. Don’t get confused! J So if the setting is configured, EnableCpuQuota is totally ignored. But if the GP setting isn’t configured at all, EnableCpuQuota decides if DFSS is enabled or not. By default the GP setting isn’t configured. As by default the group policy setting isn’t configured and EnableCpuQuota doesn’t exist, DFSS is enabled by default on an RDSH.

What the GP setting does when enabled or disabled, is creating the following setting if it doesn’t already exist (and if a piece of the key path doesn’t exist, that’s created too):
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SessionManager\DFSS
Named value: EnableDFSS
Possible values:

  • 0: DFSS is disabled
  • 1: DFSS is enabled

If the GP setting is enabled, the named value should be 0. If the GP setting is disabled though, DFSS should be 1. Of course it’s not really necessary to have a GP setting to control DFSS, as you can edit EnableDFSS yourself directly too. If EnableDFSS doesn’t exist, that’s the same as no GP setting for DFSS being active (so that setting being not configured) and then EnableCpuQuota determines how DFSS behaves. Note: be aware of the fact that if you change EnableDFSS directly, it can be overridden if you actually configure the group policy setting. If the setting isn’t configured through group policies, but it was before, the named value is deleted.

Side note: by default SessionManager in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows doesn’t exist. It’s only there if you have created it explicitly (manually, through a script,…) or if the GP setting is configured. The same counts for the subkey “DFSS”. The subkey “Quota System” is only introduced explicitly (there is no GP setting doing something over there). If the DFSS key exists and the GP setting is not configured, but it was before, the key will be deleted automatically if there is no other content under the key; then it also deletes the key SessionManager if there is no other content beneath. So this deletion of named value and key(s) takes place only when the setting was configured through group policy first and changed to “Not configured” later (and of course no other group policy keeps configuring it).

Anyway, in my case it was all very simple: I wanted DFSS to be enabled explicitly through group policies (although it was already enabled by default) and I disabled the GP setting. But… EnableDFSS was indeed introduced, but it got the value 0! Even when I changed its value to 1 and updated the group policies again or even rebooted the server, EnableDFSS was 0 again. Oh damn!
I tried it the other way around too: now I wanted to disable DFSS through group policy (just for testing). Well, that’s what I did, but that didn’t work either, because now EnableDFSS became 1! It seems the group policy setting does the opposite of what is expected or the named value’s name is misleading (and then 0 means enabled and 1 disabled). If I check the Internet and read about the behavior of this named value (for example, on http://technet.microsoft.com/en-us/library/dd560667(v=ws.10).aspx), I would expect it’s the group policy setting that’s “misbehaving”.

So, what should you do? Well, you can

  • “not configure” the GP setting and let EnableCpuQuota control the desired behavior of DFSS (and again, not having this named value is the same as giving it the value of 1)
  • Set the opposite of what you actually want through group policy J

There is one more important thing to know though. At first I was confused by http://technet.microsoft.com/en-us/library/ee808941(WS.10).aspx. This page doesn’t really explain the situation well… It gives the impression disabling DFSS through group policy doesn’t work at all (and only disabling!). It also gives the impression you should make EnableCpuQuota 0 (and create it first if it doesn’t exist yet) to disable DFSS, while it doesn’t really matter what the GP setting is configured. Technically spoken this page doesn’t tell us incorrect things, but it does give a whole lot of wrong impressions. Typically users will set their GP setting on “Not configured” after reading this page, so EnableCpuQuota being set explicitly to 0 does indeed disable DFSS. But if you keep your GP setting enabled (because you tried to disable DFSS), EnableDFSS still stays 1 and thus DFSS still stays enabled (as EnableCpuQuota isn’t used then). You see? The page at TechNet gives wrong impressions and in some cases their “solution” still doesn’t work. So please read all the things I’ve explained in this article to get the full picture. If you want to see a confirmation of everything I’m telling you, please read http://support.citrix.com/article/ctx127135. This page from Citrix doesn’t explain every detail of the whole story, but it clearly provides us with the bottom line. The page wants to help people to effectively disable DFSS. Side note: you could ask yourself why in the world you would like to disable DFSS. Well, normally I would advise you to keep it enabled, but in some cases it is better or even necessary to disable it. One situation is on XenApp servers (RDSHs with the Citrix XenApp functionality built on top of it) where you want to enforce Session and Published Application Importance levels: DFSS needs to be disabled and the XenApp CPU Management Server Level must have been set to “Preferential Load Balancing”.
Oh yes, the first link was also confusing because it mentioned it was actually targeting Windows 7. AFAIK DFSS is only for RDSHs (so only for WS08R2) though… I guess that is a documentation error.

Figure 1 shows DFSS is enabled because the GP setting was enabled. Figure 2 shows how DFSS is disabled through a named value which has nothing to do with group policies (remember it is only valid if the GP setting isn’t configured).

Figure 1

Figure 2

Some double checking
If we take a look at the GP setting in TerminalServer-Server.admx (located in %windir%\PolicyDefinitions) we can read the following:
<policy name=”TS_ENABLE_DFSS” class=”Machine” displayName=”$(string.TS_ENABLE_DFSS)” explainText=”$(string.TS_ENABLE_DFSS_EXPLAIN)” key=”SOFTWARE\Policies\Microsoft\Windows\SessionManager\DFSS” valueName=”EnableDFSS”>
<parentCategory ref=”terminalserver:TS_CONNECTIONS” />
<supportedOn ref=”terminalserver:TS_SUPPORTED_Windows7_Server” />
<decimal value=”1″ />
<decimal value=”0″ />
It’s very probable Microsoft itself was confused: the enablement of the GP setting leads to the enablement of DFSS, while the name of the setting (“Turn off Fair Share CPU Scheduling “) actually indicates the turning off of DFSS instead of DFSS itself…

ATTENTION: in my previous blog post I’ve stated some incorrect statements. The reason for this was I was confused by the TechNet page I was just referring to. I thought the GP setting was always ignored, except when EnableCpuQuota was set to 0. Now you and I know this is completely incorrect.

CU! Pedro.


6 thoughts on “DFSS doesn’t work as expected

    Bill said:
    18/06/2012 at 00:31

    Since your previous blog entry has noted incorrect statements, why not delete the post? Or at least go back and correct it?!

      Padre Pedro said:
      19/06/2012 at 19:09

      Hi Bill. I don’t want to hide the fact I’ve written an incorrect article and you never know why it could still be of some interest (for example, people who have once read the (old) article and come back, could now see how the old and new article compare to each other and get a small feeling of how I could understand things wrong). Once published, it stays published. Of course I definitely add an update remark to the old article to note it’s deprecated, but at the end the content stays available. Thanks anyway for the tip! I appreciate it! 🙂

    Retheesh Andrews said:
    25/04/2013 at 15:18

    I was going through the same tests and figured that your article is absolutely true. I have made sure that DFSS is enabled, and tested the functionality using CPUSTRES, however it is not functioning as expected. Other user sessions are locking up. Do yuo know a way to confirm if DFSS is doing it’s job? Thanks!

    […] DFSS doesn’t work as expected […]

      Padre Pedro said:
      25/11/2013 at 17:25

      Well, that’s what I’m explaining here 🙂 Or is there something you don’t understand form my article? If you have any question, please don’t hesitate to ask! Ciao!

    David Bottomley said:
    05/08/2014 at 10:38

    I’ve found 2 differnent TerminalServer-Server.admx one with what you have above and one with the following.

    I’m not sure where this one originated it might be Windows 2012 or Windows 7.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s