Errors Deploying an SSIS package

Hi All,

I hope someone can help becuase this problem is issue us several headaches.

We are currently trying to deploy an SSIS package to a production server. The deployment goes fine, the package runs ok when executed manually. The issues start when we try and execute it under the SQL agent.

Having gone back to the drawing board and spent much of the day reading various articles and applying the various options (especially those within the MS KB article 918760), we are still no closer to a resolution.

The SSIS package was created under an Administrator, and the SQL agent runs under a different Domain Admin account.

When we set up the Schedule to read from SQL Server or the SSIS Store the standard "Executed as user: DOMAIN\USERNAME. The package execution failed. The step failed" in the history.

We tried to create the package as a file access and now get "Package could not be found" even though you can browse to i in the schedule list. The Domain account as full access to the folder where the package resides.

Has anyone else come across this issue, or have a workable solution?

Many TIA.

But does the SQL Server service account have access to everything? Not the Agent user, but the SQL Server service account?|||

Phil,

Thanks for the assist, adding access rights the SQL Server Account ot the database helped, and it seems to have fixed one issue in that it now adds the /Decrypt item to the when saved as EncryptWithPassword, and stores the information.

We have decided to run the package from the SQL server rather than a file, However we still get the same permission error when running the job in SQL agent.

Any more ideas?

|||

This KB article maqy help

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

|||

Thanks for the Pointer Rafael, but we have already tried to apply the workrounds mentioned in the articles with no joy.

I'm coming to the conclusion that MS have really over done the security model for SSIS, I still pondering what the point of of the EncryptWithUserKey setting is as most jobs will generally need to be scheduled and run under the SQLAgent account.