Вопросы Теги

Различие между HKLM:\SOFTWARE\Policies\и HKLM:\SYSTEM\CurrentControlSet\

В чем различие между изменением настроек HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services и HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server?

Подобные настройки, кажется, появляются в обоих. Например, fSingleSessionPerUser ключ для служб удаленных рабочих столов. В Сервере 2012R2 единственный способ измениться это через локального редактора политики (объект Средств администрирования, который был в Server, 2008 не стало). Я предполагаю, что использование gpedit.msc изменяется HKLM:\SOFTWARE\Policies область.

Установка политики действует как маска для другой установки, вызывая его к определенному состоянию если существующий?

Сервер не является частью домена.

Если я пишу сценарии, чтобы загрузить новую машину и хотеть настроить эту установку, которая является лучшим местом для изменения ее?

2
задан 4 August 2014 в 11:19
4 ответа

Это то место, где я бы сделал изменение, в месте CurrentControlSet. Вам не нужен gpedit.msc или что-то особенное, просто настройка реестра.

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

и для повторного включения, установите его на '1'.

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

EDIT

Следует отметить, что групповая политика действительно вносит изменения в расположение политики. Смотрите файл .adm для более подробной информации - C:\Windows\PolicyDefinitions\TerminalServer.admx Это по замыслу, не смотря ни на что, я бы все равно внес изменения в текущий набор управления. Причина, по которой компании Microsoft понадобилось второе место для размещения групповых политик, чтобы они могли переопределять реальный параметр без татуировки реестра, как это было в 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>
2
ответ дан 3 December 2019 в 11:41

Я не могу это подтвердить, однако ключ реестра "Политики" предназначен для групповой политики и будет иметь преимущественную силу. Ключ реестра должен быть защищен от изменений пользователей, и, в зависимости от реализации на программном уровне, он также может предотвращать изменения внутри приложения.

Есть и другие соображения в отношении ключа "Политики" - например, он должен быть очищен, когда групповая политика перестает применяться. Я знаю по опыту, что ключи останутся в рабочей группе, но я не уверен, что произойдет, если вы присоединитесь к домену и начнете применять другие политики

Другими словами, Можно использовать и то, и другое, но если вы пытаетесь внедрить параметры для всех пользователей и не собираетесь присоединять машину к домену, то политики, как правило, будут лучшим выбором. Если вы, возможно, присоединяетесь к домену или внедрение не является вашей основной задачей, тогда придерживайтесь ключа "Control" (Контроль)

.
2
ответ дан 3 December 2019 в 11:41

Согласно данным компании Microsoft, HKLM\SOFTWARE\Policies дерево реестра "содержит записи, которые хранят настройки групповой политики", в то время как HKLM\SYSTEM\CurrentControlSet\Control дерево реестра "содержит информацию для управления запуском системы и некоторыми аспектами конфигурации устройств". На практике это означает, что дерево Policies, как правило, не следует редактировать напрямую, если только у вас нет на то веских оснований, поэтому в общем случае вы должны вносить свои изменения в дерево реестра Control. Однако, настройки в дереве Policies будут иметь приоритет над конфликтующими настройками в дереве Control, поэтому, если вы обеспокоены тем, что машина получает конфликтующие настройки откуда-то, это будет "веской причиной" для внесения ваших изменений в дереве Policy, а не в дереве Control.

В противном случае, нет никакой разницы между ними, и существует множество настроек, которые можно настроить из любого из деревьев реестра.

.
0
ответ дан 3 December 2019 в 11:41

По моему опыту (среда домена), где нет явных объектов групповой политики, установленных в дереве политик, когда вы устанавливаете два конфликтующих ключа в политиках и контроле, ключи управления выигрывают.

-2
ответ дан 3 December 2019 в 11:41

Теги

Похожие вопросы