Script de reinicialização automática do Windows 2000 Server

Question

Estou executando um aplicativo de rede legado em um sistema operacional de servidor antiquado (Win2k Web Server) rodando fora do site. O aplicativo é um produto comercial (ou seja, eu não tenho a fonte) que foi descontinuado pelo desenvolvedor, mas a minha empresa ainda depende dele porque não há produto melhor no mercado para esse produto extremamente específico. O problema é que ele falha a cada poucos dias e sempre nos piores momentos (fins de semana, 3h, etc) e eu preciso fazer login no servidor via RDC e reinicializar o servidor e reiniciar o aplicativo manualmente assim que o servidor voltar. O servidor não faz nada além de hospedar este aplicativo. Eu tentei no win2k3 e ele ainda trava, então uma mudança de sistema operacional não vai ajudar.

Estou tentando automatizar esse servidor para reinicializar e, em seguida, reinicie o aplicativo quando ele descobrir que o aplicativo morreu. Eu tenho um método de detectar quando este aplicativo morreu e tem a capacidade de executar qualquer tipo de script / exe naquele momento. O aplicativo não pode ser executado como um serviço (eu tentei fazer isso funcionar, mas não há chance). Ele tem que ser executado na área de trabalho do usuário do RDC e não há como evitar isso porque preciso interagir com ele frequentemente na área de trabalho. Então:

1: Reconhecer quando o aplicativo está morto (concluído) 2: Reinicie o servidor automaticamente quando isso é feito (simples, feito) 3: Quando o servidor concluir a reinicialização, abra este aplicativo na área de trabalho RDC de um usuário de nível de administrador.

A minha pergunta formal é: como faço # 3?

Qualquer conselho seria extremamente bem-vindo e apreciado.

    

Answer 1

Eu vou dizer o que os outros disseram, mas um pouco diferente, já que eu fiz exatamente isso com um par de programas horríveis (ambos são programas de pesquisa para relógios de tempo - o que é isso? com programas que pesquisam relógios de tempo sendo uma droga? :):

• Faça logon no computador servidor como o usuário que executará o aplicativo. Defina o protetor de tela do usuário para ser seguro (isto é, exigir uma senha). Você provavelmente deve usar "tela em branco" para economizar CPU.

• Coloque atalhos no seu script para iniciar o aplicativo e testar sua "vitalidade" no grupo "Inicialização" de "Todos os usuários". (Certifique-se de que seu script forneça ao aplicativo tempo suficiente para iniciar, antes de verificar se está "morto").

• Pegue uma cópia do "nircmd" de link e jogue-o no diretório% SystemRoot% \ System32 (ou em qualquer lugar, na verdade). Adicione um atalho ao grupo "Todos os usuários" "Inicialização" para chamar:

  Protetor de tela

  % SystemRoot% \ system32 \ nircmd.exe

• Adicione os seguintes valores do registro, substituindo o nome de usuário e a senha apropriados.

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
    AutoAdminLogon - REG_SZ - 1
    DefaultUsername - REG_SZ - Set to user name to logon with
    DefaultPassword - REG_SZ - Set to password to logon with
    DefaultDomain - REG_SZ - Set to either local machine's name if a local account is used to logon, or domain's name if a domain account is used to logon.
    ForceAutoLogon - REG_SZ - 1

• Modifique a permissão na chave NT \ CurrentVersion \ Winlogon de HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows (usando REGEDT32) para remover os grupos "Usuários avançados" e "Usuários" da ACL nessa chave. (Eu apenas testei isso em uma máquina W2K, e isso não atrapalhou o autologon). Isso impedirá que a senha de texto simples seja lida por um usuário de acesso limitado na caixa.

Neste ponto, o computador inicializará e fará logon automaticamente como o usuário que você especificou, iniciará o aplicativo e seu script "deadness" e entrará imediatamente em um protetor de tela bloqueado. A chave que está sendo mantida durante a inicialização não irá parar o auto-login (mas, como esta está fora do local, esperamos que o teclado / mouse esteja protegido de qualquer maneira).

Se você pode executá-lo no W2K3, você pode usar o argumento "/ admin" ou "/ console" no cliente da Área de Trabalho Remota (dependendo de qual versão você tem-- faça um "/?" para ver) para conectar para a sessão de console. Você precisará fazer logon com o mesmo nome de usuário e senha usados pela conta de logon automático, e qualquer pessoa que não tenha esse nome de usuário e senha não poderá se conectar à sessão de console.

Se você tiver que continuar executando-o no W2K, instale algo como o VNC, para poder controlar remotamente a sessão do console. Se você usar VNC, certifique-se de modificar a permissão na chave do registro onde a configuração VNC da máquina está armazenada (HKEY_LOCAL_MACHINE \ Software \ ORL \ Winvnc para versões mais antigas, outros locais para versões mais recentes) para remover "Usuários" e "Usuários avançados" "da ACL da chave. Isso impedirá que os usuários com acesso limitado acessem o hash da senha do VNC, que pode ser facilmente revertido para a senha do VNC.

É assim que eu faria.

    

Answer 2

A chave aqui é a segurança - em suma, você não terá nenhuma se seguir estas instruções.

As etapas são: 1. Login automático. 2. Execute um arquivo em lote (cmd) que inicie seu programa quando fizer o login.

Para login automático - basta usar o TweakUI - é apenas um monte de arquivos de registro, mas o TweakUI é a melhor maneira de escrevê-los bem.

Para o arquivo em lote, basta escrever um arquivo cmd que execute seu programa e colocá-lo na pasta "Start up" no diretório "Todos os usuários".

Haverá maneiras mais sofisticadas de fazer isso, mas esse mecanismo de baixa tecnologia funcionará, mas comprometerá 100% a segurança do servidor!

Mike

    

Answer 3

Temos que fazer isso em alguns sites e usamos o login automático sugerido por Mike.

Como você é de Linux, talvez seja importante ressaltar que o login automático fornece automaticamente um nome de usuário e uma senha para a sessão interativa quando o servidor é iniciado, ou seja, é como se alguém se sentasse no servidor, pressionado ctrl. alt-delete e logado no servidor. O aplicativo é executado a partir da pasta de inicialização, assim como para qualquer usuário interativo.

NB RDC não está envolvido. É um logon interativo.

Obviamente, a segurança agora não existe, pois qualquer um pode ir até o servidor e começar a digitar. No entanto, você pode definir a proteção de tela para um tempo limite muito curto, para que ela bloqueie rapidamente a sessão interativa. O único risco de segurança é se alguém estiver assistindo ao reinício do servidor e conseguir capturá-lo no intervalo entre o login automático e o protetor de tela.

JR

    

Answer 4

Que tal colocar seu aplicativo em um servidor virtual; VMWare ou Hyper-V e usando o login automático descrito por Mike?

Eu só pensei nisso depois de postar minha primeira resposta, mas se você colocar seu aplicativo em um servidor virtual, poderá executá-lo na sessão interativa e não haverá risco de segurança porque a máquina virtual não tem teclado nem mouse.

JR

    

Answer 5

Uma alternativa popular ao RDP nesse cenário é o VNC, que permite conectar-se à sessão do console, esteja ela conectada ou não.

Eu acredito que o VNC pode ser moderadamente seguro, dependendo de qual versão você usar, e é FLOSS.

• Use o TweakUI para criar um autologon, uma conta local não uma conta de domínio.
• Adicione um atalho ao aplicativo ao grupo de inicialização no menu inicial da conta de logon automático.

Você pode tentar TightVNC , UltraVNC , RealVNC , WinVNC ...