Conectarse á VPN non volve executar o script de inicio de sesión
Os scripts de inicio de sesión execútanse ao iniciar sesión, non cando aparece un túnel. Separe o arranque, o inicio de sesión e a actualización en segundo plano, e despois active o traballo na conexión.
O seu usuario inicia sesión na casa, conecta a VPN e espera a asignación de unidade que antes aparecía soa na oficina. O túnel sobe, o dominio responde e nada se asigna. Nada está roto: un script de inicio de sesión execútase ao iniciar sesión, e un túnel aberto vinte minutos despois de comezar a sesión non é un inicio de sesión. Ler ambos como o mesmo evento envía a xente a buscar unha falla de VPN que non existe.
Catro decisións converten a sorpresa nun fluxo de traballo que se comporta, e a primeira é simplemente saber sobre que eventos cabalga un script.
Os scripts cabalgan sobre eventos de ciclo de vida que non pode repetir
A directiva do lado do equipo aplícase cando arranca a máquina e a do lado do usuario cando alguén inicia sesión, mentres que unha actualización en segundo plano percorre os mesmos axustes sen reiniciar nada. Ese refresco procesa a extensión de scripts, pero non volve executar os scripts individuais, que só se disparan ao arrancar, apagar, iniciar ou pechar sesión. Por iso gpupdate /force pode informar de éxito mentres a asignación segue ausente, e unha actualización limpa non é proba de que o script fixera algo.
A referencia de Microsoft sobre o procesamento de directivas traza exactamente esa liña entre procesar a extensión e executar o que contén, e é a páxina que hai que citar cando alguén insiste en que unha actualización debería ter repetido o script.
Tampouco falla todo script sen conexión. Un que só le material local ou na caché pode ter tido éxito parcial, mentres que un que toca un recurso compartido falla en silencio e non deixa marca evidente. Comprobe a ruta real do script e ata onde chega antes de culpar a rede. A mesma revisión corresponde a calquera afirmación de que un script non se executa ao iniciar sesión, porque unha tarefa programada ou unha acción do cliente poden estar facendo o traballo onde ninguén mira.
Ate o traballo á conexión, non ao inicio de sesión
Tres traballos distintos escóndense tras a frase script de inicio de sesión: asignar unha unidade despois de que o usuario se conecte, aplicar configuración da máquina antes de que ninguén inicie sesión e obter a directiva actualizada. Teñen prazos diferentes, e só o segundo necesita realmente conectividade antes do inicio de sesión. Escriba o requisito como unha frase cun prazo, por exemplo: esta asignación debe existir dentro do minuto seguinte a que suba o túnel.
Para o traballo que debe ocorrer despois da conexión, use unha tarefa desencadeada pola conexión ou a acción de conexión que admita o cliente. Comprobe que evento emite realmente o cliente, porque un evento xerado polo cliente VPN nativo de Windows non o xera un de terceiros. Para a configuración da máquina que debe preceder ao inicio de sesión, a resposta admitida é un túnel de dispositivo ou outro deseño previo ao inicio de sesión, non unha tarefa que se dispare cando apareza o escritorio. Execute o traballo coa identidade e a sesión que o necesitan, xa que unha asignación creada como SYSTEM acaba nunha sesión que o usuario nunca ve.
Probe a preparación antes de actuar e fracase en voz alta
Un evento de conexión pode chegar antes de que o DNS ou o servidor de ficheiros sexan utilizables, así que a tarefa debe probar o que necesita en lugar de supoñelo. Resolva o nome concreto, tente a conexión concreta e reintente cun límite e un atraso: Resolve-DnsName files.corp.example dentro dun bucle curto separa aínda-non de nunca. Informe dun fallo concreto tras o último reintento, co nome e o erro dentro.
Un bucle sen fin e sen rexistro é indistinguible dunha tarefa que nunca comezou, e oculta a diferenza entre unha credencial caducada e unha regra de devasas.
Verifique catro cousas e despois fagao repetible
Durante o piloto, rexistre catro observacións en lugar dunha: o evento de conexión disparouse, a tarefa arrincou, o recurso respondeu e o cambio solicitado chegou de verdade. Se o rexistro se detén en tarefa iniciada, o fallo real queda invisible por moito que espere. Despois execute gpresult /scope user /v para ver que directiva cre ter a sesión e compáreo co axuste que esperaba. Un informe que lista o GPO como aplicado segue sen dicir nada sobre unha asignación.
Faga que o traballo sexa seguro de repetir antes de amplialo, porque o cliente se reconecta e a tarefa vólvese disparar. Comprobe se xa existe a asignación ou a configuración antes de creala e rexistre o que atopou. O traballo duplicado tras cada reconexión transitoria é como unha tarefa útil se converte nun incidente.
Onde un desencadeante automático non encaixa, unha acción de usuario aprobada que executa o mesmo script asinado é un deseño lexítimo. Fai explícito o momento en lugar de finxir que ocorreu un evento de inicio de sesión.