Ligar-se à VPN não repete o seu script de início de sessão

O seu utilizador inicia sessão em casa, liga-se à VPN e espera o mapeamento da unidade que antes aparecia sozinho no escritório. O túnel sobe, o domínio responde e nada é mapeado. Nada está avariado: um script de início de sessão é executado no início de sessão, e um túnel aberto vinte minutos depois do início da sessão não é um início de sessão. Ler os dois como o mesmo evento envia as pessoas à procura de uma avaria de VPN que não existe.

Quatro decisões transformam a surpresa num fluxo de trabalho que se comporta, e a primeira é simplesmente saber sobre que eventos cavalga um script.

Os scripts cavalgam eventos do ciclo de vida que não pode reproduzir

A política do lado do computador é aplicada quando a máquina arranca e a do lado do utilizador quando alguém inicia sessão, enquanto uma atualização em segundo plano percorre as mesmas definições sem reiniciar nada. Essa atualização processa a extensão de scripts, mas não volta a executar os scripts individuais, que só disparam no arranque, no encerramento, no início ou no fim de sessão. Por isso gpupdate /force pode reportar sucesso enquanto o mapeamento continua ausente, e uma atualização limpa não é prova de que o script fez alguma coisa.

A referência da Microsoft sobre o processamento de políticas traça exatamente essa linha entre processar a extensão e executar o que ela contém, e é a página a citar quando alguém insiste que uma atualização deveria ter repetido o script.

Também não falha todo o script sem rede. Um que só lê material local ou em cache pode ter tido êxito parcial, enquanto um que toca numa partilha falha em silêncio e não deixa marca evidente. Verifique o caminho real do script e até onde chega antes de culpar a rede. A mesma verificação é devida a qualquer afirmação de que um script não é executado no início de sessão, porque uma tarefa agendada ou uma ação do cliente pode estar a fazer o trabalho onde ninguém olha.

Ligue o trabalho à ligação, não ao início de sessão

Três trabalhos diferentes escondem-se atrás da expressão script de início de sessão: mapear uma unidade depois de o utilizador se ligar, aplicar a configuração da máquina antes de alguém iniciar sessão e obter a política atualizada. Têm prazos diferentes, e só o segundo precisa realmente de conectividade antes do início de sessão. Escreva o requisito como uma frase com um prazo, por exemplo: este mapeamento tem de existir dentro de um minuto após a subida do túnel.

Para o trabalho que tem de acontecer após a ligação, use uma tarefa desencadeada pela ligação ou a ação de ligação suportada pelo cliente. Verifique que evento o cliente emite realmente, porque um evento levantado pelo cliente VPN nativo do Windows não é levantado por um cliente de terceiros. Para a configuração da máquina que tem de preceder o início de sessão, a resposta suportada é um túnel de dispositivo ou outro desenho pré-início de sessão, não uma tarefa que dispara quando o ambiente de trabalho aparece. Execute o trabalho na identidade e na sessão que dele precisam, porque um mapeamento criado como SYSTEM acaba numa sessão que o utilizador nunca vê.

Teste a prontidão antes de agir, e falhe em voz alta

Um evento de ligação pode chegar antes de o DNS ou o servidor de ficheiros estar utilizável, por isso a tarefa deve testar o que precisa em vez de presumir. Resolva o nome concreto, tente a ligação concreta e repita com um limite e um atraso: Resolve-DnsName files.corp.example dentro de um ciclo curto separa ainda-não de nunca. Comunique uma falha concreta após a última tentativa, com o nome e o erro lá dentro.

Um ciclo infinito sem registo é indistinguível de uma tarefa que nunca começou, e esconde a diferença entre uma credencial expirada e uma regra de firewall.

Verifique quatro coisas e depois torne-o repetível

Durante o piloto, registe quatro observações em vez de uma: o evento de ligação disparou, a tarefa arrancou, o recurso respondeu e a alteração pedida chegou mesmo a acontecer. Se o registo parar em tarefa iniciada, a falha real fica invisível por muito que espere. Depois execute gpresult /scope user /v para ver que política a sessão pensa ter, e compare com a definição que esperava. Um relatório que lista a GPO como aplicada continua a não dizer nada sobre um mapeamento.

Torne o trabalho seguro de repetir antes de o alargar, porque o cliente volta a ligar-se e a tarefa dispara outra vez. Verifique se o mapeamento ou a configuração já existe antes de o criar, e registe o que encontrou. O trabalho duplicado após cada religação transitória é como uma tarefa útil se transforma num incidente.

Onde um acionador automático não serve, uma ação de utilizador aprovada que executa o mesmo script assinado é um desenho legítimo. Torna o momento explícito em vez de fingir que ocorreu um evento de início de sessão.