Se connecter au VPN ne rejoue pas votre script d'ouverture de session

Votre utilisateur ouvre une session à la maison, se connecte au VPN et attend le lecteur réseau qui apparaissait autrefois tout seul au bureau. Le tunnel monte, le domaine répond, et rien n'est mappé. Rien n'est cassé : un script d'ouverture de session s'exécute à l'ouverture de session, et un tunnel ouvert vingt minutes après le début de la session n'est pas une ouverture de session. Lire les deux comme un même événement envoie les gens chercher une panne VPN qui n'existe pas.

Quatre décisions transforment la surprise en un flux de travail qui se comporte bien, et la première consiste simplement à savoir sur quels événements un script s'appuie.

Les scripts s'appuient sur des événements de cycle de vie que vous ne pouvez pas rejouer

La stratégie côté ordinateur est appliquée au démarrage de la machine et la stratégie côté utilisateur à l'ouverture de session, tandis qu'une actualisation en arrière-plan parcourt les mêmes paramètres sans rien redémarrer. Cette actualisation traite l'extension de scripts, mais elle ne réexécute pas les scripts individuels, qui ne se déclenchent qu'au démarrage, à l'arrêt, à l'ouverture ou à la fermeture de session. Ainsi, gpupdate /force peut signaler un succès alors que le mappage manque encore, et une actualisation propre ne prouve pas que le script a fait quoi que ce soit.

La référence Microsoft sur le traitement des stratégies trace exactement cette frontière entre traiter l'extension et exécuter ce qu'elle contient, et c'est la page à citer quand quelqu'un insiste pour qu'une actualisation ait dû rejouer le script.

Tout script n'échoue pas non plus hors ligne. Un script qui ne lit que des éléments locaux ou en cache a pu réussir partiellement, tandis qu'un script qui touche un partage échoue silencieusement et ne laisse aucune trace évidente. Vérifiez le chemin réel du script et ce qu'il atteint avant d'accuser le réseau. Le même examen vaut pour toute affirmation selon laquelle un script ne s'exécute pas à l'ouverture de session, car une tâche planifiée ou une action du client peut faire le travail là où personne ne regarde.

Rattachez le travail à la connexion, pas à l'ouverture de session

Trois travaux différents se cachent derrière l'expression script d'ouverture de session : mapper un lecteur après la connexion de l'utilisateur, appliquer la configuration de la machine avant que quiconque ouvre une session, et récupérer la stratégie mise à jour. Ils ont des échéances différentes, et seul le deuxième a réellement besoin de connectivité avant l'ouverture de session. Rédigez l'exigence comme une phrase avec une échéance, par exemple : ce mappage doit exister dans la minute suivant la montée du tunnel.

Pour le travail qui doit avoir lieu après la connexion, utilisez une tâche déclenchée par la connexion ou l'action de connexion prise en charge par le client. Vérifiez quel événement le client émet réellement, car un événement levé par le client VPN natif de Windows ne l'est pas par un client tiers. Pour la configuration de la machine qui doit précéder l'ouverture de session, la réponse prise en charge est un tunnel d'appareil ou une autre conception avant ouverture de session, pas une tâche qui se déclenche à l'apparition du bureau. Exécutez le travail dans l'identité et la session qui en ont besoin, car un mappage créé en tant que SYSTEM atterrit dans une session que l'utilisateur ne voit jamais.

Testez l'état de préparation avant d'agir, et échouez bruyamment

Un événement de connexion peut arriver avant que le DNS ou le serveur de fichiers soit utilisable, donc la tâche doit tester ce dont elle a besoin plutôt que de supposer. Résolvez le nom précis, tentez la connexion précise, et réessayez avec une limite et un délai : Resolve-DnsName files.corp.example dans une boucle courte sépare pas-encore de jamais. Signalez un échec concret après la dernière tentative, avec le nom et l'erreur dedans.

Une boucle sans fin sans journal est indiscernable d'une tâche qui n'a jamais démarré, et elle masque la différence entre un identifiant obsolète et une règle de pare-feu.

Vérifiez quatre choses, puis rendez-le reproductible

Pendant le pilote, enregistrez quatre observations au lieu d'une : l'événement de connexion s'est déclenché, la tâche a démarré, la ressource a répondu, et la modification demandée a réellement abouti. Si le journal s'arrête à tâche démarrée, la véritable défaillance reste invisible, quelle que soit la durée d'attente. Exécutez ensuite gpresult /scope user /v pour voir quelle stratégie la session croit avoir, et comparez-la au paramètre attendu. Un rapport listant la GPO comme appliquée ne dit toujours rien d'un mappage.

Rendez le travail sûr à répéter avant de l'étendre, car le client se reconnecte et la tâche se déclenche à nouveau. Vérifiez l'existence du mappage ou de la configuration avant de le créer, et notez ce que vous avez trouvé. Un travail dupliqué après chaque reconnexion transitoire est la façon dont une tâche utile devient un incident.

Là où un déclencheur automatique ne convient pas, une action utilisateur approuvée qui exécute le même script signé est une conception légitime. Elle rend le moment explicite au lieu de prétendre qu'un événement d'ouverture de session a eu lieu.