Diferença entre HKLM: \ SOFTWARE \ Policies \ e HKLM: \ SYSTEM \ CurrentControlSet \

Question

Qual é a diferença entre editar configurações em HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services e HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server ?

Configurações semelhantes parecem aparecer em ambos. Por exemplo, a chave fSingleSessionPerUser para serviços de terminal. No Server 2012R2, a única maneira de alterar isso é por meio do editor de diretivas local (o item Ferramentas Administrativas que estava no Server 2008 desapareceu). Eu assumo o uso gpedit.msc muda a área HKLM:\SOFTWARE\Policies .

A configuração de política age como uma máscara para a outra configuração, forçando-a a um estado específico, se presente?

O servidor não faz parte de um domínio.

Se eu estiver escrevendo scripts para inicializar uma nova máquina e quiser configurar essa configuração, qual é o melhor lugar para alterá-la?

    

Answer 1

Aqui é onde eu faria a alteração, no local CurrentControlSet. Você não precisa de gpedit.msc ou nada de especial, apenas uma configuração de registro.

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

e para reativar, defina-o de volta para "1".

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

EDITAR

Deve-se observar que a política de grupo faz a mudança no local da política. Veja o arquivo .adm para obter maiores detalhes - C:\Windows\PolicyDefinitions\TerminalServer.admx Isso ocorre por design, independentemente, eu ainda faria a alteração no currentcontrolset. A razão pela qual a Microsoft precisava de um segundo local para abrigar as políticas de grupo para que pudessem superar a configuração real sem realmente tatuar o registro como em nt4 dias.

<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>

    

Answer 2

Não estou em posição de confirmar isso, no entanto, a chave do Registro "Políticas" foi criada para a Diretiva de Grupo e terá precedência. A chave de registro deve ser protegida das alterações do usuário e, dependendo da implementação em um nível de software, também pode impedir alterações no aplicativo.

Existem outras considerações em relação à chave "Políticas" - por exemplo, ela deve ser desmarcada quando uma Política de Grupo parar de ser aplicada. Eu sei por experiência que as chaves ficarão lá enquanto estiver em um grupo de trabalho, mas não tenho certeza do que acontecerá se você fizer uma junção de domínio e começar a aplicar outras políticas.

Em outras palavras, ambos podem ser usados, mas se você estiver tentando impor uma configuração para todos os usuários e não pretender unir a máquina ao domínio, as Políticas geralmente serão a melhor opção. Se você pode ingressar no domínio ou não é sua principal preocupação, siga para a tecla "Control".

    

Answer 3

Segundo a Microsoft, a % árvore de registro HKLM\SOFTWARE\Policies "contém entradas que armazenam configurações de Diretiva de Grupo" , enquanto a HKLM\SYSTEM\CurrentControlSet\Control árvore de registro "contém informações para controlar a inicialização do sistema e alguns aspectos da configuração do dispositivo ".

Em termos práticos, isso significa que a árvore Policies geralmente não deve ser editada diretamente, a menos que você tenha uma boa razão, portanto, no caso geral, você deve fazer as alterações na árvore de registro Control . No entanto, as configurações na árvore Policies terão precedência sobre as configurações conflitantes na árvore Control , portanto, se houver uma preocupação sobre a máquina ter configurações conflitantes em algum lugar, isso seria uma "boa razão" para fazer as alterações em Policy em vez de Control .

Caso contrário, não há diferença entre os dois, e há muitas configurações que podem ser configuradas a partir da árvore de registro.

    

Answer 4

Da minha experiência (ambiente de domínio), onde não há GPOs explícitos definidos na árvore de diretivas, quando você define duas chaves conflitantes em Políticas e controla as chaves de controle.