Hvilken telefonbok søker en SYSTEM-oppgave etter VPN-profiler i?

VPN-profilen din ligger rett der i Innstillinger, og den planlagte oppgaven rapporterer fortsatt at den ikke finner tilkoblingen. Ingenting er skadet: det opprinnelige Windows VPN-lageret er per bruker med mindre profilen ble opprettet som en profil for alle brukere, og en oppgave kjøres som den kontoen principal-en angir. Vanligvis leser oppgaven en telefonbok som aldri inneholdt profilen din. To kommandoer og én oppgaveinnstilling er nok til å bevise det, og de er verdt å kjøre før noen bygger tilkoblingen på nytt.

To lagre holder samme profilnavn

En opprinnelig Windows VPN-profil ligger i lageret til kontoen som opprettet den. Det globale lageret er en annen telefonbok, som bare fylles når profilen opprettes med bryteren for alle brukere i en forhøyet økt. Begge kan holde en profil med samme navn, og ingen av dem er en visning av den andre.

Les begge lagrene fra samme økt og sammenlign navnene de returnerer. Bryteren velger det globale lageret, og å lese det krever vanligvis en forhøyet økt:

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

Hvis den første kommandoen lister profilen og den andre ikke, vil ingen endring av påloggingsinformasjon hjelpe en oppgave som kjøres under en annen konto, fordi medlemskap er problemet og ikke autentisering. Hvis begge lister den, er lageret ikke årsaken, og neste avsnitt gjelder. Den ene sammenligningen lukker halvparten av disse sakene. Noter hvilket lager som svarte, og under hvilken konto du kjørte kontrollen, fordi svaret er meningsløst uten begge fakta.

Les oppgavens principal før påloggingsinformasjonen

Åpne oppgaven og les principal-en, fordi den forteller deg hvilket lager oppgaven kan se. En oppgave som er satt til å kjøre som SYSTEM er ikke kontoen din med ekstra rettigheter: den har sin egen profil og ingen tilgang til telefonboken per bruker som du opprettet mens du var pålogget. En tjenestekonto oppfører seg nøyaktig på samme måte.

Valget om å kjøre uavhengig av om du er pålogget endrer dette også, fordi oppgaven da ikke har noen interaktiv økt den kan låne påloggingsinformasjon fra. La handlingen skrive whoami til en fil, og les svaret i stedet for å anta det.

Diagnostikk fra din egen terminal sier ingenting om dette problemet, fordi den viser hva kontoen din ser. Kjør sammenligningen under oppgavens identitet gjennom den godkjente prosessen du har for det. Utdata limt inn fra en administratorkonsoll er et annet datasett, ikke et mer privilegert. Hvis en slik prosess ikke finnes, må oppgaven logge svaret selv, noe det siste avsnittet setter opp.

Å finne profilen er ikke å logge på

En profil for alle brukere gjør konfigurasjonen bredere synlig. Den bærer ikke det lagrede passordet fra kontoen som opprettet den, og den gir ikke en annen konto den private nøkkelen som er lagret i brukerprofilen din. Synlighet og brukbar påloggingsinformasjon er to separate tester, og å bestå den første sier ingenting om den andre.

Hvis oppgaven nå finner profilen og feiler ved autentisering, er det fremgang, og trinnet hører hjemme i registret. Flytt sertifikatet til maskinlageret, eller lever hemmeligheten gjennom distribusjonens egen mekanisme, i stedet for å gjenopprette tilkoblingsnavnet igjen. Å gjenopprette det gir samme feil med et nyere tidsstempel. Microsoft dokumenterer de to områdene som cmdlet-bryteren velger mellom.

Ikke-interaktive utfordringer er fellen bak det trinnet. En PIN-forespørsel eller en engangskode kan ikke besvares av en oppgave uten skrivebord, så en profil som ringer perfekt manuelt kan være ubrukelig under automatisering.

Fire felt som oppgaveregistret trenger

Hold verdiene som avgjør resultatet samlet på ett sted, fordi tre av dem vanligvis blir stående implisitt. Registret trenger fire linjer:

• Handlingssti: skriptet eller den kjørbare filen oppgaven kjører, ikke en snarvei som løses annerledes for en annen konto.
• Profilnavn: den nøyaktige strengen, fordi to lagre kan holde samme navn som peker på forskjellige servere.
• Principal: kontoen oppgaven kjøres som, og om den har en interaktiv økt.
• Autentiseringsmetode: hva den principal-en faktisk kan fullføre, for eksempel et sertifikat fra maskinlageret i stedet for en nøkkel i brukerprofilen din.

De fire linjene svarer på spørsmålet saken egentlig stiller, nemlig hvilken konfigurasjon automatiseringen brukte. De overlever også den neste gjenoppbyggingen av oppgaven, når den opprinnelige forfatteren ikke er der for å forklare hvorfor navnet var viktig. Uten dem kommer samme feil tilbake etter neste distribusjon og koster de samme timene igjen.

Finn trinnet oppgaven nådde

Instrumenter handlingen i stedet for å gjette fra resultatet av siste kjøring. En kort wrapper registrerer identiteten, lageret den kan se og oppringsresultatet på ett sted:

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

Oppringingskommandoen skriver ut sin egen feil, som vanligvis er klarere enn en generisk oppgavefeil. Spørringen returnerer principal-en og den siste resultatkoden side om side, så identitet og resultat er synlige i én visning. De to fakta avgjør om neste steg er en lagerendring eller en endring av påloggingsinformasjon.

Til slutt, skill en oppgave som kobler til etter at en bruker logger på, fra en enhetstunnel eller en støttet arbeidsflyt før pålogging. Å dele én profil er ikke et design for noen av dem, og principal-feltet er det som forteller deg hvilken av de tre du har bygget. Hvis tilkoblingen må finnes før pålogging, er profillageret per bruker feil lag å reparere.