Difference between HKLM:\SOFTWARE\Policies\ and HKLM:\SYSTEM\CurrentControlSet\

Question

What is the difference between editing settings in HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services and HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server?

Similar settings seem to appear in both. For example, the fSingleSessionPerUser key for terminal services. In Server 2012R2 the only way to change this is via the local policy editor (the Administrative Tools item which was in Server 2008 is gone). I assume use gpedit.msc changes the HKLM:\SOFTWARE\Policies area.

Does the policy setting act as a mask for the other setting, forcing it to a specific state if present?

The server is not part of a domain.

If I'm writing scripts to bootstrap a new machine and want to configure this setting, which is the best place to change it?

Solution 1

This is where I'd make the change, in the CurrentControlSet location. You don't need gpedit.msc or anything special, just a registry setting.

Set-ItemProperty -Path "registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name "fSingleSessionPerUser" -Value 0

and to re-enable, set it back to '1'.

Set-ItemProperty -Path "registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name "fSingleSessionPerUser" -Value 1

EDIT

It should be noted, the group policy does make the change in the policy location. See the .adm file for greater details - C:\Windows\PolicyDefinitions\TerminalServer.admx This is by design, regardless, I'd still make the change in the currentcontrolset. The reason being Microsoft needed a second location to house group policies so they could over-ride the real setting without actually tattooing the registry as in nt4 days.

<policy name="TS_SINGLE_SESSION" class="Machine" displayName="$(string.TS_SINGLE_SESSION)" explainText="$(string.TS_SINGLE_SESSION_EXPLAIN)" key="SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" valueName="fSingleSessionPerUser">
  <parentCategory ref="TS_CONNECTIONS" />
  <supportedOn ref="windows:SUPPORTED_WindowsNET" />
  <enabledValue>
    <decimal value="1" />
  </enabledValue>
  <disabledValue>
    <decimal value="0" />
  </disabledValue>
</policy>

Solution 2

I'm not in the position to confirm this, however the "Policies" registry key is designed for Group Policy and will take precedence. The registry key should be protected from user changes and, depending on the implementation at a software level, it may also prevent changes within the application.

There are other considerations with regards to the "Policies" key - for example, it should be cleared when a Group Policy stops applying. I know from experience that the keys will stay there while in a workgroup, but I'm not sure what will happen if you do a domain join and start applying other policies.

In other words, both can be used but if you're attempting to enforce a setting for all users and don't intend to join the machine to the domain then Policies would generally be the better choice. If you may be joining to the domain or enforcement isn't your primary concern, then stick to the "Control" key.

Solution 3

According to Microsoft, the HKLM\SOFTWARE\Policies registry tree "contains entries that store Group Policy settings", whereas the HKLM\SYSTEM\CurrentControlSet\Control registry tree "contains information for controlling system startup and some aspects of device configuration".

In practical terms, that means that the Policies tree should generally not be directly edited, unless you have a good reason, so in the general case, you ought to make your changes under the Control registry tree. However, settings in the Policies tree will take precedence over conflicting settings under the Control tree, so if there's a concern about the machine getting conflicting settings from somewhere, that would be a "good reason" to make your changes under Policy rather than Control.

Otherwise, there's really no difference between the two, and there are a great many settings that can be configured from either registry tree.

Comments

[jscott]

Keys/Values under "Policies" branches are managed by Group Policy. In most instances, the settings in a Policies key will take precedence. You shouldn't modify, by hand, anything under a Policies branch, but it does happen.