Een aanmeldingsscript dat een station koppelt of een synchronisatietaak start, draait voordat de tunnel een adres heeft, dus het faalt stil en de gebruiker repareert het elke ochtend met de hand. Windows biedt de meeste clients geen verbindings-callback per VPN, maar het logt de netwerkwijziging, en die registratie kan het werk op het juiste moment starten. De keuze ligt tussen reageren op die registratie, de resource pollen en de prompt verwijderen die de fout zichtbaar maakte.

De drie mechanismen vergelijken op wat ze garanderen is beter dan ze op elegantie rangschikken. Elk faalt anders, en de faalwijze is wat je daarna meemaakt.

Waarom aanmelding te vroeg afgaat

Aanmelding en opstarten draaien voordat de VPN-adapter zijn adres krijgt, dus een stationstoewijzing, een interne URL of een databaseverbinding die op dat moment wordt geprobeerd heeft noch een route noch een resolver. Het verzoek mislukt, en de sessie blijft achter in een toestand die de gebruiker handmatig moet herstellen. Hetzelfde script naar de opstartmap verplaatsen verandert niets, omdat het volgordeprobleem meeverhuist. De trigger moet een netwerkwijziging zijn en geen sessiegebeurtenis.

Een geplande taak bij aanmelding met een willekeurige vertraging lijkt een oplossing en is in werkelijkheid een gok. Het werkt op een snelle verbinding en faalt op een langzame, wat de minst bruikbare vorm van betrouwbaarheid is.

Drie haken vergeleken

De mechanismen verschillen in wat ze waarnemen, hoe snel ze reageren en wat ze doen bij een herverbinding later op de dag. De tabel vergelijkt ze op die drie punten en niet op hoe slim elk klinkt.

MechanismReacts toCovers a mid-session reconnectTypical failure
Network profile eventA network connect recordYes, when the event repeatsRuns on the wrong network
Resource poll with backoffThe resource becoming reachableYesLog noise and a wasted window
Stored credentials aloneNothing; it removes a promptNoStill fires before the tunnel

Lees de tabel rij voor rij. De gebeurtenishaak is het snelst en het luidruchtigst, omdat Windows elk netwerk vastlegt, ook de Wi-Fi van het café, dus de actie moet de resource verifiëren voordat ze iets doet. De poll is langzamer en nauwkeuriger, omdat die precies slaagt wanneer de share of de hostnaam antwoordt, en hij hoeft niet te weten welke client is geïnstalleerd. Opgeslagen referenties zijn helemaal geen concurrerende optie: ze verwijderen de wachtwoordprompt, wat een tweede en onafhankelijke reden is waarom een toewijzing bij aanmelding mislukt.

Kiezen tussen de eerste twee hangt ervan af of er op de client een bruikbare gebeurtenis bestaat. Waar dat zo is, is een gebeurtenis plus een resourcecontrole de betere standaard.

Bouw de gebeurtenis-trigger correct

De registratie staat in het log Microsoft-Windows-NetworkProfile/Operational, en ID 10001 markeert een netwerk dat zojuist is verbonden. Maak de taak met een trigger Bij een gebeurtenis gericht op dat log, die providernaam en die id. Elk netwerk waar de machine bij komt, zal hem afvuren, dus de actie heeft een beschermende voorwaarde nodig in plaats van een aanname, en ze mag alleen lopen terwijl de gebruiker is aangemeld als het werk gekoppelde stations raakt.

De beschermende voorwaarde moet testen wat de taak echt nodig heeft, zoals een sharepad of een servicepoort, en stil stoppen wanneer dat onbereikbaar is. De adaptornaam testen is niet genoeg, omdat een client één adapter over meerdere profielen kan hergebruiken. Een stille stop houdt het log leesbaar en voorkomt een storm van nieuwe pogingen tegen een netwerk dat de resource nooit zal leveren.

Test dat de taak op het juiste moment loopt

Bewijs het moment en niet de configuratie. De opdrachten hieronder tonen de taakdefinitie, de recente netwerkprofielgebeurtenissen en of de resource bereikbaar is vanaf het account waaronder de taak loopt. Voer ze uit na een echte herverbinding en niet na een handmatige start.

schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoami

Een taakgeschiedenisregel die bestaat terwijl geen netwerkgebeurtenis overeenkomt, betekent dat de trigger fout is en niet de actie. Als de gebeurtenissen verschijnen en de taak niet, loopt de taak misschien onder een account dat de resource niet ziet, en de accountuitvoer is de aanwijzing. Een resourcecontrole die slaagt terwijl de toewijzing nog ontbreekt, wijst op de sessiecontext en niet op connectiviteit. Elk van die drie waarnemingen stuurt je naar een andere oplossing.

Schrijf één logregel per uitvoering met het adres, het resourceresultaat en de uitkomst. De volgende fout laat dan zien of de taak te vroeg liep, op het verkeerde netwerk liep of helemaal niet liep.

Gerelateerde artikelen