Armazenar scripts de GPO no Netlogon ou pasta de diretiva?

Question

A melhor prática é armazenar os scripts de logon centralmente em \DOMAIN\Netlogon ou na pasta de diretivas que eles colocam por padrão, por exemplo. \DOMAIN\SysVol\DOMAIN\Policies\{DE22B6FB-315E-4C55-BF06-A7709913CD9E}\User\Scripts\Logon ?

Quais são as implicações (se houver) de escolher um local em detrimento do outro?

Estou inclinado a apenas mantê-los todos no Netlogon para facilitar o acesso / revisão ...

    

Answer 1

O local padrão para os scripts de logon usuário é o compartilhamento NETLOGON, que, por padrão, é replicado em todos os DCs da sua floresta e está fisicamente localizado em %SystemRoot%\SYSVOL\sysvol\<domain DNS name>\scripts .

Se você definir um script de logon usuário (ADUC > User > Propriedades > Logon > Logon-Script > hello.cmd), ele será executado a partir do NETLOGON.

A melhor prática "oficial" é:

• armazene-os junto com o GPO, se você configurá-lo por meio do GPO.
• armazena-os no NETLOGON, se você definir como uma propriedade do usuário no AD.

Answer 2

Ambos os locais são sincronizados entre o controlador de domínio, portanto, para mim, é apenas uma escolha pessoal.

A opinião do meu pessoal é que depois de um certo número de GPO, ter tudo no netlogon pode ser difícil de gerenciar. (como quando você exclui um GPO, o script não seria apagado no exemplo)

    

Answer 3

Não tenho certeza se isso é "melhor prática", mas eu vi alguns posts recomendarem isso, e eu prefiro isso:

Temos um compartilhamento de arquivos que contém todos os arquivos de suporte dos nossos GPOs, incluindo scripts. Todos os scripts são verificados no controle de versão.

O compartilhamento de arquivos é configurado com o DFS, por isso é \ domain.com \ DFS \ GPO-Files

Os scripts estão em um subdiretório.com \ DFS \ GPO-Files \ Scripts

No GPO, você chama o script "powershell.exe" e os parâmetros que você faz -File PathToScript.

Eu gosto dessa abordagem porque os arquivos e scripts de GPO estão em um local bem conhecido, não enterrados em uma pasta com um nome de GUID.

Ele também permite mais controle sobre como o powershell.exe é chamado, como o ExecutionPolicy.