Executar uma tarefa quando a VPN se conecta: evento, sondagem ou credencial?

Um script de início de sessão que mapeia uma unidade ou inicia uma tarefa de sincronização é executado antes de o túnel ter endereço, pelo que falha silenciosamente e o utilizador repara-o à mão todas as manhãs. O Windows não oferece à maioria dos clientes qualquer callback de ligação por VPN, mas registra a alteração de rede, e esse registo pode iniciar o trabalho no momento certo. A escolha está entre reagir a esse registo, sondar o recurso e remover o pedido que tornava a falha visível.

Comparar os três mecanismos pelo que garantem supera ordená-los pela elegância. Cada um falha de forma diferente, e o modo de falha é aquilo com que se vive depois.

Porque é que o início de sessão dispara demasiado cedo

O início de sessão e o arranque executam-se antes de o adaptador VPN receber o seu endereço, pelo que um mapeamento de unidade, um URL interno ou uma ligação a base de dados tentados nesse momento não têm rota nem resolvedor. O pedido falha, e a sessão fica num estado que o utilizador tem de reparar manualmente. Mover o mesmo script para a pasta de arranque não muda nada, porque o problema de ordem viaja com ele. O acionador tem de ser uma alteração de rede e não um evento de sessão.

Uma tarefa agendada no início de sessão com um atraso arbitrário parece uma correção e na realidade é um palpite. Funciona numa ligação rápida e falha numa lenta, que é o tipo de fiabilidade menos útil.

Três ganchos comparados

Os mecanismos diferem no que observam, na rapidez com que reagem e no que fazem quanto a uma reconexão mais tarde no dia. A tabela compara-os nesses três pontos e não no quão engenhoso cada um soa.

Leia a tabela linha a linha. O gancho de evento é o mais rápido e o mais ruidoso, já que o Windows registra todas as redes, incluindo a Wi-Fi do café, pelo que a ação tem de verificar o recurso antes de fazer o que quer que seja. A sondagem é mais lenta e mais precisa, porque só tem sucesso exatamente quando a partilha ou o nome do anfitrião responde, e não precisa de saber que cliente está instalado. As credenciais guardadas não são de todo uma opção concorrente: removem o pedido de palavra-passe, que é um segundo motivo independente para um mapeamento no início de sessão falhar.

Escolher entre os dois primeiros depende de existir um evento utilizável no cliente. Onde existe, um evento mais uma verificação do recurso é a melhor predefinição.

Construa corretamente o acionador de evento

O registo está no log Microsoft-Windows-NetworkProfile/Operational, e o ID 10001 marca uma rede que acabou de ligar. Crie a tarefa com um acionador Ao ocorrer um evento dirigido a esse log, a esse nome de fornecedor e a esse identificador. Todas as redes a que a máquina se ligar o irão disparar, pelo que a ação precisa de uma cláusula de proteção e não de uma suposição, e só deve correr enquanto o utilizador tem sessão iniciada se o trabalho tocar em unidades mapeadas.

A cláusula de proteção deve testar o que a tarefa realmente precisa, como um caminho de partilha ou uma porta de serviço, e sair em silêncio quando não estiver acessível. Testar o nome do adaptador não chega, porque um cliente pode reutilizar um adaptador em vários perfis. Uma saída silenciosa mantém o registo legível e evita uma tempestade de novas tentativas contra uma rede que nunca servirá o recurso.

Teste que a tarefa corre no momento certo

Prove o momento e não a configuração. Os comandos abaixo mostram a definição da tarefa, os eventos recentes do perfil de rede e se o recurso está acessível a partir da conta em que a tarefa corre. Execute-os após uma reconexão real e não após um arranque manual.

schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoami

Uma entrada no histórico de tarefas que existe enquanto nenhum evento de rede corresponde significa que o acionador está errado e não a ação. Se os eventos aparecem e a tarefa não corre, a tarefa pode estar a correr sob uma conta que não vê o recurso, e a saída da conta é a pista. Uma verificação do recurso que passa enquanto o mapeamento ainda falta aponta para o contexto de sessão e não para a conectividade. Cada uma dessas três observações leva-o a uma correção diferente.

Escreva uma linha de registo por execução com o endereço, o resultado do recurso e o desfecho. A falha seguinte mostrará então se a tarefa correu cedo, correu na rede errada ou não correu de todo.