Executeu una tasca quan el VPN es connecta: esdeveniment, sondeig o credencial?

Un script d'inici que assigna una unitat o inicia una tasca de sincronització s'executa abans que el túnel tingui adreça, així que falla en silenci i l'usuari el repara a mà cada matí. Windows no ofereix a la majoria de clients cap devolució de trucada per VPN connectada, però sí que registra el canvi de xarxa, i aquest registre pot iniciar la feina en el moment adequat. L'elecció se situa entre reaccionar a aquest registre, sondejar el recurs i eliminar l'avís que feia visible la fallada.

Comparar els tres mecanismes pel que garanteixen és millor que ordenar-los per elegància. Cadascun falla de manera diferent, i el mode de fallada és el que després has de suportar.

Per què l'inici s'executa massa d'hora

L'inici de sessió i l'arrencada s'executen abans que l'adaptador VPN rebi la seva adreça, així que una assignació d'unitat, una URL interna o una connexió a base de dades provades en aquell moment no tenen ni ruta ni resolutor. La sol·licitud falla, i la sessió queda en un estat que l'usuari ha de reparar manualment. Moure el mateix script a la carpeta d'inici no canvia res, perquè el problema d'ordre viatja amb ell. El desencadenador ha de ser un canvi de xarxa i no un esdeveniment de sessió.

Una tasca programada a l'inici amb un retard arbitrari sembla una solució i en realitat és una endevinalla. Funciona en un enllaç ràpid i falla en un de lent, que és el tipus de fiabilitat menys útil.

Tres ganxos comparats

Els mecanismes difereixen en què observen, amb quina rapidesa reaccionen i què fan amb una reconnexió més tard al dia. La taula els compara en aquests tres punts i no en com d'enginyós sona cadascun.

Llegiu la taula fila per fila. El ganxo d'esdeveniment és el més ràpid i el més sorollós, ja que Windows registra totes les xarxes, incloent-hi el Wi-Fi del cafè, així que l'acció ha de verificar el recurs abans de fer res. El sondeig és més lent i més precís, perquè té èxit exactament quan la compartició o el nom d'amfitrió responen, i no necessita saber quin client hi ha instal·lat. Les credencials desades no són cap opció competidora: eliminen l'avís de contrasenya, que és un segon motiu independent pel qual falla una assignació a l'inici.

Triar entre els dos primers depèn de si hi ha un esdeveniment utilitzable al client. On n'hi ha, un esdeveniment més una comprovació del recurs és el millor valor per defecte.

Construeu bé el desencadenador d'esdeveniment

El registre viu al registre Microsoft-Windows-NetworkProfile/Operational, i l'ID 10001 marca una xarxa que acaba de connectar-se. Creeu la tasca amb un desencadenador En un esdeveniment adreçat a aquest registre, aquest nom de proveïdor i aquest identificador. Totes les xarxes a què s'uneixi la màquina l'activaran, així que l'acció necessita una clàusula de guàrdia i no una suposició, i hauria d'executar-se només mentre l'usuari té la sessió iniciada si la feina toca unitats assignades.

La clàusula de guàrdia hauria de provar el que la tasca necessita de veritat, com ara una ruta de compartició o un port de servei, i sortir en silenci quan no sigui accessible. Provar el nom de l'adaptador no n'hi ha prou, perquè un client pot reutilitzar un adaptador en diversos perfils. Una sortida silenciosa manté el registre llegible i evita una tempesta de reintents contra una xarxa que mai no servirà el recurs.

Comproveu que la tasca s'executa en el moment adequat

Demostreu el moment, no la configuració. Les ordres següents mostren la definició de la tasca, els esdeveniments recents del perfil de xarxa i si el recurs és accessible des del compte amb què s'executa la tasca. Executeu-les després d'una reconnexió real i no després d'un inici manual.

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

Una entrada de l'historial de tasques que existeix mentre no coincideix cap esdeveniment de xarxa vol dir que el desencadenador és incorrecte i no l'acció. Si els esdeveniments apareixen i la tasca no, potser la tasca s'executa amb un compte que no veu el recurs, i la sortida del compte és la pista. Una comprovació del recurs que passa mentre l'assignació encara falta apunta al context de sessió i no a la connectivitat. Cadascuna d'aquestes tres observacions et porta a una solució diferent.

Escriviu una línia de registre per execució amb l'adreça, el resultat del recurs i el desenllaç. La propera fallada mostrarà llavors si la tasca es va executar d'hora, es va executar a la xarxa equivocada o no es va executar mai.