Run a Task When the VPN Connects: Event, Poll or Credential?
A logon script runs before the tunnel exists. Compare a network event trigger, a resource poll and stored credentials by what each one guarantees.
A logon script that maps a drive or starts a sync job runs before the tunnel has an address, so it fails quietly and the user repairs it by hand every morning. Windows offers no per-VPN connect callback for most clients, but it does log the network change, and that record can start work at the right moment. The choice sits between reacting to that record, polling the resource, and removing the prompt that made the failure visible.
Comparing the three mechanisms by what they guarantee beats ranking them by elegance. Each fails differently, and the failure mode is what you live with afterwards.
Why Logon Fires Too Early
Logon and startup run before the VPN adapter receives its address, so a drive mapping, an internal URL or a database connection attempted at that moment has neither a route nor a resolver. The request fails, and the session is left in a state the user has to fix manually. Moving the same script to the startup folder changes nothing, because the ordering problem travels with it. The trigger has to be a network change rather than a session event.
A scheduled task at logon with an arbitrary delay looks like a fix and is really a guess. It works on a fast link and fails on a slow one, which is the least useful kind of reliability.
Three Hooks Compared
The mechanisms differ in what they observe, how quickly they react, and what they do about a reconnection later in the day. The table compares them on those three points rather than on how clever each one sounds.
| Mechanism | Reacts to | Covers a mid-session reconnect | Typical failure |
|---|---|---|---|
| Network profile event | A network connect record | Yes, when the event repeats | Runs on the wrong network |
| Resource poll with backoff | The resource becoming reachable | Yes | Log noise and a wasted window |
| Stored credentials alone | Nothing; it removes a prompt | No | Still fires before the tunnel |
Read the table by row. The event hook is fastest and noisiest, since Windows records every network including the cafe Wi-Fi, so the action must verify the resource before doing anything. The poll is slower and more precise, because it succeeds exactly when the share or hostname answers, and it needs no knowledge of which client is installed. Stored credentials are not a competing option at all: they remove the password prompt, which is a second and independent reason a logon-time mapping fails.
Choosing between the first two comes down to whether a usable event exists on the client. Where it does, an event plus a resource check is the better default.
Build the Event Trigger Correctly
The record lives in the Microsoft-Windows-NetworkProfile/Operational log, and ID 10001 marks a network that just connected. Create the task with an On an event trigger aimed at that log, that provider name and that identifier. Every network the machine joins will fire it, so the action needs a guard clause rather than an assumption, and it should run only while the user is logged on if the work touches mapped drives.
The guard clause should test what the task actually needs, such as a share path or a service port, and exit quietly when it is unreachable. Testing the adapter name is not enough, because a client can reuse one adapter across several profiles. A quiet exit keeps the log readable and prevents a retry storm against a network that will never serve the resource.
Test That the Task Runs at the Right Moment
Prove the timing rather than the configuration. The commands below show the task definition, the recent network profile events, and whether the resource is reachable from the account the task runs as. Run them after a genuine reconnect rather than after a manual start.
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoamiA task history entry that exists while no network event lines up means the trigger is wrong rather than the action. If the events appear and the task does not, the task may be running under an account that cannot see the resource, and the account output is the clue. A resource check that passes while the mapping is still missing points at session context instead of connectivity. Each of those three observations sends you to a different fix.
Write one log line per run with the address, the resource result and the outcome. The next failure will then show whether the task ran early, ran on the wrong network, or never ran at all.