Windows-prokuraj ensalutaj skriptoj ne spuras postajn retajn ŝanĝojn
Traktu la prokuran elekton ĉe Windows-ensaluto kaj postajn retajn transirojn kiel apartajn eventojn, kun intenca klienta ĝisdatigo kaj konekta politiko.
Tekkomputilo povas ĝuste ricevi la oficejan prokuron ĉe ensaluto kaj konservi ĝin post reveno hejmen. La ensaluta skripto ruliĝis unufoje; ĝi ne abonis ĉiun postan Wi-Fi-ŝanĝon. Fona Grupa Politika prilaborado ne estas promeso relanĉi arbitran ensalutan skripton ĉe transiro.
Difinu la postan konduton eksplicite:
- Ekigilo: administrita aplikaĵo povas uzi la sciigojn de Network List Manager pri konekteca ŝanĝo por ree pripensi la staton. La sciigo mem nek elektas nek skribas prokuron.
- Decido: ekzamenu sufiĉan aktualan retan staton. Unu privata adreso aŭ la unue listigita interfaco estas malforta pruvo kiam Ethernet, Wi-Fi kaj VPN samtempe ekzistas.
- Klienta ĝisdatigo: apliku la agordon tra la interfaco, kiun la klientoj uzas. WinINet-konservo kaj dokumentitaj sciigoj pri agorda ŝanĝo kaj refreŝigo estas apartaj agoj; WinHTTP aŭ privata aplikaĵa agordo povas bezoni alian vojon.
- Ekzistanta laboro: decidu ĉu malfermitaj konektoj rajtas finiĝi, devas rekonektiĝi aŭ devas halti. Nova prokura elekto ne povas movi establitan ingon al alia eliro.
Por partoprenantaj prokur-konsciaj klientoj, PAC estas alia dezajno: tenu la elekton laŭ celo en la kliento anstataŭ ripete anstataŭigi statikan finpunkton. Ĝia liverado kaj rezerva politiko ankoraŭ devas funkcii en la migrantaj retoj.