Já considerou a execução do aplicativo como um serviço? O serviço poderia então ser configurado para usar seu determinado usuário / passe e você não teria mais que fazer malabarismo entre as sessões para mantê-lo funcionando especificamente.
Eu tenho um aplicativo do Windows que deve ser executado em um determinado usuário / senha em um servidor que executa o Windows Server 2000 e outro em um Windows Server 2003. Esse é um aplicativo crítico e deve estar em execução 24 horas por dia, 7 dias por semana.
Sempre que preciso gerenciar o servidor, preciso fazer o login usando as credenciais dessa conta para evitar o fechamento do aplicativo, pois é um aplicativo do Windows que mostra muitas informações e não pode ser executado como serviço e, como é um aplicativo de terceiros. Eu não posso mudar seu código para funcionar como um serviço também.
Devido a isso, a conta necessária para executar o aplicativo é o administrador local, o que não é seguro, e todo Anúncio Sys precisa ter suas credenciais, o que também não é seguro, pois não posso acompanhar quem fez o quê.
Eu preciso encontrar uma maneira de manter uma conta sempre conectada e executando o aplicativo [até que alguém explicitamente logue isso, é claro :)] e toda vez que eu precisar verificar algo no aplicativo eu posso logar com esta conta e abrir esta mesma sessão. Mas quando alguém precisa gerenciar o servidor, ele / ela pode se conectar usando a conta de administrador dele, o que não fará logoff da outra conta.
Como posso conseguir isso?
Só para deixar claro:
Eu preciso de uma maneira de acessar duas sessões no servidor (Windows Server 2000 ou superior).
Uma dessas sessões usará uma credencial de conta regular para executar o aplicativo. Esta sessão só pode ser efetuada pelo próprio usuário ou forçada pelo Enterprise Admin. Se alguém logar no servidor, mesmo localmente, ele não fará logoff desta sessão.
Outras contas, como administradores locais, administradores de domínio ou até mesmo usuários comuns, podem abrir uma nova sessão e / ou fazer logon localmente no servidor sem fechar a outra conexão.
Este é o cenário. :)
Já considerou a execução do aplicativo como um serviço? O serviço poderia então ser configurado para usar seu determinado usuário / passe e você não teria mais que fazer malabarismo entre as sessões para mantê-lo funcionando especificamente.
Dependendo do método principal usado para interagir com o servidor (localmente via console ou via RDP), existem duas opções. Tenha em mente que o Windows Server normalmente tem 3 sessões interativas totais - a sessão do console e 2 sessões remotas (a menos que seja um servidor de terminal, caso em que você está limitado por suas CALs, mas não acredito que esteja usando um servidor de terminal neste caso)
Acho que a verdadeira solução de causa raiz do problema é comunicar a todos que têm a capacidade de fazer o logoff desse usuário para NÃO efetuar logout dele. Qualquer administrador que interaja com o servidor será exibido uma mensagem quando fizer login se o "usuário do serviço" estiver usando essa sessão ou não, e terá a opção de fazer logoff ou não. Isso realmente se resume a eles clicando em "Sim" ou "Não", pois se eles são administradores no servidor, eles têm outros meios para fazer logoff do "usuário do serviço" sem interagir diretamente com uma caixa de logon, se eles realmente quiserem. absolutamente nenhuma maneira de contornar isso. Os administradores podem fazer logoff de outros administradores e usuários, e os usuários regulares só podem efetuar logon ou desativação. Isso ocorre por design.
Dado que você não quer que as pessoas façam isso acidentalmente ou pelo menos veja a caixa de diálogo "Sim" ou "Não" com a menor freqüência possível, você pode fazer o login usando a sessão do console ou uma sessão RDP usando a área de trabalho remota. sobre como outros administradores acessam os servidores.
1) Se os administradores geralmente se conectarem aos servidores via área de trabalho remota, você desejará usar a sessão de console para o "usuário do serviço", já que a maioria dos administradores se conectará sem usar a opção / console ou / admin (dependendo da versão do cliente RDP). Eles podem entrar e sair sem entrar em contato com a sessão do "usuário do serviço". Se já houver duas conexões remotas com o servidor, elas não poderão fazer o login e não terão a oportunidade de desconectar o "usuário do serviço". No entanto, se eles usarem a opção / console ou / admin com sua sessão RDP, serão apresentados à janela para desconectar o "usuário do serviço".
2) Se os administradores geralmente interagirem com os servidores diretamente usando a sessão de console, talvez seja melhor usar uma das sessões RDP para registrar o "usuário do serviço". Tenha cuidado com a Configuração dos Serviços de Terminal no servidor localmente ou na Diretiva de Grupo, pois ela pode ser configurada com limites máximos de sessão para registrar a sessão remota após um determinado período de tempo, esteja o usuário ocioso ou não.
Você pode fazer login na conta que executa o aplicativo usando uma sessão remota (RDP) e depois desconectar a sessão.
Eu uso o TweakUI para registrar o usuário no servidor automaticamente e, em seguida, permitir somente uma sessão da Área de Trabalho Remota. Em vez de fazer logoff, basta fechar a janela do RDP, mantendo o usuário logado.
Como Chris_K disse, o que você provavelmente quer é executar o programa como um serviço - que permitirá que ele seja executado em segundo plano com o nome de usuário / senha atribuído sem precisar de um login ativo e sem ir embora ligar / desligar o servidor.
Você precisará de um programa chamado SrvAny, capaz de executar programas arbitrários como serviços. Está disponível diretamente da Microsoft como parte do Windows Server Resource Toolkit.
Uma vez que o SrvAny estiver instalado, você usaria o comando "InstSrv NameOfYourProgram c: \ Path \ To \ YourProgram.exe". Ele será então encontrado na tela Serviços. Você pode entrar em Serviços e definir opções para ele, como nome de usuário e senha.
Concordo que a execução do processo como um serviço seria ideal, já que não exigiria uma sessão totalmente registrada. No entanto, sendo um aplicativo baseado em formulário, isso pode gerar problemas de interatividade (mesmo ao selecionar a opção para permitir que o serviço interaja com a área de trabalho), especialmente em versões mais recentes do Windows, onde essas formas insistem em se apresentar em um ambiente isolado. ambiente de desktop (por motivos de segurança).
Portanto, se o seu aplicativo não responder bem ao executar em um contexto de serviço, uma maneira de contornar isso em versões mais recentes (Vista, Windows Server 2008, etc.) é definir o aplicativo para ser executado como uma tarefa agendada. tarefa está configurada para ocorrer "na inicialização".
E se a execução da tarefa na inicialização ainda não funcionar corretamente para o aplicativo específico, você pode tentar configurar a tarefa para "fazer logon". Nesse caso, você pode combiná-la com a configuração de logon automático sugerida por Bård ( consulte o artigo 315231 do MS KB para obter mais informações ... infelizmente só posso postar um único hiperlink em minhas respostas )
Outra resposta possível:
Use o Editor de Diretiva de Grupo para desabilitar o logout e o desligamento. Isso deve fazer com que você só possa desconectar do RDP, não terminar a sessão (não posso testá-lo aqui para ter certeza, então ymmv aqui)
Configuração do usuário - > Modelos Administrativos - > Menu Iniciar e Barra de Tarefas
Procure as opções "Remover logoff no menu Iniciar" e "Remover e impedir o acesso ao comando Desligar". Ainda será possível fazê-lo a partir da linha de comando - se você quiser REALMENTE bloqueá-lo, também poderá bloquear a linha de comando.
Em link
nós configuramos o autologon em alguns computadores que fazem coisas muito especiais (screengrabs). Pode ser feito com o TweakUI no xp e alguma configuração de registro no Vista.
Iniciar - > Executar - > "control userpasswords2"
Lá você encontrará uma opção para registrar automaticamente um usuário no Windows.
Este usuário receberá a sessão de console, para que um administrador possa fazer login via RDP usando seu próprio nome de usuário / senha e não perturbar a sessão automaticamente conectada.
Acabei de marcar e isso não está mais no Windows 7: - (
Use uma sessão Remote Interactive como descrito em link
O melhor desta configuração é que ela efetua login automaticamente após a reinicialização de um PC ou servidor.
Existem algumas ações que podem ser tomadas para solucionar a solução que você está procurando. SOme foi mencionado aqui, como habilitar autologin.
Suponho que você também possa remover os botões de logoff e desligamento. Você também pode configurar a máquina para efetuar login imediatamente na conta desejada, caso ela seja desconectada. Nós temos algumas máquinas configuradas assim. É muito factível.
Temos uma situação semelhante.
As edições do servidor do Windows já possuem 3 sessões, duas remotas e uma console (que ainda pode ser acessada usando / admin no rdp). As sessões remotas não fazem logoff de outro usuário, mas às vezes, quando alguém se desconecta, em vez de fazer logoff, ele impede que outros usuários se conectem. A sessão / admin sempre permite que alguém se conecte, mas irá desconectar qualquer usuário existente daquela sessão de console, então é bom manter-se livre para permitir que você entre e expulse um usuário inativo.
(Se você quiser mais usuários, então você pode ativar os serviços de terminal)
Além de dar a conhecer a todos para não logar o usuário do aplicativo, temos a configuração de monitoramento nagios para verificar se o aplicativo exe é um processo em execução nessa máquina. Então, se ele for desligado inadvertidamente, receberemos um aviso e poderemos reiniciá-lo novamente.
Tags windows