How do I troubleshoot SSIS packages failed execution in a SQL Agent job?

[This is just for sharing information for those common asked questions collected from forums. If you have any better way or feedback, please directly reply in this thread so that community users can benefit from your answers.]

Question:
I have a SSIS package which is running fine in BIDS but when I run it with a SQL Agent job, it fails. What is the problem?
 
Answer:
When you see a SSIS package fails running in a SQL Agent job, you need to first consider the following conditions:
1. The user account that is used to run the package under SQL Server Agent differs from the original package author.
2. The user account does not have the required permissions to make connections or to access resources outside the SSIS package.

You can find the detailed information in this KB article:
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

You can check SQL Server Agent’s activity logs, Windows Event logs and SSIS logs to get more clues. Also the tool Process Monitor is helpful to track the cause of registry or file access related issues.

The following 4 issues are common encountered in the SSIS forum. We also would like to list them here for your reference:
1. The package's Protection Level is set to EncryptSensitiveWithUserKey but your SQL Server Agent service account is different from the SSIS package creator.
2. Data source connection issue.
3. File or registry access permission issue.
4. No 64-bit driver issue.
 
Package Protection Level issue
For the 1st issue, you can follow the following steps to troubleshoot this issue:
1. Check what the Protection Level is in your SSIS package.
2. If the Protection Level is set to EncryptSensitiveWithUserKey, check the Creator in your SSIS package and compare it with the SQL Server Agent Service account.
3. If the Creator is different from the SQL Server Agent Service account, then the sensitive data of the SSIS package could not be correctly decrypted, which will lead to the failure.
 
A common solution to this issue is that you create a proxy account for SSIS in SQL Server Agent and then specify the proxy account as the "Run as" account in the job step. The proxy account must be the same as the SSIS package creator. You can refer to this article for how to create a proxy account:
How to create a proxy account
http://msdn.microsoft.com/en-us/library/ms190698.aspx
 
You can also change the SSIS package protection level to EncryptSensitiveWithPassword and specify the password (/P XXXX) in the command line in the job step. For the command parameters, you can refer to this article:
Dtexec utility
http://msdn.microsoft.com/en-us/library/ms162810.aspx
 
Besides you can import your SSIS package into your SQL Server MSDB database via SQL Server Management Studio (connecting to Integration Services). When you import the package to MSDB, you need to set the ProtectionLevel to "Rely on server storage and roles for access control". After that, add your SQL Server Agent Services account to be a user of MSDB with the db_ssisadmin role. Then connect to your SSIS in SSMS again, right click your SSIS package, click Package Roles, and set both the ReaderRole and Writer Role to db_ssisadmin.
 
Data Source Connection Issue
For the 2nd data source connection issue, it usually happens when you are using Windows Authentication for your data source. In this case, you need to make sure that the SQL Server Agent Services service account or your Proxy account has the permission to access your database.
 
File or Registry Key Access Issue
For the 3rd file or registry access permission issue,  if you know which file or folder your SSIS package need to make sure that your SQL Server Agent Services service account or your Proxy account has the permission to access the file or folder. If you are not very sure of this, you can run SQL Server Process Monitor to monitor your SQL Server Agent Services process and dtexec process when you start running the job. You can analyze the trace to check if there is any ACCESS DENIED message. You can download Process Monitor here:
Process Monitor
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
 
64-Bit Driver Issue
For the 4th issue, this usually happens on a 64-bit server since there is no corresponding 64-bit driver in a 64-bit process. Think about that when your SSIS package is accessing Excel or Access database file while there is no related 64-bit Jet driver, the job of executing your SSIS package will fail. To resolve this issue, before SQL Server 2008, you need to use 32-bit DTEXEC utility in your SQL Server Agent job to execute the SSIS package. In SQL Server 2008, you have a better choice, using the option“Use 32-bit runtime” under the tab “Execution options” of your job step with the “SQL Server Integration Services Package” type.