Mapear a unidade antes de a VPN estar pronta? Condicione ao servidor

A letra da unidade aparece no logon e depois abre como uma pasta vazia, ou com uma cruz vermelha e uma mensagem sobre um recurso de rede indisponível. As permissões costumam estar certas. O que aconteceu é que o comando de mapeamento rodou na janela em que o cliente VPN existia, mas não havia rota até o servidor de arquivos, e o Windows registrou essa falha como o estado da unidade. A correção é parar de tratar o mapeamento como algo que acontece no logon e tratá-lo como o último passo de uma sequência de conexão.

Por que o mapeamento roda cedo demais

Um script de logon começa quando a sessão começa. Um cliente VPN que se conecta durante o logon acrescenta a própria linha do tempo por cima: o processo pode estar rodando, o adaptador virtual pode existir e a rota para a sub-rede do escritório pode ainda faltar. Esses três estados parecem iguais do ponto de vista de um script e só um deles funciona.

Alguns ambientes respondem repetindo a mesma linha falha em cada logon, o que produz um usuário que aprendeu a clicar duas vezes na unidade e um script que nunca teve sucesso sozinho.

A própria unidade piora isso. Uma unidade mapeada é um objeto de sessão, e depois que o Windows a marcou como indisponível, o ícone pode continuar quebrado muito tempo depois de o túnel estar saudável. É por isso que remapear à mão funciona enquanto o script parece não fazer nada. A sessão lembra da falha, não da intenção por trás dela.

Um status conectado não é um caminho

O ícone da VPN na bandeja informa se o túnel está no ar. Não diz nada sobre existir uma rota até um servidor específico, se o DNS resolve esse nome para o endereço do túnel, nem se o firewall do próprio servidor aceita você.

São três falhas separadas com o mesmo resultado visível, e condicionar tudo ao ícone da bandeja as funde em um único sinal não confiável.

Uma verificação de prontidão que nomeia o servidor de que você realmente precisa as distingue, porque falha até o caminho específico funcionar, e não até alguma interface se declarar conectada.

Condicione ao servidor, não ao cliente

Escolha um host que só seja alcançável pelo túnel e espere por ele antes de mapear qualquer coisa. O trecho abaixo conecta uma entrada de VPN do Windows salva, sonda o servidor de arquivos e depois mapeia a unidade.

@echo off
set server=fileserver.corp.example
rasdial "Office VPN" /disconnect
rasdial "Office VPN"
:wait
ping -n 1 -w 1000 %server% >nul || (
  timeout /t 5 /nobreak >nul
  goto wait
)
net use Z: \\%server%\share /persistent:no

O ping é uma sonda de prontidão, não um teste de permissões. Se o ICMP for filtrado na sua rede, sonde em vez disso o serviço que você realmente usa: net view \\%server% para uma verificação rápida, ou um teste TCP curto na porta 445 no PowerShell. Qualquer um dos dois condiciona ao que importa.

Adicione um número limitado de tentativas. Um laço de espera sem teto transforma um túnel quebrado em uma sessão que nunca termina o logon, e isso é uma chamada de suporte pior do que uma letra de unidade ausente.

Torne-o reexecutável e ciente da sessão

Execute-o dentro da sessão do próprio usuário. Uma tarefa que roda como SYSTEM coloca a unidade em uma sessão completamente diferente, e o usuário conectado nunca vê o resultado. Isso dá a você um script que relata sucesso e uma área de trabalho sem unidade.

Verifique antes de mapear e remova apenas a entrada obsoleta. net use Z: /delete retorna um erro quando a letra não está em uso, e esse erro pode ser ignorado sem problema em vez de ser motivo para abandonar o resto do script. Mantenha /persistent:no para que uma tentativa falha não se torne mais tarde uma tentativa permanente de reconexão.

E não coloque uma senha no arquivo. rasdial pode reutilizar as credenciais salvas para a entrada de VPN, e o compartilhamento deveria autenticar como o usuário conectado. Se o compartilhamento realmente precisa de credenciais diferentes, registre-as uma vez por usuário com cmdkey em vez de embuti-las em um arquivo em lotes que vive em um compartilhamento de logon. Qualquer um que possa ler esse compartilhamento pode ler a senha, e isso transforma uma comodidade em um incidente.

Reexecutar o script inteiro deveria ser inofensivo, porque é exatamente isso que vai acontecer. Os usuários se reconectam, os notebooks acordam, e o mesmo caminho de código roda de novo com um estado inicial diferente.

Registre o suficiente para provar qual metade chegou atrasada

Escreva o carimbo de data e hora, o resultado da verificação de prontidão e o código de saída do mapeamento em um arquivo sob o perfil do usuário. Quando chegar o próximo relato de unidade ausente, esse log responde à única pergunta que importa: o túnel chegou atrasado ou o compartilhamento recusou?

Sem isso, cada reincidência é investigada do zero, e a conclusão habitual é uma mudança de permissões que não conserta nada.

Teste a sequência uma vez a partir de um boot frio e uma vez a partir da suspensão. O caso do despertar é onde a ordem se quebra com mais frequência, porque a sessão é retomada antes da rede e o script vê uma máquina conectada há horas.