Futtat egy parancsot egy VPN-profil ellen, az nem ad vissza hibát, és a felhasználó által indított kapcsolat pontosan úgy viselkedik, mint korábban. Semmi sem tört el. A Windows két tárolóban tartja a natív VPN-profilokat, és Ön azt szerkesztette, amelyik nincs játékban. Ugyanaz a megjelenített név létezhet mindkettőben, és ezért tűnik egy szkript sikeresnek, miközben a felhasználó kapcsolata figyelmen kívül hagyja minden módosítását.

A megoldás nem egy jobb szkript; hanem hogy a hatókört a profil előtt nevezze meg.

A tünet és a két tároló

A Windows a natív VPN-profilokat felhasználónkénti telefonkönyvben és gépszintű, minden felhasználóra kiterjedő telefonkönyvben tartja. A Get-VpnConnection az aktuális felhasználó tárolóját olvassa, a Get-VpnConnection -AllUserConnection pedig a gépét.

Az -AllUserConnection kapcsolóval létrehozott profil a gépen minden fiók számára megjelenik, és létrehozásához vagy eltávolításához emelt szintű munkamenet kell. A nélküle létrehozott profil ahhoz a fiókhoz tartozik, amelyik a parancsot futtatta, és egy másik bejelentkező felhasználó semmit sem lát. Mindkettő viselheti ugyanazt a nevet, és egyik sem figyelmezteti, hogy a másik létezik. Ezért néz ki a tünet csendes hibaként, és nem hibaüzenetként.

Mit dönt el valójában a hatókör

A hatókör két kérdésre válaszol, a harmadikra pedig nem hajlandó:

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

Pont az utolsó két sort értik félre az emberek. A minden felhasználóra kiterjedő profil gépszintű tároló, nem gépidentitás, és önmagában nem teszi elérhetővé a kapcsolatot, mielőtt valaki bejelentkezik. A Windows Always On eszköz-alagút külön konfiguráció, saját tanúsítvány- és profilkövetelményekkel. A hatókör arról szól, ki láthat egy profilt, nem arról, mi a gép.

A láthatóság nem hitelesítés

A minden felhasználóra kiterjedő profilnak továbbra is támogatott identitás- és hitelesítőadat-elrendezés kell. A profil minden fiók számára láthatóvá tétele nem teszi minden fiókot ugyanazzá a hitelesített felhasználóvá, és nem vonja össze a hitelesítő adatokat.

Ha a tervezés azt kívánja, hogy az alagút bejelentkezés előtt álljon, a válasz egy eszköz-alagút, nem pedig szélesebb profilhatókör. Ha a tervezés azt kívánja, hogy mindenki a saját tanúsítványát mutassa be, a felhasználónkénti profil jobban illeszkedik ehhez a modellhez, mert a gépszintű profil nem tud olyan hitelesítő adatot bemutatni, amely valaki máshoz tartozik.

Telepítés és házirend-tulajdon

Kezelt gépeken egy EMM vagy egy konfigurációs profil a módosítása után újra létrehozhatja a mentett állapotot.

Ez nem hiba a szkriptjében; ez két tulajdonos, aki ugyanabba a tárolóba ír. Hangolja össze a hatókört a házirend tulajdonosával, és inkább a házirendet módosítsa, mint hogy a parancsát ütemezés szerint újrafuttassa. A házirenddel versengő helyi javítás olyan gépet eredményez, ahol a profil a következő szinkronizálásig helyesnek látszik.

Mit rögzítsen, amikor elromlik

Három dolgot rögzítsen együtt: a profil nevét, a megcélzott hatókört és a tényleges kapcsolathibát.

Egy másik tárolóban lévő profilra alkalmazott útvonal vagy tanúsítvány nem javítja meg azt, amelyiket a felhasználó indít, és a hiba szövege továbbra is a kapcsolatra mutat, nem a szerkesztésére. Jóváhagyott módosítás után kapcsolódjon újra a szándékolt belépési ponton keresztül, és vizsgálja meg az alkalmazott útválasztást, valamint a mentett beállításokat. A profiltároló arra válaszol, mi érhető el, míg az aktív kapcsolat arra válaszol, mit tesz most az eszköz.

A Microsoft Add-VpnConnection dokumentációja a hatókör-kapcsolót az általa módosított paraméterek mellett sorolja fel, ami hasznos emlékeztető arra, hogy a hatókör létrehozáskor hozott döntés, nem pedig később átbillentett beállítás.

Kapcsolódó cikkek