Post reply

Timeout problem with PSEXEC in SSIS package when running as a Job.

  • June 21, 2010 at 1:41 pm

    #145731

    Hi,

    I have an SSIS package with an Execute Process Task that calls a bat file to run a remote process. The bat file contains the following line:

    psexec \\DT2K3FS01 -u XXXXX\XXXXX-p XXXXX "C:\Program Files\Access Applications\Executive Desktop\EDProcessor.exe"

    The bat file is located locally to the database server.

    All works OK when I run the SSIS manually - the remote process starts - but when I run the SSIS package from SQL SERVER AGENT as a job it always goes to error :

    Source: Execute Process Task Execute Process Task Description: The process timed out. End Error DTExec: The package execution returned DTSER_FAILURE (1).

    When I run the SSIS package manually and have the Windows Style option of the Execute Process Task set to Window I notice the DOS window does not disappear after the psexec has called the remote process - it just hangs there. This probably has something to do with it

    I have left the default values for the Execute Process Task.

    Any help greatly appeciated - its driving me nuts!!

  • June 21, 2010 at 2:44 pm

    #1182989

    http://support.microsoft.com/kb/918760

    Hope this link helps...

    Let me know

    ------------------
    Why not ?

  • August 9, 2012 at 1:42 pm

    #1524070

    I had a similar issue recently. I remoted into the machine and ran the psexec command that the SSIS package was attempting to run and it worked fine. So I logged off of the machine and logged back in with the credentials used by SQL Server Agent (which is the same credentials the agent job was configured to use) and tried running the psexec command and to my surprise, a window pops with the license agreement and the program wouldn't execute until I clicked the accept button. After that, the scheduled SSIS package worked without issue. Basically, the 1st time you run any of the executables from sysinternals this window pops up and it isn't machine specific, but user specific. I'm sure there is probably a registry entry you could edit, but it's easy enough to login with the agent account credentials or runas the agent account credentials to get this squared away.

  • November 15, 2013 at 3:33 pm

    #1666855

    Hi Jason,

    Thanks a ton for that piece of advice - was exactly what was causing my problem.

    You can use the command -accepteula to avoid this problem from arriving.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply