Ejecutar una tarea cuando se conecta la VPN: ¿evento, sondeo o credencial?

Un script de inicio de sesión que asigna una unidad o inicia un trabajo de sincronización se ejecuta antes de que el túnel tenga dirección, así que falla en silencio y el usuario lo repara a mano cada mañana. Windows no ofrece a la mayoría de los clientes ninguna devolución de llamada por VPN conectada, pero sí registra el cambio de red, y ese registro puede iniciar el trabajo en el momento adecuado. La elección está entre reaccionar a ese registro, sondear el recurso y eliminar el aviso que hacía visible el fallo.

Comparar los tres mecanismos por lo que garantizan supera ordenarlos por elegancia. Cada uno falla de forma distinta, y el modo de fallo es lo que uno soporta después.

Por qué el inicio de sesión se dispara demasiado pronto

El inicio de sesión y el arranque se ejecutan antes de que el adaptador VPN reciba su dirección, así que una asignación de unidad, una URL interna o una conexión de base de datos intentada en ese momento no tienen ni ruta ni resolución. La solicitud falla y la sesión queda en un estado que el usuario debe reparar manualmente. Mover el mismo script a la carpeta de inicio no cambia nada, porque el problema de orden viaja con él. El desencadenador tiene que ser un cambio de red y no un evento de sesión.

Una tarea programada al iniciar sesión con un retardo arbitrario parece una solución y en realidad es una conjetura. Funciona en un enlace rápido y falla en uno lento, que es el tipo de fiabilidad menos útil.

Tres enganches comparados

Los mecanismos difieren en lo que observan, con qué rapidez reaccionan y qué hacen ante una reconexión más tarde ese día. La tabla los compara en esos tres puntos y no en lo ingenioso que suena cada uno.

Lea la tabla fila por fila. El enganche de evento es el más rápido y el más ruidoso, ya que Windows registra todas las redes, incluida la Wi-Fi de la cafetería, así que la acción debe verificar el recurso antes de hacer nada. El sondeo es más lento y más preciso, porque tiene éxito exactamente cuando responde el recurso compartido o el nombre de host, y no necesita saber qué cliente está instalado. Las credenciales guardadas no son ninguna opción competidora: eliminan el aviso de contraseña, que es un segundo motivo independiente por el que falla una asignación al iniciar sesión.

Elegir entre los dos primeros depende de si existe un evento utilizable en el cliente. Donde existe, un evento más una comprobación del recurso es el mejor valor predeterminado.

Construya correctamente el desencadenador de evento

El registro vive en el registro Microsoft-Windows-NetworkProfile/Operational, y el ID 10001 marca una red que acaba de conectarse. Cree la tarea con un desencadenador Al producirse un evento dirigido a ese registro, ese nombre de proveedor y ese identificador. Toda red a la que se una la máquina lo activará, así que la acción necesita una cláusula de protección en lugar de una suposición, y solo debería ejecutarse mientras el usuario tenga la sesión iniciada si el trabajo toca unidades asignadas.

La cláusula de protección debería comprobar lo que la tarea necesita de verdad, como una ruta compartida o un puerto de servicio, y salir en silencio cuando no sea accesible. Comprobar el nombre del adaptador no basta, porque un cliente puede reutilizar un adaptador en varios perfiles. Una salida silenciosa mantiene legible el registro y evita una tormenta de reintentos contra una red que nunca servirá el recurso.

Compruebe que la tarea se ejecuta en el momento adecuado

Demuestre el momento, no la configuración. Los comandos siguientes muestran la definición de la tarea, los eventos recientes del perfil de red y si se puede acceder al recurso desde la cuenta con la que se ejecuta la tarea. Ejecútelos tras una reconexión real y no tras un inicio manual.

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

Una entrada del historial de tareas que existe mientras no coincide ningún evento de red significa que el desencadenador está mal y no la acción. Si aparecen los eventos y la tarea no, puede que la tarea se ejecute con una cuenta que no ve el recurso, y la salida de la cuenta es la pista. Una comprobación del recurso que pasa mientras la asignación sigue faltando apunta al contexto de sesión y no a la conectividad. Cada una de esas tres observaciones le lleva a una solución distinta.

Escriba una línea de registro por ejecución con la dirección, el resultado del recurso y el desenlace. El siguiente fallo mostrará entonces si la tarea se ejecutó pronto, se ejecutó en la red equivocada o no se ejecutó nunca.