Failed to decrypt protected XML node "DTS:Property" in SQL Agent Job

  • We have an SSIS package that a developer is working on that we need to run as a scheduled job. The job is running as a proxy account. The proxy account is a domain service account.

    There is a point in the package where it needs to pull data from an external system. The step has a user name and password associated with it. The problem is, only the developer can successfully run the package. If we try to run it as a scheduled job, we get the error below.

    I have read some different solutions for this, but none that sound very secure. Does anyone know the best practice for this. We have to deploy this package to production. This package CANNOT run under a developer’s credentials. Developers are not allowed access to production systems. No passwords can be visible in any part of the scheduled job.

    How do I enable the proxy account to execute everything in the package?

    Here is the error:

    Description: Failed to decrypt protected XML node "DTS:Property" with error 0x8009000B "Key not valid for use in specified state.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error: 2010-08-06 14:35:02.59 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTS:Property" with error 0x8009000B "Key not valid for use in specified state.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error: 2010-08-06 14:35:02.60 Code: 0xC0016016 Source: Description: Failed to ... The package execution fa... The step failed.

  • May be you have read this already. I would go with any one of the options given in this article.

    Pradeep Adiga
    Blog: sqldbadiaries.com
    Twitter: @pradeepadiga

  • I do have a proxy account setup.

    We tried to save it with ServerStorage but got in error related to the fact that it was not stored in SQL Server. Do you have to deploy it first and then open it up from the server to change it?

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply