SSIS Package Protection Level Errors - decrypt protected XML node "DTS:Password" with error 0x8009000B ; failed with error code 0xC0202009.
Error7Error loading GetData.dtsx: Failed to decrypt protected XML node "DTS:Password" 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.c:\Packages\GetData.dtsx11 Error8Validation error. Data Flow Task:OLEDB Source[5310]: The AcquireConnection method call to the connection manager "SourceServer" failed with error code 0xC0202009.GetData.dtsx00Environment I need to execute - BIDSHave Solution, with files linked with VSS. When I click on package, aforesaid errors show up and package opens in designed.Protection Level : Encrypt Sesitive with User KeyThis means it'd run only on machine and by user where and who created respectively.So I changed it to Encrypt Sesitive with Passoword and provided Passoword. No luckSo I changed it to Do not save sensitive, as anyways in the connection manager, it has Expression saying @Variablename (with appropriate correct syntax), and variable is mapped to config file. I tired with Config file and also by hardcoding the value in the connection manager's connection string after removing the variable name, also tried by hardcoding value in variable value and disabling config file.Nothing works. I read 3 threads discussing this issue by others, and they all focus on SQL Server Agent, creating proxy accounts, etc. Within BIDS, I think I've exhausted all options. Kindly help someone!
November 30th, 2009 4:52pm

How are you passing the credentials to connect to server? Is "Enable Package Configuration" box checked in SSIS-->Package Configurations?Nitesh Rai- Please mark the post as answered if it answers your question
Free Windows Admin Tool Kit Click here and download it now
November 30th, 2009 5:11pm

Yes, it is checked. Moreover, I passed the credentials to connect to the server by :1) Via package config2) Disabling config and hardcoding in connection manager3) Discabling config and hardcoding in variableAll 3 I tried.
November 30th, 2009 5:14pm

Hi sqlserverdotnet,This behavior occurs if the value of the ProtectionLevel property in the SSIS package is set to provide the maximum amount of protection for the Password property in the SSIS package. By default, the value of the ProtectionLevel property is set to EncryptSensitiveWithUserKey. The EncryptSensitiveWithUserKey value encrypts all the properties of the SSIS package that are considered sensitive, such as the Password property. When the same user account and the same computer that were used to create the SSIS package are used to run the SSIS package, the SSIS package automatically decrypts, and no error message is generated. However, when a different user account or a different computer is used to run the SSIS package, the EncryptSensitiveWithUserKey value of the ProtectionLevel property is engaged, and the Password property of the SSIS package remains encrypted. When this occurs, an error message is generated. Please change the ProtectionLevel Property and that resolved this issue.Thanks,Jin ChenJin Chen - MSFT
Free Windows Admin Tool Kit Click here and download it now
December 2nd, 2009 12:01pm

Hi Jin, I am in same situation. The previous developer had used EncryptSensetiveWithUserKey and now that he no longer works in same organisation I am struggling to find solution for this. I can open all the other files fine, but its only the .dtsx that doesn't open. Is there any possible way to recover this. And on other note, I don't understand why such property is set by default? I think because it is something set by default some developers do not pay attention to it....
September 9th, 2010 9:35pm

Unfortunately, no - it's encrypted, and "a solution" for this would be to break the encryption. You need to open the package, re-enter all the sensitive information, change the ProtectionLevel if you wish, and save the package again. Yes, it can seem crazy that this is the default option. But being the default makes it easy to safeguard sensitive information while still making it easy for the developer to get on with their job. When (or if) the package makes it into production, this setting becomes apparent - although not as obviously as I'd like. In shops with more formalized deployment processes, packages would go through a process of changing this property and handling sensitive information differently. Talk to me now on
Free Windows Admin Tool Kit Click here and download it now
September 9th, 2010 9:49pm

Hi, I have the same problem. You suggest to change the ProtectionLevel Property: in which value do I have to change? Now I Have " EncryptSensitiveWithUserKey ". Thanks a lot,
December 16th, 2010 12:54pm

You need to read the docs on the ProtectionLevel property to understand what the other settings do for you. It doesn't make sense for me to cut and paste that stuff here. Talk to me now on
Free Windows Admin Tool Kit Click here and download it now
December 16th, 2010 9:15pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics