My script works fine when executed manually, but fails or hangs when run by Windows Scheduler, SSIS or other automation service. What am I doing wrong?

Your script probably depends on your configuration of WinSCP or your local Windows account permissions or environment.

Advertisement

Configuration

There are two common problems that can be caused by relying on external configuration:

  • Your script might fail,1 because the host key (SFTP or SCP) or certificate (FTPS, WebDAVS, S3) is not known by the service’s account, and WinSCP fails its verification.
  • The connection fails, because your script depends on site, which is not known by the service’s account; or the local account that runs the service does not have a network access.

Note that when using registry as configuration storage, the settings are accessible only for your Windows account. When the script is run from Windows Scheduler, SSIS, DTS or other automation service, it is typically run under different (service) account that cannot access your configuration.

To check what configuration storage is used, whether a site name was recognized or under what Windows account the script is running, inspect a beginning of session log. For example, following log shows that the configuration was read from Windows registry, the script was running under local account martin and mysession was recognized as a site name.

-------------------------------------------------------------------------- 
WinSCP Version 5.15.3 (Build 9730) (OS 10.0.18362 - Windows 10 Enterprise)
Configuration: HKCU\Software\Martin Prikryl\WinSCP 2\         
Log level: Normal
Local account: INTRANET\martin                                           
...
Login time: 08 January 2015 08:55:53                                       
-------------------------------------------------------------------------- 
Session name: mysession (Site)                            

Advertisement

If there was no such site in current configuration storage (Windows registry in this case), mysession (as passed to open command) would be interpreted as host name and the log line would say:

Session name: mysession (Ad-hoc session)

Solutions:

Environment variables

If your script refers to user environment variables, they won’t be resolved, if your script run user the service’s account.

Mapped Network Drives

If your script refers to mapped network drives, it may fail if those drives are not mapped under the services’ account or if the account does not even have an access to the network drive.

Use an UNC path to a shared folder, instead of a path to the drive mapped to the shared folder. Make sure the service’s account has an access to the shared folder.

Authentication Agent (Pageant)

Your script might (intentionally or not) rely on Pageant authentication, but the Pageant is running in a different Windows session, so it cannot talk to an automated instance of WinSCP (due to Windows session isolation).

Instead of Pageant authentication, use explicit private key authentication (using -privatekey and -passphrase switches).

General Recommendations

If you are able to log in with WinSCP GUI, have it generate a portable script for you. The generated script takes care of many of the issues mentioned above.

When dealing with SSIS see also guide to SFTP task in SSIS.

Further Reading

Advertisement

  1. Or “hang” in old versions of WinSCPBack
  2. Alternatively make sure the host key or certificate is verified under the service’s account.Back
  3. You can also transfer the site (and/or other settings) to the service’s account instead.Back

Last modified: by martin