Vilken telefonbok söker en SYSTEM-uppgift i efter VPN-profiler?

Din VPN-profil ligger precis där i Inställningar, och den schemalagda uppgiften rapporterar fortfarande att den inte hittar anslutningen. Inget är skadat: Windows inbyggda VPN-lager är per användare om profilen inte skapades som en profil för alla användare, och en uppgift körs som det konto som dess principal anger. Vanligtvis läser uppgiften en telefonbok som aldrig innehöll din profil. Två kommandon och en uppgiftsinställning räcker för att bevisa det, och de är värda att köra innan någon bygger om anslutningen.

Två lager håller samma profilnamn

En inbyggd Windows VPN-profil ligger i lagret för det konto som skapade den. Det globala lagret är en annan telefonbok, som bara fylls när profilen skapas med växeln för alla användare i en förhöjd session. Båda kan hålla en profil med samma namn, och ingen av dem är en vy av den andra.

Läs båda lagren från samma session och jämför namnen de returnerar. Växeln väljer det globala lagret, och att läsa det kräver vanligtvis en förhöjd session:

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

Om det första kommandot listar profilen och det andra inte, hjälper ingen ändring av autentiseringsuppgifter en uppgift som körs under ett annat konto, eftersom medlemskap är problemet och inte autentisering. Om båda listar den är lagret inte orsaken och nästa avsnitt gäller. Den enda jämförelsen stänger hälften av dessa ärenden. Anteckna vilket lager som svarade och under vilket konto du körde kontrollen, eftersom svaret är meningslöst utan båda fakta.

Läs uppgiftens principal före dess autentiseringsuppgifter

Öppna uppgiften och läs principal, eftersom den talar om vilket lager uppgiften kan se. En uppgift som är inställd att köras som SYSTEM är inte ditt konto med extra rättigheter: den har en egen profil och ingen åtkomst till telefonboken per användare som du skapade medan du var inloggad. Ett tjänstekonto beter sig precis likadant.

Alternativet att köra oavsett om du är inloggad ändrar detta också, eftersom uppgiften då inte har någon interaktiv session att låna autentiseringsuppgifter från. Låt åtgärden skriva whoami till en fil och läs svaret i stället för att anta det.

Diagnostik från din egen terminal säger ingenting om detta problem, eftersom den visar vad ditt konto ser. Kör jämförelsen under uppgiftens identitet genom vilken godkänd process du än har för det. Utdata som klistrats in från en administratörskonsol är en annan datamängd, inte en mer privilegierad. Om ingen sådan process finns måste uppgiften logga svaret själv, vilket det sista avsnittet ställer in.

Att hitta profilen är inte att logga in

En profil för alla användare gör konfigurationen bredare synlig. Den bär inte det sparade lösenordet från kontot som skapade den, och den ger inte ett annat konto den privata nyckel som lagras i din användarprofil. Synlighet och användbara autentiseringsuppgifter är två separata tester, och att klara det första säger ingenting om det andra.

Om uppgiften nu hittar profilen och misslyckas med autentiseringen är det framsteg och steget hör hemma i registret. Flytta certifikatet till maskinlagret, eller leverera hemligheten via distributionens egen mekanism, i stället för att återskapa anslutningsnamnet igen. Att återskapa det ger samma fel med en nyare tidsstämpel. Microsoft dokumenterar de två omfången som cmdlet-växeln väljer mellan.

Icke-interaktiva utmaningar är fällan bakom det steget. En PIN-förfrågan eller en engångskod kan inte besvaras av en uppgift utan skrivbord, så en profil som ringer perfekt manuellt kan vara oanvändbar under automatisering.

Fyra fält som uppgiftsregistret behöver

Håll värdena som avgör resultatet samlade på ett ställe, eftersom tre av dem vanligtvis lämnas implicita. Registret behöver fyra rader:

• Åtgärdsväg: skriptet eller den körbara filen som uppgiften kör, inte en genväg som löses annorlunda för ett annat konto.
• Profilnamn: den exakta strängen, eftersom två lager kan hålla samma namn som pekar på olika servrar.
• Principal: kontot som uppgiften körs som, och om det har en interaktiv session.
• Autentiseringsmetod: vad den principalen faktiskt kan slutföra, till exempel ett certifikat från maskinlagret i stället för en nyckel i din användarprofil.

De fyra raderna svarar på frågan som ärendet egentligen ställer, nämligen vilken konfiguration automatiseringen använde. De överlever också nästa ombyggnad av uppgiften, när den ursprungliga författaren inte är där för att förklara varför namnet spelade roll. Utan dem återkommer samma fel efter nästa distribution och kostar samma timmar igen.

Fastställ steget som uppgiften nådde

Instrumentera åtgärden i stället för att gissa från resultatet av den senaste körningen. Ett kort omslag registrerar identiteten, lagret det kan se och uppringningsresultatet på ett ställe:

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

Uppringningskommandot skriver ut sitt eget fel, vilket vanligtvis är tydligare än ett allmänt uppgiftsfel. Frågan returnerar principal och den senaste resultatkoden sida vid sida, så identitet och resultat syns i en enda vy. Dessa två fakta avgör om nästa steg är en lagerändring eller en ändring av autentiseringsuppgifter.

Slutligen, skilj en uppgift som ansluter efter att en användare loggar in från en enhetstunnel eller ett arbetsflöde som stöds före inloggning. Att dela en enda profil är inte en design för någon av dem, och principal-fältet är det som talar om vilken av de tre du har byggt. Om anslutningen måste finnas före inloggning är profillagret per användare fel lager att reparera.