rasdial Says Connected. When Is the Network Actually Ready?

A script that opens the VPN window and then sleeps for ten seconds is guessing, and the guess is wrong in both directions: it starts the copy before the tunnel is usable, or it waits after the work could have begun. Neither outcome tells you whether authentication finished. Use the command's own result, then ask the service a question it can actually answer. The order of those two steps is the whole design.

What the command actually reports

For a native Windows profile that the installed command-line tool understands, rasdial.exe dials a named entry and returns a process exit code. That code describes the dial attempt: zero means the connection was established for that profile, and non-zero means it failed at a stage the code identifies. Read it as the result of one layer, not of the job.

The result says nothing about address assignment, private DNS, added routes or the permission to reach a particular server. All of those happen after a successful dial, and any of them can still be wrong. That gap is why a connected icon and a failed copy coexist so often.

Capture the result before anything else runs

Start by confirming that the profile exists for the account that will run the job, not just for the account you are testing with:

Get-VpnConnection -Name "Contoso-Office"
Get-VpnConnection -Name "Contoso-Office" -AllUserConnection

Then dial and read the code immediately. PowerShell keeps the native result in $LASTEXITCODE only until the next external command runs, so a stray ping between the dial and the check destroys the value you meant to read. Assign it to your own variable first, then decide what to do.

& rasdial.exe "Contoso-Office"
$dial = $LASTEXITCODE
if ($dial -ne 0) { throw "rasdial failed with $dial" }

Log the code with the non-secret error text, because a missing entry, a rejected credential and a timeout need different responses. The table maps the common results to the next action.

Readiness is the resource, not the tunnel

Once the dial succeeds, test the thing the job needs. A share, an API endpoint or a database port is a better readiness probe than a public website, because a public site answers through any working path and proves nothing about the private one. Pick the probe the application itself depends on. A successful TCP connect tells you routing and filtering are open, which is most of what the first write needs:

Test-NetConnection -ComputerName files.contoso.example -Port 445

Bound the attempts and record which stage failed. A rejected credential should stop the script rather than feed a retry loop; a DNS name that has not appeared yet deserves a few short retries; a port that never opens is a routing or policy problem above the client.

Where the connection already existed before the job started, leave it alone. Disconnecting a session you did not open interrupts the user's other work, so record who owns the session and what teardown is appropriate.

Scope the profile to the account that runs the job

A scheduled task runs under its own identity and session, and a profile that works on your desktop can be invisible there. Re-run the visibility check and the dial under the task's account before trusting the schedule. Keep the password off the command line as well: arguments are visible to other processes and often end up in logs.

If the deployment requires a browser prompt, a smart-card tap or an MFA approval, that interaction is part of the design and cannot be automated away by simulating keystrokes. Use the supported client for that case and let the human step happen.

The shape of the final script stays short: check the profile, dial, read the code, probe the resource, then start the work. Each step answers a question the previous one could not, and none of them relies on a sleep.