Du kjører en kommando mot en VPN-profil, den returnerer ingen feil, og tilkoblingen brukeren starter, oppfører seg nøyaktig som før. Ingenting er ødelagt. Windows oppbevarer innebygde VPN-profiler i to lagre, og du redigerte det som ikke er i bruk. Samme visningsnavn kan finnes i begge, og det er derfor et skript ser ut til å lykkes mens brukerens tilkobling ignorerer hver endring du gjorde.

Løsningen er ikke et bedre skript; den er å navngi omfanget før du navngir profilen.

Symptomet og de to lagrene

Windows oppbevarer innebygde VPN-profiler i en telefonbok per bruker og i en maskinomfattende telefonbok for alle brukere. Get-VpnConnection leser lagret til gjeldende bruker, og Get-VpnConnection -AllUserConnection leser maskinens.

En profil opprettet med -AllUserConnection vises for hver konto på maskinen og krever en forhøyet økt for å bli opprettet eller fjernet. En profil opprettet uten den tilhører kontoen som kjørte kommandoen, og en annen bruker som logger på ser ingenting. Begge kan bære samme navn, og ingen av dem varsler deg om at den andre finnes. Derfor ser symptomet ut som en stille feil i stedet for en feilmelding.

Hva omfanget faktisk avgjør

Omfanget svarer på to spørsmål og nekter å svare på et tredje:

QuestionCurrent userAll users
Who can see the profileThe account that created itEvery account on the machine
Elevation to create or removeNot requiredRequired
Where the profile livesPer-user phone bookMachine-wide phone book
Does it authenticate a deviceNoNo
Does it start before sign-inNoNo, that needs a device tunnel

Det er de to siste radene folk tar feil av. En profil for alle brukere er lagring med maskinomfang, ikke en maskinidentitet, og den gjør ikke i seg selv tilkoblingen tilgjengelig før noen logger på. En Windows Always On enhetstunnel er en egen konfigurasjon med egne krav til sertifikat og profil. Omfang handler om hvem som kan se en profil, ikke om hva maskinen er.

Synlighet er ikke autentisering

En profil for alle brukere trenger fortsatt en støttet ordning for identitet og påloggingsinformasjon. Å gjøre profilen synlig for hver konto gjør ikke hver konto til den samme autentiserte brukeren, og den slår ikke sammen påloggingsinformasjon.

Hvis designet krever at tunnelen er oppe før pålogging, er svaret en enhetstunnel og ikke et bredere profilomfang. Hvis designet krever at hver person legger fram sitt eget sertifikat, passer en profil per bruker bedre til den modellen, fordi en maskinomfattende profil ikke kan legge fram påloggingsinformasjon som tilhører noen andre.

Utrulling og eierskap til policy

På administrerte maskiner kan en EMM eller en konfigurasjonsprofil gjenopprette den lagrede tilstanden etter endringen din.

Det er ikke en feil i skriptet ditt; det er to eiere som skriver til samme lager. Koordiner omfanget med den som eier policyen, og foretrekk å endre policyen framfor å kjøre kommandoen på nytt etter en tidsplan. En lokal rettelse som konkurrerer med policy, gir en maskin der profilen ser riktig ut til neste synkronisering.

Hva du skal logge når det knekker

Logg tre ting sammen: profilenavnet, omfanget du siktet på, og den faktiske tilkoblingsfeilen.

En rute eller et sertifikat brukt på en profil i det andre lagret retter ikke den brukeren starter, og feilteksten vil fortsette å peke på tilkoblingen i stedet for på redigeringen din. Etter en godkjent endring, koble til på nytt via det tiltenkte inngangspunktet og undersøk både rutingen som er brukt og de lagrede innstillingene. Profillageret svarer på hva som er tilgjengelig, mens den aktive tilkoblingen svarer på hva enheten gjør nå.

Microsoft-dokumentasjonen for Add-VpnConnection lister omfangsbryteren ved siden av parameterne den endrer, noe som er en nyttig påminnelse om at omfang er en beslutning ved opprettelsen, ikke en innstilling du bytter senere.

Relaterte artikler