Watter telefoonboek deursoek 'n SYSTEM-taak vir VPN-profiele?

Jou VPN-profiel staan reg daar in Instellings, en die geskeduleerde taak rapporteer steeds dat dit nie die verbinding kan vind nie. Niks is beskadig nie: die inheemse Windows VPN-store is per gebruiker, tensy die profiel as 'n all-user-profiel geskep is, en 'n taak loop as watter rekening sy principal ook al noem. Die taak lees gewoonlik 'n telefoonboek wat nooit jou profiel bevat het nie. Twee opdragte en een taakinstelling is genoeg om dit te bewys, en dit is die moeite werd om dit te hardloop voordat iemand die verbinding herbou.

Twee store hou dieselfde profielnaam

'n Inheemse Windows VPN-profiel woon in die store van die rekening wat dit geskep het. Die globale store is 'n ander telefoonboek, wat slegs gevul word wanneer die profiel met die all-user-skakelaar in 'n verhoogde sessie geskep word. Albei kan 'n profiel met dieselfde naam hou, en nie een is 'n aansig van die ander nie.

Lees albei store uit dieselfde sessie en vergelyk die name wat hulle teruggee. Die skakelaar kies die globale store, en om dit te lees vereis gewoonlik 'n verhoogde sessie:

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

As die eerste opdrag die profiel lys en die tweede nie, sal geen geloofsbriefverandering 'n taak help wat onder 'n ander rekening loop nie, want lidmaatskap is die probleem eerder as verifikasie. As albei dit lys, is die store nie die oorsaak nie en geld die volgende afdeling. Daardie enkele vergelyking sluit die helfte van hierdie tickets. Teken aan watter store geantwoord het, en onder watter rekening jy die kontrole gedoen het, want die antwoord is betekenisloos sonder albei feite.

Lees die taak se principal voor sy geloofsbriewe

Maak die taak oop en lees die principal, want dit vertel jou watter store die taak kan sien. 'n Taak wat as SYSTEM gestel is, is nie jou rekening met ekstra regte nie: dit het sy eie profiel en geen toegang tot die per-gebruiker-telefoonboek wat jy geskep het terwyl jy aangemeld was nie. 'n Diensrekening werk presies dieselfde.

Die opsie om te loop of jy aangemeld is of nie, verander dit ook, want die taak het dan geen interaktiewe sessie wie se geloofsbriewe dit kan leen nie. Laat die aksie whoami in 'n lêer skryf en lees die antwoord eerder as om dit te aanvaar.

Diagnostiek uit jou eie terminaal sê niks oor hierdie probleem nie, want dit wys wat jou rekening sien. Hardloop die vergelyking onder die taak se identiteit deur watter goedgekeurde proses jy ook al daarvoor het. Uitset wat uit 'n administrateurkonsole geplak is, is 'n ander datastel, nie een met meer voorregte nie. As daar geen sulke proses bestaan nie, moet die taak self die antwoord aanteken, wat die laaste afdeling opstel.

Om die profiel te vind is nie om aan te meld nie

'n All-user-profiel maak die konfigurasie wyer sigbaar. Dit dra nie die gestoorde wagwoord van die rekening wat dit geskep het nie, en dit gee nie aan 'n ander rekening die private sleutel wat in jou gebruikersprofiel gestoor is nie. Sigbaarheid en bruikbare geloofsbriewe is twee afsonderlike toetse, en om die eerste te slaag sê niks oor die tweede nie.

As die taak die profiel nou vind en by verifikasie misluk, is dit vordering en die stadium hoort in die rekord. Skuif die sertifikaat na die masjienstore, of voorsien die geheim deur die ontplooiing se eie meganisme, in plaas daarvan om die verbindingsnaam weer te skep. Om dit weer te skep lewer dieselfde mislukking met 'n nuwer tydstempel. Microsoft dokumenteer die twee omvange waaruit die cmdlet-skakelaar kies.

Nie-interaktiewe uitdagings is die lokval agter daardie stadium. 'n PIN-oproep of 'n eenmalige kode kan nie deur 'n taak sonder 'n lessenaar beantwoord word nie, so 'n profiel wat met die hand perfek skakel, kan onder outomatisering onbruikbaar wees.

Vier velde wat die taakrekord nodig het

Hou die waardes wat die uitkoms bepaal op een plek bymekaar, want drie van hulle word gewoonlik implisiet gelaat. Die rekord het vier reëls nodig:

• Aksiepad: die script of uitvoerbare lêer wat die taak loop, nie 'n kortpad wat vir 'n ander rekening anders oplos nie.
• Profielnaam: die presiese string, want twee store kan dieselfde naam hou wat na verskillende bedieners wys.
• Principal: die rekening waaronder die taak loop, en of dit 'n interaktiewe sessie het.
• Verifikasiemetode: wat daardie principal werklik kan voltooi, soos 'n masjienstore-sertifikaat eerder as 'n sleutel in jou gebruikersprofiel.

Daardie vier reëls beantwoord die vraag wat die ticket eintlik vra, naamlik watter konfigurasie die outomatisering gebruik het. Hulle oorleef ook die volgende herbou van die taak, wanneer die oorspronklike outeur nie daar is om te verduidelik waarom die naam saak gemaak het nie. Sonder hulle keer dieselfde mislukking terug ná die volgende ontplooiing en kos dit weer dieselfde ure.

Spoor die stadium op wat die taak bereik het

Instrumenteer die aksie in plaas daarvan om uit die laaste loop se resultaat te raai. 'n Kort wrapper teken die identiteit, die store wat dit kan sien en die skakeluitkoms op een plek aan:

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

Die skakelopdrag druk sy eie fout, wat gewoonlik duideliker is as 'n generiese taakmislukking. Die navraag gee die principal en die laaste resultaatkode langs mekaar terug, so identiteit en uitkoms is in een aansig sigbaar. Daardie twee feite bepaal of die volgende stap 'n store-verandering of 'n geloofsbriefverandering is.

Skei laastens 'n taak wat na 'n gebruiker se aanmelding verbind, van 'n toesteltunnel of 'n ondersteunde vooraanmeldingswerkstroom. Om een profiel te deel is nie 'n ontwerp vir enige van die twee nie, en die principal-veld is wat jou vertel watter van die drie jy gebou het. As konnektiwiteit voor aanmelding moet bestaan, is die per-gebruiker-profielstore die verkeerde laag om reg te maak.