Hvilken telefonbog søger en SYSTEM-opgave i efter VPN-profiler?

Din VPN-profil er lige der i Indstillinger, og den planlagte opgave rapporterer stadig, at den ikke kan finde forbindelsen. Intet er beskadiget: det oprindelige Windows VPN-lager er per bruger, medmindre profilen er oprettet som en profil for alle brugere, og en opgave kører som den konto, dens principal angiver. Opgaven læser normalt en telefonbog, som aldrig indeholdt din profil. To kommandoer og én opgaveindstilling er nok til at bevise det, og de er værd at køre, før nogen genopbygger forbindelsen.

To lagre rummer det samme profilnavn

En oprindelig Windows VPN-profil ligger i lageret for den konto, der oprettede den. Det globale lager er en anden telefonbog, som kun fyldes, når profilen oprettes med kontakten for alle brugere i en forhøjet session. Begge kan rumme en profil med samme navn, og ingen af dem er en visning af den anden.

Læs begge lagre fra samme session, og sammenlign de navne, de returnerer. Kontakten vælger det globale lager, og det kræver normalt en forhøjet session at læse det:

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

Hvis den første kommando viser profilen, og den anden ikke gør, vil ingen ændring af legitimationsoplysninger hjælpe en opgave, der kører under en anden konto, fordi medlemskab er problemet og ikke godkendelse. Hvis begge viser den, er lageret ikke årsagen, og næste afsnit gælder. Den ene sammenligning lukker halvdelen af disse sager. Notér, hvilket lager der svarede, og under hvilken konto du kørte kontrollen, fordi svaret er meningsløst uden begge fakta.

Læs opgavens principal før dens legitimationsoplysninger

Åbn opgaven, og læs principal, fordi den fortæller, hvilket lager opgaven kan se. En opgave, der er sat til at køre som SYSTEM, er ikke din konto med ekstra rettigheder: den har sin egen profil og ingen adgang til den telefonbog per bruger, som du oprettede, mens du var logget ind. En tjenestekonto opfører sig præcis på samme måde.

Indstillingen for at køre, uanset om du er logget på, ændrer også dette, fordi opgaven så ikke har nogen interaktiv session, hvis legitimationsoplysninger den kan låne. Lad handlingen skrive whoami i en fil, og læs svaret i stedet for at antage det.

Diagnostik fra din egen terminal siger intet om dette problem, fordi den viser, hvad din konto ser. Kør sammenligningen under opgavens identitet gennem den godkendte proces, du har til det. Output indsat fra en administratorkonsol er et andet datasæt, ikke et mere privilegeret. Hvis en sådan proces ikke findes, må opgaven selv logge svaret, hvilket det sidste afsnit sætter op.

At finde profilen er ikke at logge på

En profil for alle brugere gør konfigurationen bredere synlig. Den bærer ikke den gemte adgangskode fra den konto, der oprettede den, og den giver ikke en anden konto den private nøgle, der er gemt i din brugerprofil. Synlighed og brugbare legitimationsoplysninger er to separate tests, og det at bestå den første siger intet om den anden.

Hvis opgaven nu finder profilen og fejler ved godkendelse, er det fremskridt, og trinnet hører i registret. Flyt certifikatet til maskinlageret, eller lever hemmeligheden gennem udrulningens egen mekanisme, i stedet for at genskabe forbindelsesnavnet igen. At genskabe det giver den samme fejl med et nyere tidsstempel. Microsoft dokumenterer de to scopes som cmdlet-kontakten vælger imellem.

Ikke-interaktive udfordringer er fælden bag det trin. En PIN-meddelelse eller en engangskode kan en opgave uden skrivebord ikke svare på, så en profil, der ringer perfekt manuelt, kan være ubrugelig under automatisering.

Fire felter, som opgaveregistret har brug for

Hold de værdier, der afgør resultatet, samlet på ét sted, fordi tre af dem normalt efterlades implicit. Registret har brug for fire linjer:

• Handlingssti: det script eller den eksekverbare fil, opgaven kører, ikke en genvej, der opløses anderledes for en anden konto.
• Profilnavn: den præcise streng, fordi to lagre kan rumme det samme navn, der peger på forskellige servere.
• Principal: den konto, opgaven kører som, og om den har en interaktiv session.
• Godkendelsesmetode: hvad den principal faktisk kan gennemføre, fx et certifikat fra maskinlageret i stedet for en nøgle i din brugerprofil.

De fire linjer besvarer det spørgsmål, sagen egentlig stiller, nemlig hvilken konfiguration automatiseringen brugte. De overlever også den næste genopbygning af opgaven, når den oprindelige forfatter ikke er der til at forklare, hvorfor navnet betød noget. Uden dem vender den samme fejl tilbage efter den næste udrulning og koster de samme timer igen.

Find det trin, opgaven nåede

Instrumentér handlingen i stedet for at gætte ud fra resultatet af den sidste kørsel. En kort wrapper registrerer identiteten, det lager den kan se, og opkaldsresultatet på ét sted:

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

Opkaldskommandoen udskriver sin egen fejl, som normalt er klarere end en generisk opgavefejl. Forespørgslen returnerer principal og den sidste resultatkode side om side, så identitet og resultat er synlige i én visning. De to fakta afgør, om næste skridt er en lagerændring eller en ændring af legitimationsoplysninger.

Endelig skal du skelne en opgave, der forbinder, efter en bruger logger på, fra en enhedstunnel eller et understøttet workflow før logon. At dele én profil er ikke et design for nogen af dem, og principal-feltet er det, der fortæller dig, hvilken af de tre du har bygget. Hvis forbindelsen skal findes før logon, er profillageret per bruger det forkerte lag at rette.