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

Eu tenho um programa que é iniciado na inicialização do sistema usando o Agendador de tarefas no Windows Server 2012. O programa deve ser iniciado mesmo se o computador reiniciar 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 bastante 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 fizer logon?

Outras idéias?

(Eu não quero ter que criar um programa separado apenas da GUI que se conecte ao programa original a propósito. Também preferiria que não precisasse finalizar o programa já em execução no logon do usuário e iniciar isso de novo.)

Descobri como fazer isso sozinho. É uma solução alternativa, mas é o que eu esperava obter.

• Tudo bem, o primeiro passo é pegar um programa chamado AutoLogon.exe da Microsoft:
  http://technet.microsoft.com/sv-se/sysinternals/bb963905.aspx

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

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

• Crie uma tarefa no Agendador de tarefas. Configure-o para executar apenas quando o usuário (Administrador) estiver conectado. O gatilho está "no logon" e especifica que é apenas quando o administrador faz logon.

• Crie uma segunda tarefa. Executar apenas quando o usuário estiver conectado, acionar no logon 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 faz logon automaticamente, o programa que você deseja iniciar é iniciado e a estação de trabalho fica bloqueada. Se eu fizer login via Conexão de Área de Trabalho Remota, posso ver a janela do programa e usar a GUI. 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 (ela não cria um loop infinito de log-in-lock-lock, do qual você não pode sair).

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

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

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

Como posso resolver isso?

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 se conecta ao serviço. A interface do usuário em execução no espaço do usuário conectado faz a apresentação, o serviço Windows faz o processamento. É assim que o modelo é projetado por talvez 15 anos ou mais.

Estou bastante surpreso que a Microsoft permita tal limitação em seu agendador.

Fico mais surpreso por você nunca ter perguntado o porquê.

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 ele pode executar o código lá. O modelo de mensagens do Windows está cheio de problemas.

Eu não quero ter que criar um programa separado apenas por GUI que se conecte ao programa original a propósito.

Nem eu nem a Microsoft se preocupam com o que você gosta de fazer. Existe um modelo estabelecido e suportado para vincular o processamento em segundo plano a uma interface de usuário conectada - use-o ou não. Mas quando não, não reclame dos problemas de segurança que você coloca.

É tudo sobre o Sessionqual o seu programa é executado. Se ninguém está logado, não há uma sessão interativa para exibir, acredito que ele é executado sob Session 0, que tem uma interface estranha que não aparece como as outras.

Agora, se o seu programa detectar quando é explorer.exeiniciado (ou alguma outra maneira de detectar o logon do usuário) e se remodelar magicamente ou gerar algum processo filho no novo ID da sessão, qualquer pessoa que fizer login verá com satisfação o que você está fazendo.