Les scripts d'ouverture de session proxy de Windows ne suivent pas les changements réseau ultérieurs
Traitez la sélection du proxy à l'ouverture de session Windows et les transitions réseau ultérieures comme des événements distincts, avec une mise à jour délibérée du client et une politique de connexion.
Un ordinateur portable peut recevoir correctement le proxy du bureau à l'ouverture de session et le conserver après être rentré chez lui. Le script d'ouverture de session ne s'est exécuté qu'une fois ; il ne s'est pas abonné à chaque changement Wi-Fi ultérieur. Le traitement en arrière-plan des stratégies de groupe ne promet pas de réexécuter un script d'ouverture de session arbitraire lors d'une transition.
Définissez explicitement le comportement ultérieur :
- Déclencheur : une application gérée peut utiliser les notifications de changement de connectivité du Network List Manager pour réexaminer l'état. La notification elle-même ne choisit ni n'écrit de proxy.
- Décision : inspectez suffisamment l'état actuel du réseau. Une seule adresse privée ou la première interface énumérée est une preuve faible lorsque Ethernet, Wi-Fi et VPN coexistent.
- Mise à jour du client : appliquez le paramètre via l'interface utilisée par les clients. L'enregistrement WinINet et les notifications documentées de changement de paramètres et d'actualisation sont des actions distinctes ; WinHTTP ou une configuration privée de l'application peuvent nécessiter un autre chemin.
- Travail existant : décidez si les connexions ouvertes peuvent se terminer, doivent se reconnecter ou doivent s'arrêter. Une nouvelle sélection de proxy ne peut pas déplacer une socket établie vers une autre sortie.
Pour les clients participants qui comprennent le proxy, le PAC est une autre conception : conservez la sélection par destination dans le client plutôt que de remplacer sans cesse un point de terminaison statique. Sa diffusion et sa politique de repli doivent néanmoins fonctionner sur les réseaux itinérants.