Inicie o programa na inicialização do computador quando ninguém estiver conectado e mostre a janela quando alguém fizer logon (OS: Windows)

Question

Eu tenho um programa que é iniciado na inicialização do sistema usando o Agendador de Tarefas no Windows Server 2012. O programa deve iniciar mesmo se o computador for reinicializado automaticamente.

Administrador é a conta usada para iniciar o programa, a opção "Executar se o usuário está conectado ou não" está marcada para a tarefa.

O problema é que, quando alguém finalmente faz logon como administrador usando a Conexão de Área de Trabalho Remota, a interface (janela do programa) fica oculta.

Pelo que entendi, não há como resolver isso usando o Agendador de Tarefas.

Como posso resolver isso?

Deve ser um problema bastante comum, mas não consigo encontrar nada pesquisando na rede. Estou muito surpreso que a Microsoft permita tal limitação em seu agendador. Posso criar um VBScript ou algo que seja executado na inicialização e inicie o programa que ficará visível quando o usuário realmente efetuar logon?

Outras ideias?

(Eu não quero ter que fazer um programa somente GUI separado que se conecta ao programa original, a propósito. Eu também preferiria se eu não tivesse que finalizar o programa já em execução no logon do usuário e, em seguida, inicie-o novamente.)

    

Answer 1

Descobri como fazer isso sozinho. É um pouco de uma solução, mas é o que eu esperava receber.

• Tudo bem, o primeiro passo é pegar um programa chamado AutoLogon.exe da Microsoft: link

Pare! Não se encolha ainda. Leia em ...

• Execute-o, configure-o para que o Administrador faça logon automaticamente.

• Crie uma tarefa no Agendador de Tarefas. Configure para executar somente quando o usuário (Administrador) estiver conectado. O gatilho está "no log on" e especifica que é somente quando o administrador fizer logon.

• Crie uma segunda tarefa. Executar somente quando o usuário estiver conectado, acionar no log do administrador. A ação deve ser "iniciar um programa" e o programa é "C: \ Windows \ System32 \ rundll32.exe" com o campo de argumento definido como "user32.dll, LockWorkStation".

O que acontece agora se você reiniciar o computador é que o Administrador efetue logon automaticamente, o programa que você deseja iniciar seja iniciado e a estação de trabalho seja bloqueada. Se eu fizer login via Conexão de Área de Trabalho Remota, posso ver a janela do programa e usar a GUI. Eu posso bloquear / desbloquear o computador sem problemas e desconectar / reconectar como quiser. Não há problema se eu for ao servidor e efetuar login na estação de trabalho real. Como o administrador já está conectado, a tarefa não será executada novamente (ele não cria um loop infinito de log-in-lock que você não pode abrir).

Simples assim. Concedido há um segundo período de tempo antes de o computador ficar bloqueado após o login automático e eu acho que um hacker profissional com acesso físico ao computador poderia fazer algo furtivo durante este período de tempo, mas no meu caso eu posso ignorar esse risco de segurança. Desde que eu não deixe nenhum hacker profissional entrar em minha casa e mostre a eles o computador, o sistema deve ser relativamente seguro. Acima de tudo, não há muito valor no computador que precise de proteção de proteção excessiva, por isso estou muito feliz com essa solução.

    

Answer 2

I have a program that is launched on system startup using Task Scheduler on Windows Server 2012. The program must start even if the computer reboots automatially.

Então por que você não faz dele um serviço de sistema, como as especificações do Windows definem?

How can I solve this?

Você não pode. Os programas em segundo plano não devem interagir com a interface do usuário. Ou: a interface do usuário deve executar seu próprio programa que, em seguida, se conecta ao serviço. A interface do usuário em execução no espaço do usuário do usuário conectado faz a apresentação, o serviço do Windows faz o processamento. É assim que o modelo é projetado por cerca de 15 anos.

I'm pretty surprised that Microsoft allow such a limitation in their scheduler.

Estou mais surpreso por você nunca ter perguntado por quê.

Existem vários problemas:

• Quando várias pessoas estão conectadas, quem recebe a interface do usuário?
• Quando o usuário efetua logout, você mata o programa? OUCH.
• Segurança. O programa em segundo plano pode ser executado sob direitos limitados - expor a interface do usuário ao usuário significa que o usuário pode executar o código lá. O modelo de mensagens do Windows é - ah - cheio de problemas.

I don't want to have to make a separate GUI-only program that connects to the original program by the way.

Nem eu nem a Microsoft nos preocupamos com o que você gosta de fazer. Existe um modelo estabelecido e suportado para vincular o processamento em segundo plano a uma interface do usuário conectada - use-a ou não. Mas quando não, não complemente os problemas de segurança que você colocou.

    

Answer 3

É tudo sobre o Session em que seu programa é executado. Se ninguém está logado, não há sessão interativa para exibir, eu acredito que ele é executado em Session 0 , que tem uma interface estranha que não mostra como os outros.

Agora, se o seu programa detectar quando explorer.exe é iniciado (ou alguma outra forma de detectar o login do usuário) e se rememorar magicamente ou gerar algum processo filho nesse novo ID de sessão, qualquer pessoa que efetuar login verá o que você está fazendo.