What must be taken into account on executing a batch file as scheduled task?

Question

I have a scheduled task that's running, but it doesn't seem to be working. This task executes a batch file. The batch file contains only one line:

wscript c:\myfolder/myscript.vbs

This VBScript file starts a command prompt, executes vpncli, sleeps for one minute, then proceeds to set up a connection sending the user name/password to the command line window.

This works OK when running the batch file from a command prompt window, but no success using the scheduled task. The account that it runs the task under is a service managed account. After running the task, I check in a separate command line window vpncli, and see that the connection is still disconnected.

What must be taken into account on executing batch file in scheduled task to resolve this problem?

Below is part of the code I'm using to execute in a CMD shell. There is executed the following subroutine:

Sub VPN_open
  VPN_Profile = "vpn.myhost.com"
  VPN_User = "USERNAME"
  ' If the password contains special characters, enclose the characters in curly braces {}.
  VPN_Password = "PASSWORD"
  
  oShell.Run "cmd"      
  WScript.Sleep 100
  
  oShell.AppActivate "C:\Windows\System32\cmd.exe"      
  oShell.SendKeys "vpncli connect " & VPN_Profile & "~"
  
  WScript.Sleep 10000
  
  oShell.SendKeys VPN_User & "~"
  
  WScript.Sleep 5000
  
  oShell.SendKeys VPN_Password & "~"
  
  WScript.Sleep 10000
  
  oShell.SendKeys "exit~"      
End Sub 'VPN_open

Answer 1

Using a batch file with just a single command line as scheduled task usually does not make much sense. It would be better to specify directly in scheduled task to run the application executed by the batch file with its parameters which would be in this case %SystemRoot%\System32\wscript.exe with the argument "C:\myfolder\myscript.vbs".

On using just console applications it would be better to use cscript - the console version of Windows Script Host - instead of wscript - the Windows GUI version of Windows Script Host. Help on both applications is displayed on running in a command prompt window cscript /? with help output directly into console window and wscript /? with help shown in a GUI window.

There must be taken into account at least four points on running something as scheduled task:

1. The user account configured in properties of scheduled task.
   
   The used account determines the permissions on local disk as well as on network shares. For example local administrator or system account usually do not have access permissions on any resource on a local network, but have full access to any directory on local drives. It also defines the available environment variables and all region and language dependent settings like date and time format for the commands date and time and the dynamic variables DATE and TIME of the Windows command processor.

2. The current working directory set on starting the scheduled task.
   
   The default directory on starting a scheduled task is %SystemRoot%\System32 if no other folder is configured in properties of scheduled task to use as start in folder. On double clicking a batch file on a drive with a drive letter the directory of the batch file is the current working directory. Any script executed by the batch file should take that into account. Best is to write the script for being independent on current directory by using fully qualified file names for all files including the executables.

3. The environment defined for the scheduled task depends on used account.
   
   There are system environment variables being used for all user accounts and user account related environment variables. On running a scheduled task with a different user account like local administrator or system account some environment variables could not be defined which are defined on running the same script with own user account. It is advisable to make scripts executed as scheduled task being independent on environment variables as much as possible with the exception of system variables defined by Windows automatically like SystemRoot. The Wikipedia article Windows Environment Variables lists and describes the environment variables defined by Windows.

4. Network shares connected as network drives are often not available on running a scheduled task.
   
   Windows stores in registry of current user which network share is connected persistent as network drive. Those network shares are connected (mapped to a drive letter) when the user logs in and are disconnected automatically when user logs out. Running a script as scheduled task with a different account than own account makes the network drives not available for the script because neither the network share is connected as network drive nor has the other account most likely access to network resource at all. And even when having configured in properties of scheduled task to use the own user account the network drives are not available because there is no login before running the scheduled task, except the scheduled task is configured to run only when the user is logged in.
   
   The solution is using in script UNC paths and an account with required access permissions on network resource or map for example with
   
   %SystemRoot%\System32\net.exe use X: \\ComputerName\ShareName password /user:DomainName\AccountName
   
   the share to drive X: and disconnect it before exiting script execution with
   
   %SystemRoot%\System32\net.exe use X: /delete /yes
   
   Run in a command prompt window net use /? for help on this command.
   
   By using for the scheduled task an account with access permissions on network share it is not necessary to specify password and account name in the (batch) script which is much more secure as otherwise everyone with read access to the script file can see the not encrypted password and account name. Windows stores the credentials of the scheduled task encrypted.

So the VB script working fine on manual execution with current user account with current directory being the directory of the batch file with the environment variables defined for current user account and with perhaps connected network drives accessed by the script and the applications called by the script must be investigated for finding the reason why the script does not work as scheduled task with the properties configured for the scheduled task.