Изпълнявате команда срещу VPN профил, тя не връща грешка и връзката, която потребителят стартира, се държи точно както преди. Нищо не е счупено. Windows пази вградените VPN профили в две хранилища, а вие сте редактирали това, което не се използва. Едно и също показвано име може да съществува и в двете и точно затова скриптът изглежда успешен, докато връзката на потребителя пренебрегва всяка ваша промяна.

Решението не е по-добър скрипт; то е да назовете обхвата, преди да назовете профила.

Симптомът и двете хранилища

Windows пази вградените VPN профили в телефонен указател за всеки потребител и в машинен указател за всички потребители. Get-VpnConnection чете хранилището на текущия потребител, а Get-VpnConnection -AllUserConnection чете машинното.

Профил, създаден с -AllUserConnection, се появява за всеки акаунт на машината и изисква сесия с повишени права, за да бъде създаден или премахнат. Профил, създаден без него, принадлежи на акаунта, изпълнил командата, а друг потребител, който влезе, не вижда нищо. И двата могат да носят едно и също име и никой от тях не ви предупреждава, че другият съществува. Затова симптомът изглежда като тиха повреда, а не като съобщение за грешка.

Какво всъщност решава обхватът

Обхватът отговаря на два въпроса и отказва да отговори на трети:

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

Именно последните два реда хората разбират погрешно. Профилът за всички потребители е хранилище с обхват на машината, а не машинна идентичност, и сам по себе си не прави връзката достъпна преди някой да влезе. Тунелът за устройство Windows Always On е отделна конфигурация със свои изисквания за сертификат и профил. Обхватът е за това кой може да вижда профила, а не за това какво е машината.

Видимостта не е удостоверяване

Профилът за всички потребители все още се нуждае от поддържана схема за идентичност и идентификационни данни. Правенето на профила видим за всеки акаунт не прави всеки акаунт един и същ удостоверен потребител и не обединява идентификационните данни.

Ако проектът изисква тунелът да е вдигнат преди влизане, отговорът е тунел за устройство, а не по-широк обхват на профила. Ако проектът изисква всеки човек да представи собствения си сертификат, профилът за отделен потребител отговаря по-добре на този модел, защото профил с обхват на машината не може да представи идентификационни данни, които принадлежат на някой друг.

Внедряване и собственост върху политиката

На управлявани машини EMM или профил за конфигурация може да пресъздаде запазеното състояние след вашата промяна.

Това не е дефект в скрипта ви; това са двама собственици, които пишат в едно и също хранилище. Съгласувайте обхвата с този, който притежава политиката, и предпочитайте да промените политиката, вместо да пускате командата си по график. Локално решение, което се състезава с политиката, създава машина, на която профилът изглежда правилен до следващата синхронизация.

Какво да записвате, когато се счупи

Записвайте три неща заедно: името на профила, обхвата, който сте насочили, и действителната грешка на връзката.

Маршрут или сертификат, приложен към профил в другото хранилище, няма да поправи този, който потребителят стартира, и текстът на грешката ще продължи да сочи към връзката, а не към вашата редакция. След одобрена промяна се свържете отново през предвидената входна точка и прегледайте приложеното маршрутизиране, както и запазените настройки. Хранилището на профилите отговаря какво е налично, а активната връзка отговаря какво прави устройството в момента.

Документацията на Microsoft за Add-VpnConnection изброява превключвателя за обхват до параметрите, които той променя, което е полезно напомняне, че обхватът е решение, взето при създаването, а не настройка, която превключвате по-късно.

Подобни статии