October 22, 2015 at 12:30 pm
I have some file processing SSIS package jobs running under SQL proxy. If I run them with myself as the proxy, everything is fine, but once I proxy a different account, no matter what permissions I gave, it would fail.
After a lot of digging, I found the following at the link https://support.microsoft.com/en-us/kb/918760:
"....Reasons that the package may have failed are as follows:
The user account that is used to run the package under SQL Server Agent differs from the original package author..."
Do you have to run the package as the original author? Unless I'm missing something here, it doesn't make any sense to me. What if the author has left the company? What if the author should only have access to dev env and the package has to run in the production env?
Thanks for your input.
October 22, 2015 at 12:47 pm
Reread ...
[p]
...The current user cannot decrypt secrets from the package. This scenario can occur if the current account or the execution account differs from the original package author, and the package's ProtectionLevel property setting does not let the current user decrypt secrets in the package. ...
[/p]
Check the package's ProtectionLevel property setting.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
October 22, 2015 at 12:50 pm
I suspect that the package protection level has been set to EncryptAllWithUserKey. That is where I would start looking.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
October 23, 2015 at 12:14 pm
Thanks, guys. Guess I was not reading.
I checked my package setting, and it was EncryptSensitiveWithUserKey. I don't have any sensitive info stored in the package, so it really shouldn't affect the job. I'll have to do more digging and see what other permissions I'm missing.
October 24, 2015 at 3:03 am
Change it to don't save sensitive and redeploy
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
October 24, 2015 at 5:18 am
October 29, 2015 at 11:03 am
Thanks for asking. Here's the error message:
"Exception has been thrown by the target of an invocation."
I know it has to be a permission issue because the job runs fine under my personal credential. While I was testing all kinds of scenarios, I also ran into errors like "cannot open the file", which further verified my suspicion.
The problem was eventually resolved by giving proper file access permissions. The weird part was that the same permissions were given before but the job still failed. My only explanation would be there was some kind of network security confusion in the midst of our full system migration.
Jayanth_Kurup (10/24/2015)
I know its a bit late to ask this ,but what is the exact error you get when the package fails? Is it a permissions issue or a missing account issue or package could not be read issue?
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply