Du kör ett kommando mot en VPN-profil, det returnerar inget fel, och anslutningen som användaren startar beter sig precis som tidigare. Inget är trasigt. Windows förvarar inbyggda VPN-profiler i två lager, och du redigerade det som inte används. Samma visningsnamn kan finnas i båda, och det är därför ett skript verkar lyckas medan användarens anslutning ignorerar varje ändring du gjorde.

Lösningen är inte ett bättre skript; den är att namnge omfånget innan du namnger profilen.

Symtomet och de två lagren

Windows förvarar inbyggda VPN-profiler i en telefonbok per användare och i en maskinomfattande telefonbok för alla användare. Get-VpnConnection läser den aktuella användarens lager, och Get-VpnConnection -AllUserConnection läser maskinens.

En profil som skapats med -AllUserConnection visas för varje konto på maskinen och kräver en upphöjd session för att skapas eller tas bort. En profil som skapats utan den tillhör kontot som körde kommandot, och en annan användare som loggar in ser ingenting alls. Båda kan bära samma namn, och ingen av dem varnar dig för att den andra finns. Därför ser symtomet ut som ett tyst fel i stället för ett felmeddelande.

Vad omfånget faktiskt avgör

Omfånget besvarar två frågor och vägrar besvara en 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 är de två sista raderna folk missförstår. En profil för alla användare är lagring med maskinomfång, inte en maskinidentitet, och den gör inte i sig anslutningen tillgänglig innan någon loggar in. En Windows Always On enhetstunnel är en separat konfiguration med egna krav på certifikat och profil. Omfång handlar om vem som kan se en profil, inte om vad maskinen är.

Synlighet är inte autentisering

En profil för alla användare behöver fortfarande en stödd ordning för identitet och inloggningsuppgifter. Att göra profilen synlig för varje konto gör inte varje konto till samma autentiserade användare, och den slår inte ihop inloggningsuppgifter.

Om designen kräver att tunneln är uppe före inloggning, är svaret en enhetstunnel och inte ett bredare profilomfång. Om designen kräver att varje person visar upp sitt eget certifikat, passar en profil per användare bättre för den modellen, eftersom en maskinomfattande profil inte kan visa upp inloggningsuppgifter som tillhör någon annan.

Distribution och policyägande

På hanterade maskiner kan en EMM eller en konfigurationsprofil återskapa det sparade tillståndet efter din ändring.

Det är inte en bugg i ditt skript; det är två ägare som skriver till samma lager. Samordna omfånget med den som äger policyn, och föredra att ändra policyn framför att köra kommandot igen enligt ett schema. En lokal rättelse som konkurrerar med policy ger en maskin där profilen ser korrekt ut till nästa synkronisering.

Vad du ska logga när det går sönder

Logga tre saker tillsammans: profilnamnet, omfånget du siktade på och det faktiska anslutningsfelet.

En rutt eller ett certifikat som tillämpas på en profil i det andra lagret åtgärdar inte den användaren startar, och feltexten kommer att fortsätta peka på anslutningen i stället för på din redigering. Efter en godkänd ändring, återanslut via den avsedda startpunkten och granska både den tillämpade routingen och de sparade inställningarna. Profillagret svarar på vad som är tillgängligt, medan den aktiva anslutningen svarar på vad enheten gör nu.

Microsofts dokumentation för Add-VpnConnection listar omfångsväxeln bredvid de parametrar den ändrar, vilket är en användbar påminnelse om att omfång är ett beslut vid skapandet och inte en inställning du växlar senare.

Relaterade artiklar