Conectarse a la VPN no vuelve a ejecutar el script de inicio de sesión

Su usuario inicia sesión en casa, conecta la VPN y espera la asignación de unidad que antes aparecía sola en la oficina. El túnel sube, el dominio responde y nada se asigna. Nada está roto: un script de inicio de sesión se ejecuta al iniciar sesión, y un túnel abierto veinte minutos después de empezar la sesión no es un inicio de sesión. Leer ambos como el mismo evento envía a la gente a buscar una falla de VPN que no existe.

Cuatro decisiones convierten la sorpresa en un flujo de trabajo que se comporta, y la primera es simplemente saber sobre qué eventos cabalga un script.

Los scripts cabalgan sobre eventos de ciclo de vida que no puede repetir

La directiva del lado del equipo se aplica cuando arranca la máquina y la del lado del usuario cuando alguien inicia sesión, mientras que una actualización en segundo plano recorre los mismos ajustes sin reiniciar nada. Esa actualización procesa la extensión de scripts, pero no vuelve a ejecutar los scripts individuales, que solo se disparan al arrancar, apagar, iniciar o cerrar sesión. Por eso gpupdate /force puede informar de éxito mientras la asignación sigue ausente, y una actualización limpia no es prueba de que el script hiciera algo.

La referencia de Microsoft sobre el procesamiento de directivas traza exactamente esa línea entre procesar la extensión y ejecutar lo que contiene, y es la página que hay que citar cuando alguien insiste en que una actualización debería haber repetido el script.

Tampoco falla todo script sin conexión. Uno que solo lee material local o en caché puede haber tenido éxito parcial, mientras que uno que toca un recurso compartido falla en silencio y no deja marca evidente. Compruebe la ruta real del script y hasta dónde llega antes de culpar a la red. La misma revisión corresponde a cualquier afirmación de que un script no se ejecuta al iniciar sesión, porque una tarea programada o una acción del cliente pueden estar haciendo el trabajo donde nadie mira.

Ate el trabajo a la conexión, no al inicio de sesión

Tres trabajos distintos se esconden tras la frase script de inicio de sesión: asignar una unidad después de que el usuario se conecte, aplicar configuración de la máquina antes de que nadie inicie sesión y obtener la directiva actualizada. Tienen plazos diferentes, y solo el segundo necesita realmente conectividad antes del inicio de sesión. Escriba el requisito como una frase con un plazo, por ejemplo: esta asignación debe existir dentro del minuto siguiente a que suba el túnel.

Para el trabajo que debe ocurrir después de la conexión, use una tarea desencadenada por la conexión o la acción de conexión que admita el cliente. Compruebe qué evento emite realmente el cliente, porque un evento generado por el cliente VPN nativo de Windows no lo genera uno de terceros. Para la configuración de la máquina que debe preceder al inicio de sesión, la respuesta admitida es un túnel de dispositivo u otro diseño previo al inicio de sesión, no una tarea que se dispare cuando aparezca el escritorio. Ejecute el trabajo con la identidad y la sesión que lo necesitan, ya que una asignación creada como SYSTEM acaba en una sesión que el usuario nunca ve.

Pruebe la preparación antes de actuar y falle en voz alta

Un evento de conexión puede llegar antes de que el DNS o el servidor de archivos sean utilizables, así que la tarea debe probar lo que necesita en lugar de suponerlo. Resuelva el nombre concreto, intente la conexión concreta y reintente con un límite y un retraso: Resolve-DnsName files.corp.example dentro de un bucle corto separa todavía-no de nunca. Informe de un fallo concreto tras el último reintento, con el nombre y el error dentro.

Un bucle sin fin y sin registro es indistinguible de una tarea que nunca empezó, y oculta la diferencia entre una credencial caducada y una regla de firewall.

Verifique cuatro cosas y luego hágalo repetible

Durante el piloto, registre cuatro observaciones en lugar de una: el evento de conexión se disparó, la tarea arrancó, el recurso respondió y el cambio solicitado llegó de verdad. Si el registro se detiene en tarea iniciada, el fallo real queda invisible por mucho que espere. Después ejecute gpresult /scope user /v para ver qué directiva cree tener la sesión y compárelo con el ajuste que esperaba. Un informe que lista el GPO como aplicado sigue sin decir nada sobre una asignación.

Haga que el trabajo sea seguro de repetir antes de ampliarlo, porque el cliente se reconecta y la tarea se vuelve a disparar. Compruebe si ya existe la asignación o la configuración antes de crearla y registre lo que encontró. El trabajo duplicado tras cada reconexión transitoria es como una tarea útil se convierte en un incidente.

Donde un desencadenante automático no encaja, una acción de usuario aprobada que ejecuta el mismo script firmado es un diseño legítimo. Hace explícito el momento en lugar de fingir que ocurrió un evento de inicio de sesión.