Drive Maps Before the VPN Is Ready? Gate It on the Server

The drive letter appears at logon and then opens as an empty folder, or with a red cross and a message about an unavailable network resource. Permissions are usually fine. What happened is that the mapping command ran during the window where the VPN client existed but no route to the file server did, and Windows recorded that failure as the state of the drive. The fix is to stop treating the mapping as something that happens at logon and treat it as the last step of a connection sequence.

Why the map runs too early

A sign-in script starts when the session starts. A VPN client that connects during logon adds its own timeline on top: the process can be running, the virtual adapter can exist, and the route to the office subnet can still be missing. Those three states look similar from a script's point of view and only one of them works.

Some environments respond by repeating the same failing line at every logon, which produces a user who has learned to click the drive twice and a script that has never once succeeded on its own.

The drive itself makes this worse. A mapped drive is a session object, and once Windows has marked it unavailable, the icon can stay broken long after the tunnel is healthy. That is why remapping by hand works while the script appears to do nothing. The session remembers the failure, not the intention behind it.

A connected status is not a path

The VPN tray icon reports whether the tunnel is up. It says nothing about whether a route to a particular server exists, whether DNS resolves that name to the tunnel address, or whether the server's own firewall accepts you.

Those are three separate failures with the same visible outcome, and gating on the tray icon collapses them into one unreliable signal.

A readiness check that names the server you actually need distinguishes them, because it fails until the specific path works rather than until some interface reports itself as connected.

Gate on the server, not on the client

Pick one host that is only reachable through the tunnel and wait for it before mapping anything. The fragment below connects a saved Windows VPN entry, polls the file server, and then maps the drive.

@echo off
set server=fileserver.corp.example
rasdial "Office VPN" /disconnect
rasdial "Office VPN"
:wait
ping -n 1 -w 1000 %server% >nul || (
  timeout /t 5 /nobreak >nul
  goto wait
)
net use Z: \\%server%\share /persistent:no

The ping is a readiness probe, not a permissions test. If ICMP is filtered on your network, probe the service you actually use instead: net view \\%server% for a quick check, or a short TCP test against port 445 in PowerShell. Either one gates on the thing that matters.

Add a bounded number of attempts. A wait loop with no ceiling turns a broken tunnel into a session that never finishes logging in, which is a worse support call than a missing drive letter.

Make it rerunnable and session-aware

Run it inside the user's own session. A task that runs as SYSTEM puts the drive in a different session entirely, and the logged-on user never sees the result. That gives you a script reporting success and a desktop with no drive in it.

Check before you map, and remove only the stale entry. net use Z: /delete returns an error when the letter is unused, and that error is safe to ignore rather than a reason to abandon the rest of the script. Keep /persistent:no so a failed attempt does not turn into a permanent reconnection attempt later.

And do not put a password in the file. rasdial can reuse credentials saved for the VPN entry, and the share should authenticate as the signed-in user. If the share genuinely needs different credentials, register them once per user with cmdkey instead of embedding them in a batch file that lives on a logon share. Anyone who can read that share can read the password, which turns a convenience into an incident.

Re-running the whole script should be harmless, because that is what will happen. Users reconnect, laptops wake, and the same code path runs again with a different starting state.

Log enough to prove which half was late

Write the timestamp, the readiness result and the mapping exit code to a file under the user profile. When the next report of a missing drive arrives, that log answers the only question that matters: did the tunnel arrive late, or did the share refuse?

Without it, every recurrence is investigated from scratch, and the usual conclusion is a permissions change that fixes nothing.

Test the sequence once from a cold boot and once from sleep. The wake case is where ordering breaks most often, because the session resumes before the network does and the script sees a machine that has been logged in for hours.