Kial uzantoj malŝaltas Always On kaj la profilo restigas ĝin malŝaltita

Uzanto malmarkas Aŭtomate konekti, kaj la profilo ĉesas konekti. Monatojn poste la disvastiga teamo liveras ĝisdatigitan profilon kun la sama nomo, atendas ke la ellasilo revenu, kaj ĝi ne revenas. La kialo estas ke la elekto neniam estis nur en la profilo: Vindozo registris la decidon de la uzanto ĉe tiu profila nomo en sia propra stato, kaj reinstalo ne forviŝas ĝin. La profila dosiero estas nur duono de la agordo.

Kion la markobutono fakte skribas

Malŝalti la opcion de aŭtomata konekto estas decido por unu aparato, konservata ekster la XML de la profilo. Mikrosofto dokumentas ĝin kiel liston de profilaj nomoj kies aŭtomata ellasilo estas malŝaltita, kaj tial la agordo postvivas la forigon kaj rean aldonon de la profilo.

Tiu dezajno havas sencon el la vidpunkto de la uzanto. Iu sur limigita konekto, kiu malŝaltas aŭtomatan konekton, ne atendas ke la sekva ĝisdatigo de la politiko silentas ŝaltos ĝin reen.

Ĝi ankaŭ signifas ke la profila nomo estas identeco, ne etikedo. Du profiloj kun la sama nomo estas la sama ero por tiu listo, kaj renomigo kreas novan identecon tute sen konservita prefero.

Kial reinstalo de la profilo ne restarigas ĝin

Forigi VPN-konekton kaj reen aldoni ĝin el ĝisdatigita dosiero forigas kaj rekreas la profilan objekton. Ĝi ne forigas la registron de la decido de la uzanto, ĉar tiu registro estas ŝlosita per la nomo, ne per la interna identigilo de la profilo.

Do la ĝisdatigo alvenas, la profilo ekzistas kaj estas ĝuste agordita, kaj la ellasilo tamen ne ekfunkcias. Nenio en la profilo klarigas tion, kaj tial tio estas eskalata kiel rompita disvastigo.

La sama konduto povas esti uzata intence: tenu la profilan nomon stabila kiam la ĝisdatigo celas konservi la saman konekton, kaj ŝanĝu ĝin nur kiam vi volas freŝan komencon. Renomigo por eskapi konservitan preferon funkcias, kaj ĝi ankaŭ lasas la malnovan eron malantaŭe, do la aparato amasigas nomojn kiuj jam rilatas al nenio.

Decidu kiun el tiuj vi volas antaŭ ol tuŝi la XML, ĉar la nomo estas la ŝaltilo.

Unu aktiva profilo, pluraj taŭgaj

Vindozo aplikas aŭtomatajn ellasilojn al limigita aro de profiloj, kaj pluraj taŭgaj profiloj ne igas ĉiujn konekti kiel konkurantajn defaŭltojn. Unu estas aktiva, kaj la ceteraj atendas.

Tio gravas kiam aparato ricevas kaj profilon laŭ uzanto kaj profilon laŭ aparato kun similaj nomoj. Ili ne estas la sama konekto, kaj la aŭtomate konektanta estas tiu kiun elektis la elektaj reguloj, ne nepre tiu kiun vi testis. Testo kiu sukcesis ĉe la alia profilo pruvas nenion pri la ellasilo. Notu kiun profilon respondis antaŭ ol ŝanĝi ion ajn.

Legu la konservitan staton antaŭ ĝisdatigo

Antaŭ ol liveri ajnan profilan ŝanĝon, rigardu kion la aparato nun tenas: la konektan objekton, ĝian staton kaj la konservitan liston de malŝaltitaj aŭtomataj ellasiloj.

Ĉi tiuj komandoj listigas la VPN-konektojn kaj serĉas en la registrejo la dokumentitan valoron:

Get-VpnConnection | Select-Object Name,ConnectionStatus,SplitTunneling
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Network /s /f AutoTriggerDisabledProfilesList

Ero kongruanta kun la profilo kiun vi baldaŭ disvastigos diras ke la elekto de la uzanto jam estas registrita. Tio ne estas difekto por silente ripari; ĝi estas la stato kiun via politiko devas enkalkuli.

Decidu kiun politikon vi volas

Estas du defendeblaj politikoj kaj unu malbona kutimo. La unua respektas la malakcepton de uzanto ĝis la uzanto ŝanĝos ĝin, kaj dokumentas ke la ellasilo estas konsila sur administrataj aparatoj. La dua traktas aŭtomatan konekton kiel postulon de plenumado, kaj tiam la malakcepto tute ne proponiĝu.

La malbona kutimo estas reskribi nerilatan staton por trudi la ellasilon reen, kio funkcias ĝis la sekva ĝisdatigo kaj lasas la aparaton kun agordoj kiujn neniu povas klarigi.

Skribu la elekton kie oni prizorgas la profilon, kune kun la kvar transiroj indaj je revizio: unua provizado, normala ellasilo, permesita ŝanĝo de la uzanto kaj ĝisdatigo al la sama nomo. Aŭtomatigo, enkursiga amplekso kaj devigo de la malkonektita stato estas apartaj kontroloj, kaj la etikedo Always On ne estas garantio pri iu ajn el ili.