No permissions to run SSIS Package from SQL Server Agent?

Dylan7

No permissions to run SSIS Package from SQL Server Agent?

by Dylan7 » Sat, 01 Feb 2014 13:31:57

I've been looking everywhere for a hint on how to tackle this, but can't get it to work.

I have an SSIS package that I am trying to run from SQL Server Agent.

I have been able to run it fine from the IDE, and from within the Integration Services system on my database server. However when I try to run the package via SQL Server Agent I get the following error:

"Executed as user: MyDomain\SQLServer. The package execution failed. The step failed."

The login name is the SQL Server service account, which is a domain account on our domain. The package is set with EncryptSensitiveWithPassword and the password is supplied on the command line via the /DECRYPT flag.

I am thinking that maybe there is a permissions problem with the service account, but I can't find any detailed information about what actual permissions this account requires. I have tried expanding its permissions, but continue to get this error.

How should the MyDomain\SQLServer account be configured




Sabott

No permissions to run SSIS Package from SQL Server Agent?

by Sabott » Mon, 03 Feb 2014 14:32:58

The following article addresses this issue and describes several possible causes and resolutions.

"An SSIS package does not run when you call the SSIS package from a SQL Server Agent job Step" (http://support.microsoft.com/kb/918760),


Dylan7

No permissions to run SSIS Package from SQL Server Agent?

by Dylan7 » Tue, 04 Feb 2014 16:35:00

I had seen this article, but it doesn't address my specific issue, which was file system permissions for the log file.

I would encourage anyone experiencing this issue to check the permissions on all these sorts of things (config files, log files, etc)

Thanks,

Dylan.




Dylan7

No permissions to run SSIS Package from SQL Server Agent?

by Dylan7 » Wed, 05 Feb 2014 15:33:59

OK, I solved this one myself.

My service account didn't have permissions to access the share where the log files were stored, so it turned out to be file system permissions.

Thanks for looking, everyone. Carry on with your work...

Dylan.