Mantenha uma VPN do Windows ativa: dispare o rasdial no evento de desconexão
RasClient 20226 e 20227 marcam uma queda; 631 significa que uma pessoa fez isso. Dispare o rasdial nos dois primeiros, guarde uma credencial e leia o código de saída.
O Windows não oferece nenhuma política de rediscagem para o seu cliente VPN, então uma conexão que cai à meia-noite continua fora do ar no café da manhã. Uma tarefa agendada que vigia a desconexão e executa rasdial fecha essa lacuna sem um cliente de terceiros. Se a tarefa se comporta como um operador ou como um ciclo depende de três detalhes: que eventos compara, que credencial consegue ver e o que faz com o resultado. Nenhum dos três é difícil, e falhar qualquer um deles é o que produz uma tarefa que marca para sempre.
Por que um temporizador é o gatilho errado
Um temporizador disca conforme o próprio cronograma, esteja o túnel fora do ar ou não. Isso produz tentativas que ninguém precisava, e uma tentativa durante uma sessão de trabalho pode interrompê-la. Um gatilho de evento dispara apenas quando a conexão muda de estado, o que custa menos e é mais fácil de raciocinar. O evento também carrega o motivo, e o motivo é o que separa uma falha de rede de uma pessoa que se desconecta de propósito.
Essa distinção é a diferença entre uma tarefa útil e uma que briga com o usuário todas as noites. Também é a parte que costuma faltar nas receitas que descrevem apenas a ação.
O par de eventos, e o que deve ser suprimido
O cliente do Serviço de Acesso Remoto grava registros de ciclo de vida no log Application sob o provedor RasClient. 20226 marca uma conexão encerrada, e 20227 marca uma tentativa que falhou, então qualquer um dos dois pode justificar uma nova discagem. Todo o resto na tarefa depende de casar esses dois identificadores exatamente. Eles são estáveis há anos, por isso as receitas construídas sobre eles ainda circulam, mas uma compilação que renomeia o provedor ou os identificadores faz a consulta não devolver nada. Execute novamente a etapa de prova após cada atualização de recurso, em vez de esperar a tarefa parar de disparar.
Uma terminação precisa ser excluída. O erro 631 significa que o usuário desconectou a porta, e uma rediscagem naquele momento briga com a pessoa que acabou de trocar de rede de propósito. Coloque a exclusão no filtro do gatilho e não no script, para que a tarefa nem comece. Ela precisa valer para um único ID de evento, porque um predicado EventData só casa quando o elemento nomeado existe, e uma cláusula compartilhada descartaria silenciosamente todo evento do outro ID. Leia o nome do elemento em um registro real antes de escrever o filtro:
Get-WinEvent -LogName Application -MaxEvents 5 -FilterXPath "*[System[Provider[@Name='RasClient'] and EventID=20226]]" | Select-Object -First 1 -ExpandProperty ToXml
O XML mostra os nomes exatos de Data naquele registro. ErrorCode é a grafia usual, e um registro que usa outra coisa precisa que esse nome seja substituído no filtro abaixo.
<QueryList><Query Id="0" Path="Application"><Select Path="Application">*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])</Select></Query></QueryList>
Cole isso no filtro personalizado do gatilho e prove como consulta antes que ele se torne um gatilho. O mesmo XPath roda do PowerShell contra o log em tempo real, que é a forma barata de ver com o que ele casa enquanto o histórico de tarefas ainda não está envolvido.
Get-WinEvent -LogName Application -MaxEvents 40 -FilterXPath "*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])" | Select-Object TimeCreated,Id,Message
Um gatilho que silenciosamente não casa com nada parece exatamente uma tarefa que roda e falha. Os dois aparecem como "a automação não funciona", e nenhum diz qual metade está faltando. Verifique primeiro a saída da consulta, porque ela separa os dois casos em um único passo.
A discagem falha porque não há ninguém para digitar a senha
A ação executa rasdial com o nome da conexão. Quando o perfil não tem credencial em cache, a discagem falha imediatamente porque não há ninguém para responder ao prompt. É o motivo mais comum de uma tarefa disparada corretamente não fazer nada visível, então verifique isso antes de mexer no gatilho. Discar manualmente a partir de um prompt de comando separa um problema de credencial de um problema de agendamento.
Salve a credencial uma vez sob a conta com a qual a tarefa vai rodar, e faça dessa conta parte do projeto. Uma tarefa que roda como SYSTEM não consegue ler uma credencial armazenada em cache pela sua conta interativa, e uma tarefa que roda como outra pessoa também não. O nome também precisa casar exatamente com o perfil, incluindo qualquer prefixo de domínio no campo de usuário.
rasdial
rasdial "Office VPN"
(Start-Process rasdial -ArgumentList '"Office VPN"' -Wait -PassThru -NoNewWindow).ExitCode
O primeiro comando lista os nomes que o Windows conhece. O segundo disca por nome usando a credencial em cache, e o terceiro é a forma que uma ação do PowerShell deve usar, porque espera e devolve um valor que a tarefa pode registrar.
Leia o código de saída em vez da janela
Uma tarefa que inicia um processo sem esperar relata sucesso assim que o processo existe. Para uma discagem que pode falhar um segundo depois, esse veredito não vale nada. Esperar pelo código de saída transforma a ação em um resultado real. O histórico de tarefas sozinho mostra apenas que um processo começou, nunca que um túnel subiu.
Registre o valor com um carimbo de data e hora em cada execução. Uma única falha após uma queda é normal, enquanto três falhas seguidas com o mesmo código apontam para a credencial ou o perfil e não para a rede. É esse padrão que torna o histórico digno de leitura.
Adicione um intervalo curto de repetição como seguro, e seja explícito sobre como ele interage com um gatilho de evento. Uma repetição a cada minuto por cinco minutos fornece a segunda tentativa quando a internet voltou junto com o túnel, e em Configurações, "Se a tarefa já estiver em execução, a regra a seguir se aplica", a tarefa quer "Não iniciar uma nova instância" para que uma repetição não se sobreponha a uma discagem ainda em andamento. Sem essa configuração, dois processos rasdial podem disputar a mesma porta e o segundo falha sem nenhum motivo útil.
Comprove o caminho de recuperação
Teste as duas direções de propósito. Desconecte à mão e confirme que nenhuma rediscagem acontece, depois desative o adaptador de rede e confirme que a tarefa dispara quando o link volta. Esses dois testes cobrem a regra de supressão e o caso real de falha, e nada mais faz isso.
Depois leia o histórico de tarefas em vez do ícone de conexão. O histórico registra quando a tarefa rodou, qual conta usou e o que a ação devolveu, e essa é a evidência necessária quando a mesma máquina cair de novo no mês que vem.