Here's what I'm able to do with OpenVPN GUI v 11.12.0.0 in a Windows 10 1903 powershell v5.1.18362.145 script run [b][i][u]manually [/u][/i][/b]in administrator mode: * Automatically connect to an OpenVPN server with the command: & "C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --command connect $ovpn.Config * Wait for connection to complete by pinging the remote router * Do some work * Automatically disconnect with a similar command to the above However when the script is executed under the auspices of the Task Scheduler, run with administrator privileges and "Run with Highest Privileges" checked (as noted in other forum entries), OpenVPN-gui.exe enters the following in the Event>Windows Logs>Application log: [quote]The description for Event ID 0 from source OpenVPN GUI cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: OpenVPN GUI Previous instance not yet ready to accept commands. Try again later. [/quote] In other forum entries it was suggested that the OpenVPN service be changed from Manual to Automatic, which I have done. Ideas as to what I haven't tried to get OpenVPN-gui to cooperate when run as a scheduled task?

[u]Please take note[/u] OpenVPN does [b]not[/b] endorse this script in any way [i]what so ever[/i].

powershell script connect in scheduled task

mcato

Here's what I'm able to do with OpenVPN GUI v 11.12.0.0 in a Windows 10 1903 powershell v5.1.18362.145 script run manually in administrator mode:
* Automatically connect to an OpenVPN server with the command: & "C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --command connect $ovpn.Config
* Wait for connection to complete by pinging the remote router
* Do some work
* Automatically disconnect with a similar command to the above

However when the script is executed under the auspices of the Task Scheduler, run with administrator privileges and "Run with Highest Privileges" checked (as noted in other forum entries), OpenVPN-gui.exe enters the following in the Event>Windows Logs>Application log:

The description for Event ID 0 from source OpenVPN GUI cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

OpenVPN GUI
Previous instance not yet ready to accept commands. Try again later.

In other forum entries it was suggested that the OpenVPN service be changed from Manual to Automatic, which I have done.

Ideas as to what I haven't tried to get OpenVPN-gui to cooperate when run as a scheduled task?

mcato

(Nothing like pressing Submit to think of other ideas)

Wondering if running from Task Scheduler while I'm not logged in, and thus there is no window environment is causing the failure.
When I run the script manually, the dialog pops up showing the status as OpenVPN-gui makes the connection and giving a few seconds to cancel.
Most of the examples I found were for people wanting to make a connection as they logged in, not something happening in an unattended mode.
Is there a lower-level non-gui way of making a connection?
Looking through the OpenVPN.exe --help output (not OpenVPN-gui), there are many parameters to configure how connections are made (--connect-timeout for example), but not a mundane --connect <ovpn-file>.

mcato

In the grand tradition of providing your own answer, here's what I implemented to have scheduled, unattended OpenVPN sessions created, manipulate remote network devices, and then disconnect. I prefer not having "permanent" site-to-site connections so there are log entries on both sides of when I connect (automatically or manually). Hope it saves someone else the time I put into it.

# This is the default path for OpenVPN configurations.
# The configurations were generated by pfSense's built-in OpenVPN with the addition
# of the OpenVPN Client Export package, which generates an executable that installs
# the necessary configuration files (and OpenVPN itself if needed).
$OVPNConfigPath = "C:\Program Files\OpenVPN\config"

# Array of destinations.  Only entries related to connecting with OpenVPN are show here.
$ovpns = @(
    @{  Config = "Dest1-config.ovpn";
          PSkey  = "Dest1-User1.p12";
          TLS    = "Dest1-User1-tls.key";
          Cred   = "Dest1-User1.cred";	# username/password file
	  # ... other stuff for manipulating network devices goes here
    }
    @{ # another destination
    }
    @{ # another destination
    }
)

# openvpn-gui has to be stopped, possibly I'll find other related tasks have to be
# stopped as well, but that happened only once so I'm considering it an anomaly.
Stop-Process -Name "openvpn-gui" -Force 2> $null

$ArgCmd    = "C:\Program Files\OpenVPN\bin\openvpn.exe"

foreach ($ovpn in $ovpns) {
    $ArgConfig = (Join-Path -Path $OVPNConfigPath -ChildPath $ovpn.Config)
    $ArgPKCS   = (Join-Path -Path $OVPNConfigPath -ChildPath $ovpn.PSkey)
    $ArgTLS    = (Join-Path -Path $OVPNConfigPath -ChildPath $ovpn.TLS)
    $ArgUser   = (Join-Path -Path $OVPNConfigPath -Childpath $ovpn.Cred)

    $job = Start-Job -ScriptBlock { & $args[0] --config $args[1] --pkcs12 $args[2] --tls-auth $args[3] --auth-user-pass $args[4] } -ArgumentList @($ArgCmd, $ArgConfig, $ArgPKCS, $ArgTLS, $ArgUser)

    # The line below was uncommented during debugging so I could see what
    # openvpn.exe was complaining about when I didn't have everything correct.
    # $job | Receive-Job

    #
    # Do stuff with remote network devices thru the OpenVPN tunnel here
    # using additional data from the $ovpns array.
    #

    if ($job.State -eq "Running") {
        # Kill the OpenVPN connection
        $job | Stop-Job
        $job | Remove-Job
    }
}

TinCanTech

Please take note

OpenVPN does not endorse this script in any way what so ever.

mcato

Interesting response. Maybe there are some, but I didn't see similar "disclaimers" as above elsewhere in the forum.
Is the implication what I did was wrong, or missing some nuance?
I *did* ask, and not receiving any replies, figured it out with the help of a lot of tidbits scattered across the world. I put it into a single package to further knowledge.
I welcome critiques of what I did and how it can be done better, simpler, more readable, with "correct" conventions, or whatever.

TinCanTech

Hi mcato

please don't be alarmed, you have not done anything wrong by posting this.
But it is only sensible for OpenVPN to make clear that your code is in no way endorsed here.