Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
2  
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. –  jscott Aug 4 '14 at 14:53

4 Answers 4

up vote 2 down vote accepted

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>
share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

From my experience (domain environment), where there are no explicit GPOs set on the Policies tree, when you set two conflicting keys in Policies and Control the Control keys win.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.