Gli script di accesso del proxy di Windows non seguono i successivi cambi di rete
Trattate la scelta del proxy all'accesso a Windows e le successive transizioni di rete come eventi distinti, con un aggiornamento deliberato del client e una politica delle connessioni.
Un portatile può ricevere correttamente il proxy dell'ufficio all'accesso e conservarlo dopo il rientro a casa. Lo script di accesso è stato eseguito una volta; non si è sottoscritto a ogni successivo cambio Wi-Fi. L'elaborazione in background dei criteri di gruppo non è una promessa di rieseguire uno script di accesso arbitrario durante una transizione.
Definite esplicitamente il comportamento successivo:
- Innesco: un'applicazione gestita può usare le notifiche di cambio connettività del Network List Manager per riconsiderare lo stato. La notifica in sé non sceglie né scrive un proxy.
- Decisione: ispezionate sufficiente stato attuale della rete. Un solo indirizzo privato o la prima interfaccia enumerata è una prova debole quando Ethernet, Wi-Fi e VPN coesistono.
- Aggiornamento del client: applicate l'impostazione tramite l'interfaccia usata dai client. Il salvataggio WinINet e le notifiche documentate di cambio impostazioni e aggiornamento sono azioni separate; WinHTTP o una configurazione privata dell'applicazione possono richiedere un altro percorso.
- Lavoro esistente: decidete se le connessioni aperte possono terminare, devono riconnettersi o devono fermarsi. Una nuova scelta del proxy non può spostare un socket stabilito su un'altra uscita.
Per i client partecipanti consapevoli del proxy, il PAC è un'altra progettazione: mantenete la scelta per destinazione nel client invece di sostituire ripetutamente un endpoint statico. La sua distribuzione e la politica di riserva devono comunque funzionare sulle reti in roaming.