Connecting the VPN does not replay your logon script

Your user signs in at home, connects the VPN, and waits for the drive mapping that used to appear by itself in the office. The tunnel comes up, the domain answers, and nothing maps. Nothing is broken: a logon script runs at logon, and a tunnel opened twenty minutes into the session is not a logon. Reading the two as the same event sends people hunting for a VPN fault that does not exist.

Four decisions turn the surprise into a workflow that behaves, and the first is simply knowing which events a script rides on.

Scripts ride on lifecycle events you cannot replay

Computer-side policy is applied when the machine boots and user-side policy when someone signs in, while a background refresh cycles the same settings without restarting anything. That refresh processes the scripts extension, but it does not re-run the individual scripts, which fire only at startup, shutdown, logon or logoff. So gpupdate /force can report success while the mapping is still absent, and a clean refresh is not evidence that the script did anything.

The Microsoft processing reference draws exactly that line between processing the extension and running what it contains, and it is the page to cite when someone insists a refresh should have replayed the script.

Not every script fails offline either. One that reads only local or cached material may have partly succeeded, while one that touches a share fails quietly and leaves no obvious mark. Check the actual script path and what it reaches before blaming the network. The same scrutiny belongs on any claim that a script does not run at logon, since a scheduled task or a client action may be doing the work where nobody is looking.

Attach the work to the connection, not to logon

Three different jobs hide behind the phrase logon script: mapping a drive after the user connects, applying machine configuration before anyone signs in, and pulling updated policy. They have different deadlines, and only the second genuinely needs connectivity before logon. Write the requirement as a sentence with a deadline in it, such as this mapping must exist within a minute of the tunnel coming up.

For work that must happen after connection, use a connection-triggered task or the connection action the client supports. Check which event the client actually emits, because an event raised by the native Windows VPN client is not raised by a third-party one. For machine configuration that must precede sign-in, the supported answer is a device tunnel or another pre-logon design, not a task that fires once the desktop appears. Run the work in the identity and session that need it, since a mapping created as SYSTEM lands in a session the user never sees.

Test readiness before acting, and fail loudly

A connection event can arrive before DNS or the file server is usable, so the task should test what it needs rather than assume. Resolve the specific name, attempt the specific connection, and retry with a bound and a delay: Resolve-DnsName files.corp.example inside a short loop separates not-yet from never. Report a concrete failure after the last retry, with the name and the error in it.

An endless loop with no log is indistinguishable from a task that never started, and it hides the difference between a stale credential and a firewall rule.

Verify four things, then make it repeatable

During the pilot, record four observations instead of one: the connection event fired, the task started, the resource answered, and the requested change actually landed. If the log stops at task started, the real failure stays invisible no matter how long you wait. Then run gpresult /scope user /v to see what the session believes its policy is, and compare that with the setting you expected. A report listing the GPO as applied still says nothing about a mapping.

Make the work safe to repeat before you widen it, because the client reconnects and the task fires again. Check for the existing mapping or configuration before creating it, and record what you found. Duplicated work after every transient reconnect is how a helpful task becomes an incident.

Where an automatic trigger is unsuitable, an approved user action that runs the same signed script is a legitimate design. It makes the timing explicit instead of pretending a logon event happened.