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
- 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):
Named value: EnableDFSS
- 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).
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.