Do You Have to Run an SSIS Package with Original Package Author Account?

  • 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.

  • 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.



    Alvin Ramard
    Memphis PASS Chapter[/url]

    All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.

    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]

  • Have a read here[/url].

    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

  • 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.

  • 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

  • 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?

    Jayanth Kurup[/url]

  • 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