В кой телефонен указател търси задача SYSTEM профили за VPN?

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

Две хранилища държат едно и също име на профил

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

Прочетете двете хранилища от една и съща сесия и сравнете имената, които връщат. Превключвателят избира глобалното хранилище и четенето му обикновено изисква повишена сесия:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType

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

Прочетете principal на задачата преди идентификационните ѝ данни

Отворете задачата и прочетете principal, защото той ви казва кое хранилище може да види задачата. Задача, настроена да работи като SYSTEM, не е вашият акаунт с допълнителни права: тя има свой собствен профил и няма достъп до телефонния указател за отделен потребител, който сте създали, докато сте влезли. Сервизният акаунт се държи по абсолютно същия начин.

Опцията за изпълнение независимо дали сте влезли, също променя това, защото тогава задачата няма интерактивна сесия, чиито идентификационни данни да заеме. Нека действието запише whoami във файл и прочетете отговора, вместо да го предполагате.

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

Намирането на профила не е влизане

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

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

Неинтерактивните предизвикателства са капанът зад този етап. Подкана за PIN или еднократен код не могат да бъдат отговорени от задача без работен плот, така че профил, който се свързва перфектно на ръка, може да е неизползваем при автоматизация.

Четири полета, от които се нуждае записът на задачата

Дръжте стойностите, които решават изхода, заедно на едно място, защото три от тях обикновено остават неявни. Записът се нуждае от четири реда:

• Път на действието: скриптът или изпълнимият файл, който задачата стартира, а не пряк път, който се разрешава различно за друг акаунт.
• Име на профила: точният низ, защото две хранилища могат да държат едно и също име, сочещо към различни сървъри.
• Principal: акаунтът, от който работи задачата, и дали има интерактивна сесия.
• Метод на удостоверяване: какво този principal всъщност може да завърши, например сертификат от хранилището на компютъра, а не ключ в потребителския ви профил.

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

Открийте етапа, до който е стигнала задачата

Инструментирайте действието, вместо да гадаете от резултата на последното изпълнение. Кратка обвивка записва самоличността, хранилището, което вижда, и изхода от свързването на едно място:

whoami
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress
rasdial "Office"
schtasks /query /tn "VPN Connect" /v /fo LIST

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

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