¿Mapear la unidad antes de que la VPN esté lista? Condiciónelo al servidor

La letra de unidad aparece al iniciar sesión y luego se abre como una carpeta vacía, o con una cruz roja y un mensaje sobre un recurso de red no disponible. Los permisos suelen estar bien. Lo que ocurrió es que el comando de asignación se ejecutó durante la ventana en la que el cliente VPN existía pero no había ninguna ruta al servidor de archivos, y Windows registró ese fallo como el estado de la unidad. La solución es dejar de tratar la asignación como algo que ocurre al iniciar sesión y tratarla como el último paso de una secuencia de conexión.

Por qué la asignación se ejecuta demasiado pronto

Un script de inicio de sesión empieza cuando empieza la sesión. Un cliente VPN que se conecta durante el inicio de sesión añade su propia línea temporal encima: el proceso puede estar en marcha, el adaptador virtual puede existir y la ruta a la subred de la oficina puede seguir faltando. Esos tres estados se ven igual desde el punto de vista de un script y solo uno de ellos funciona.

Algunos entornos responden repitiendo la misma línea fallida en cada inicio de sesión, lo que produce un usuario que ha aprendido a hacer doble clic en la unidad y un script que nunca ha tenido éxito por sí solo.

La propia unidad lo empeora. Una unidad asignada es un objeto de sesión, y una vez que Windows la ha marcado como no disponible, el icono puede quedarse roto mucho después de que el túnel esté sano. Por eso reasignar a mano funciona mientras el script parece no hacer nada. La sesión recuerda el fallo, no la intención que había detrás.

Un estado conectado no es una ruta

El icono de la VPN en la bandeja indica si el túnel está levantado. No dice nada sobre si existe una ruta a un servidor concreto, si el DNS resuelve ese nombre a la dirección del túnel, ni si el cortafuegos del propio servidor le acepta a usted.

Son tres fallos separados con el mismo resultado visible, y condicionar la operación al icono de la bandeja los funde en una sola señal poco fiable.

Una comprobación de disponibilidad que nombra el servidor que realmente necesita los distingue, porque falla hasta que funciona la ruta concreta, y no hasta que alguna interfaz se declara conectada.

Condicione la operación al servidor, no al cliente

Elija un host que solo sea alcanzable a través del túnel y espérelo antes de asignar nada. El fragmento de abajo conecta una entrada de VPN de Windows guardada, sondea el servidor de archivos y después asigna la unidad.

@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

El ping es una sonda de disponibilidad, no una prueba de permisos. Si el ICMP está filtrado en su red, sondee en su lugar el servicio que realmente usa: net view \\%server% para una comprobación rápida, o una prueba TCP corta contra el puerto 445 en PowerShell. Cualquiera de las dos condiciona la operación a lo que importa.

Añada un número limitado de intentos. Un bucle de espera sin techo convierte un túnel roto en una sesión que nunca termina de iniciar sesión, y eso es una llamada de soporte peor que una letra de unidad ausente.

Hágalo reejecutable y consciente de la sesión

Ejecúteló dentro de la sesión del propio usuario. Una tarea que se ejecuta como SYSTEM coloca la unidad en una sesión completamente distinta, y el usuario que ha iniciado sesión nunca ve el resultado. Así obtiene un script que informa de éxito y un escritorio sin ninguna unidad.

Compruebe antes de asignar y elimine solo la entrada obsoleta. net use Z: /delete devuelve un error cuando la letra no se usa, y ese error se puede ignorar sin problema en lugar de ser un motivo para abandonar el resto del script. Mantenga /persistent:no para que un intento fallido no se convierta más tarde en un intento de reconexión permanente.

Y no ponga ninguna contraseña en el archivo. rasdial puede reutilizar las credenciales guardadas para la entrada de VPN, y el recurso compartido debería autenticarse como el usuario que ha iniciado sesión. Si el recurso necesita de verdad credenciales distintas, regístrelas una vez por usuario con cmdkey en lugar de incrustarlas en un archivo batch que vive en un recurso compartido de inicio de sesión. Cualquiera que pueda leer ese recurso puede leer la contraseña, lo que convierte una comodidad en un incidente.

Volver a ejecutar todo el script debería ser inofensivo, porque es lo que va a pasar. Los usuarios se reconectan, los portátiles se despiertan y el mismo camino de código se ejecuta otra vez con un estado inicial distinto.

Registre lo suficiente para demostrar qué mitad llegó tarde

Escriba la marca de tiempo, el resultado de la comprobación de disponibilidad y el código de salida de la asignación en un archivo bajo el perfil del usuario. Cuando llegue el siguiente informe de una unidad ausente, ese registro responde a la única pregunta que importa: ¿llegó tarde el túnel o rechazó el recurso compartido?

Sin él, cada reaparición se investiga desde cero, y la conclusión habitual es un cambio de permisos que no arregla nada.

Pruebe la secuencia una vez desde un arranque en frío y otra desde la suspensión. El caso de despertar es donde el orden se rompe más a menudo, porque la sesión se reanuda antes que la red y el script ve una máquina que lleva horas con la sesión iniciada.