Hello All,

Rather new to TFS so you will have to forgive me. All of the SSIS
packages that are checked into TFS open like this: 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.
I'm thinking that there should be a better way to manage this. Do
most of you use Package Configurations? Bottom line question is what
is the best way to share packages amoung a team using TFS?

Thank you in Advance!

While I don't use TFS, I am familiar with the error. It happens when one
person saves an SSIS Package with a password in a Connection String, then
another person tries to open the package.

When you have sensitive data (like passwords for Connection Strings), SSIS
will by default encrypt that data using your UserKey. That same UserKey is
obviously needed to also decrypt the same data. A different user openning the
package has a different UserKey, so cannot decrypt the passwords.

It's a minor annoyance during the design phase, but only occurs when
packages get passed around. The REAL trouble arrises when you deploy. What to
do then?

I have some write-up on these issues:
http://toddchitt.wordpress.com/2008/06/30/ssis_pw
and
http://toddchitt.wordpress.com/2008/06/27/ssis_config

They have helped others. Hope they help.
--
Todd C

[If this response was helpful, please indicate by clicking the appropriate
answer at the bottom]


"dba" wrote:

While I don't use TFS, I am familiar with the error. It happens when one
person saves an SSIS Package with a password in a Connection String, then
another person tries to open the package.

When you have sensitive data (like passwords for Connection Strings), SSIS
will by default encrypt that data using your UserKey. That same UserKey is
obviously needed to also decrypt the same data. A different user openning the
package has a different UserKey, so cannot decrypt the passwords.

It's a minor annoyance during the design phase, but only occurs when
packages get passed around. The REAL trouble arrises when you deploy. What to
do then?

I have some write-up on these issues:
http://toddchitt.wordpress.com/2008/06/30/ssis_pw
and
http://toddchitt.wordpress.com/2008/06/27/ssis_config

They have helped others. Hope they help.
--
Todd C

[If this response was helpful, please indicate by clicking the appropriate
answer at the bottom]


"dba" wrote:

While I don't use TFS, I am familiar with the error. It happens when one
person saves an SSIS Package with a password in a Connection String, then
another person tries to open the package.

When you have sensitive data (like passwords for Connection Strings), SSIS
will by default encrypt that data using your UserKey. That same UserKey is
obviously needed to also decrypt the same data. A different user openning the
package has a different UserKey, so cannot decrypt the passwords.

It's a minor annoyance during the design phase, but only occurs when
packages get passed around. The REAL trouble arrises when you deploy. What to
do then?

I have some write-up on these issues:
http://toddchitt.wordpress.com/2008/06/30/ssis_pw
and
http://toddchitt.wordpress.com/2008/06/27/ssis_config

They have helped others. Hope they help.
--
Todd C

[If this response was helpful, please indicate by clicking the appropriate
answer at the bottom]


"dba" wrote:

While I don't use TFS, I am familiar with the error. It happens when one
person saves an SSIS Package with a password in a Connection String, then
another person tries to open the package.

When you have sensitive data (like passwords for Connection Strings), SSIS
will by default encrypt that data using your UserKey. That same UserKey is
obviously needed to also decrypt the same data. A different user openning the
package has a different UserKey, so cannot decrypt the passwords.

It's a minor annoyance during the design phase, but only occurs when
packages get passed around. The REAL trouble arrises when you deploy. What to
do then?

I have some write-up on these issues:
http://toddchitt.wordpress.com/2008/06/30/ssis_pw
and
http://toddchitt.wordpress.com/2008/06/27/ssis_config

They have helped others. Hope they help.
--
Todd C

[If this response was helpful, please indicate by clicking the appropriate
answer at the bottom]


"dba" wrote:

While I don't use TFS, I am familiar with the error. It happens when one
person saves an SSIS Package with a password in a Connection String, then
another person tries to open the package.

When you have sensitive data (like passwords for Connection Strings), SSIS
will by default encrypt that data using your UserKey. That same UserKey is
obviously needed to also decrypt the same data. A different user openning the
package has a different UserKey, so cannot decrypt the passwords.

It's a minor annoyance during the design phase, but only occurs when
packages get passed around. The REAL trouble arrises when you deploy. What to
do then?

I have some write-up on these issues:
http://toddchitt.wordpress.com/2008/06/30/ssis_pw
and
http://toddchitt.wordpress.com/2008/06/27/ssis_config

They have helped others. Hope they help.
--
Todd C

[If this response was helpful, please indicate by clicking the appropriate
answer at the bottom]


"dba" wrote:

While I don't use TFS, I am familiar with the error. It happens when one
person saves an SSIS Package with a password in a Connection String, then
another person tries to open the package.

When you have sensitive data (like passwords for Connection Strings), SSIS
will by default encrypt that data using your UserKey. That same UserKey is
obviously needed to also decrypt the same data. A different user openning the
package has a different UserKey, so cannot decrypt the passwords.

It's a minor annoyance during the design phase, but only occurs when
packages get passed around. The REAL trouble arrises when you deploy. What to
do then?

I have some write-up on these issues:
http://toddchitt.wordpress.com/2008/06/30/ssis_pw
and
http://toddchitt.wordpress.com/2008/06/27/ssis_config

They have helped others. Hope they help.
--
Todd C

[If this response was helpful, please indicate by clicking the appropriate
answer at the bottom]


"dba" wrote:

While I don't use TFS, I am familiar with the error. It happens when one
person saves an SSIS Package with a password in a Connection String, then
another person tries to open the package.

When you have sensitive data (like passwords for Connection Strings), SSIS
will by default encrypt that data using your UserKey. That same UserKey is
obviously needed to also decrypt the same data. A different user openning the
package has a different UserKey, so cannot decrypt the passwords.

It's a minor annoyance during the design phase, but only occurs when
packages get passed around. The REAL trouble arrises when you deploy. What to
do then?

I have some write-up on these issues:
http://toddchitt.wordpress.com/2008/06/30/ssis_pw
and
http://toddchitt.wordpress.com/2008/06/27/ssis_config

They have helped others. Hope they help.
--
Todd C

[If this response was helpful, please indicate by clicking the appropriate
answer at the bottom]


"dba" wrote:

While I don't use TFS, I am familiar with the error. It happens when one
person saves an SSIS Package with a password in a Connection String, then
another person tries to open the package.

When you have sensitive data (like passwords for Connection Strings), SSIS
will by default encrypt that data using your UserKey. That same UserKey is
obviously needed to also decrypt the same data. A different user openning the
package has a different UserKey, so cannot decrypt the passwords.

It's a minor annoyance during the design phase, but only occurs when
packages get passed around. The REAL trouble arrises when you deploy. What to
do then?

I have some write-up on these issues:
http://toddchitt.wordpress.com/2008/06/30/ssis_pw
and
http://toddchitt.wordpress.com/2008/06/27/ssis_config

They have helped others. Hope they help.
--
Todd C

[If this response was helpful, please indicate by clicking the appropriate
answer at the bottom]


"dba" wrote: