O objetivo aqui é iniciar um aplicativo .NET simples que escrevi, que captura algumas variáveis de ambiente (hora, nome de usuário, nome do computador, etc.) no login. Este aplicativo .NET assina o evento "Logout do usuário" do Windows.
Ao iniciar, a aplicação captura as variáveis acima, e cria um registro em meu banco de dados, no logout (que estou capturando) atualizo outro campo no mesmo registro, com o horário de logout.
O procedimento acima está funcionando exatamente como eu gostaria, quando executo o binário, ele faz sua entrada inicial no log, aguarda o evento de logout e atualiza o mesmo registro.
Restrições, o binário .NET deve poder residir em um ponto de compartilhamento (\server\share\myapp\v1) para que eu possa atualizar o aplicativo para (\server\share\myapp\v2) e simplesmente atualizar o script GPO/Logon .
Meu pensamento inicial foi usar o diretório \domaincontroller\sysvol\ para armazenar o binário e depois atualizar todas as contas de usuário para incluir uma chamada para meu aplicativo. Você consegue ver alguma falha nessa abordagem?
A minha pergunta é a seguinte: Primeiro, há algo de errado com a minha ideia acima? Segundo, em caso afirmativo, qual é a melhor maneira (por meio de política de grupo ou de outra forma) de garantir que esse aplicativo seja iniciado sempre que uma sessão for iniciada em um servidor?
Responder1
Para iniciar sempre que uma sessão for iniciada, o uso de um script de logon baseado em Política de Grupo será suficiente. A única ressalva que descobrimos é que esses scripts especificados em um GPO de usuário parecem ser executados DUAS VEZES se o 'processamento de loopback' estiver ativado para qualquer GPO de objeto de computador aplicável. Como resultado, tivemos que modificar nossos scripts de logon para lidar com esse caso.
Não estou familiarizado com assinaturas de eventos .NET, então não sei se isso significa que o arquivo do aplicativo é mantido aberto durante toda a sessão. Se for esse o caso, atualizar o aplicativo será muito difícil devido ao problema de bloqueio aberto. Se 50 estações estiverem conectadas, o aplicativo terá 50 bloqueios de negação de gravação, o que dificulta a atualização do aplicativo. Este é um exemplo em que manter o aplicativo em sysvol (na verdade, no próprio GPO) pode ajudar, pois lida melhor com esse caso.
No entanto, isso significa apenas que ele será acionado novamente ao sair, mantendo-o em um compartilhamento, deve servir.
Responder2
Não há nada de errado em executá-lo a partir do sysvol.
E criar um script de logon gpo faria exatamente isso por padrão e também garantiria que ele fosse executado. Normalmente, os servidores de terminal possuem vários GPOs e um deles executaria seu script de logon e especificaria o modo de processamento de loopback da política de grupo.