Lancer une tâche quand le VPN se connecte : événement, interrogation ou identifiant ?

Un script d’ouverture de session qui mappe un lecteur ou démarre un travail de synchronisation s’exécute avant que le tunnel ait une adresse, il échoue donc en silence et l’utilisateur le répare à la main chaque matin. Windows n’offre pas de rappel de connexion par VPN à la plupart des clients, mais il journalise le changement de réseau, et cet enregistrement peut lancer le travail au bon moment. Le choix se situe entre réagir à cet enregistrement, interroger la ressource et supprimer l’invite qui rendait l’échec visible.

Comparer les trois mécanismes selon ce qu’ils garantissent vaut mieux que les classer par élégance. Chacun échoue différemment, et le mode d’échec est ce avec quoi vous vivez ensuite.

Pourquoi l’ouverture de session démarre trop tôt

L’ouverture de session et le démarrage s’exécutent avant que l’adaptateur VPN reçoive son adresse, donc un mappage de lecteur, une URL interne ou une connexion à une base de données tentés à ce moment n’ont ni route ni résolveur. La requête échoue, et la session reste dans un état que l’utilisateur doit réparer manuellement. Déplacer le même script dans le dossier de démarrage ne change rien, car le problème d’ordre voyage avec lui. Le déclencheur doit être un changement de réseau et non un événement de session.

Une tâche planifiée à l’ouverture de session avec un délai arbitraire ressemble à un correctif et n’est en réalité qu’une supposition. Elle fonctionne sur une liaison rapide et échoue sur une liaison lente, ce qui est le type de fiabilité le moins utile.

Trois accroches comparées

Les mécanismes diffèrent par ce qu’ils observent, la vitesse de leur réaction et ce qu’ils font d’une reconnexion plus tard dans la journée. Le tableau les compare sur ces trois points et non sur l’ingéniosité apparente de chacun.

Lisez le tableau ligne par ligne. L’accroche d’événement est la plus rapide et la plus bruyante, car Windows enregistre chaque réseau, y compris le Wi-Fi du café, donc l’action doit vérifier la ressource avant de faire quoi que ce soit. L’interrogation est plus lente et plus précise, car elle réussit exactement quand le partage ou le nom d’hôte répond, et elle n’a pas besoin de savoir quel client est installé. Les identifiants enregistrés ne sont pas du tout une option concurrente : ils suppriment l’invite de mot de passe, ce qui est une seconde raison indépendante pour laquelle un mappage à l’ouverture de session échoue.

Choisir entre les deux premiers revient à savoir si un événement utilisable existe sur le client. Là où il existe, un événement plus une vérification de la ressource est la meilleure valeur par défaut.

Construire correctement le déclencheur d’événement

L’enregistrement se trouve dans le journal Microsoft-Windows-NetworkProfile/Operational, et l’ID 10001 marque un réseau qui vient de se connecter. Créez la tâche avec un déclencheur Lors d’un événement visant ce journal, ce nom de fournisseur et cet identifiant. Chaque réseau auquel la machine se joint le déclenchera, donc l’action a besoin d’une clause de garde plutôt que d’une supposition, et elle ne devrait s’exécuter que tant que l’utilisateur est connecté si le travail touche des lecteurs mappés.

La clause de garde devrait tester ce dont la tâche a réellement besoin, comme un chemin de partage ou un port de service, et sortir discrètement quand il est inaccessible. Tester le nom de l’adaptateur ne suffit pas, car un client peut réutiliser un adaptateur sur plusieurs profils. Une sortie discrète garde le journal lisible et empêche une tempête de nouvelles tentatives contre un réseau qui ne servira jamais la ressource.

Vérifier que la tâche s’exécute au bon moment

Prouvez le moment plutôt que la configuration. Les commandes ci-dessous montrent la définition de la tâche, les événements récents du profil réseau et si la ressource est accessible depuis le compte sous lequel la tâche s’exécute. Exécutez-les après une vraie reconnexion et non après un démarrage manuel.

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

Une entrée d’historique de tâche qui existe alors qu’aucun événement réseau ne correspond signifie que le déclencheur est faux et non l’action. Si les événements apparaissent et que la tâche non, la tâche s’exécute peut-être sous un compte qui ne voit pas la ressource, et la sortie du compte est l’indice. Une vérification de ressource qui passe alors que le mappage manque encore renvoie au contexte de session et non à la connectivité. Chacune de ces trois observations vous mène à un correctif différent.

Écrivez une ligne de journal par exécution avec l’adresse, le résultat de la ressource et l’issue. La prochaine panne montrera alors si la tâche s’est exécutée tôt, sur le mauvais réseau, ou pas du tout.