Deploy Package Problem

I have a package that runs fine on my dev box. I deploy it to another server and run it by right-clicking and choosing run. I get an error saying it was unable to log in to the server.(Log in failed for user 'myuser') I am using sql authenication and the connection string says persist security info = true. So where is that password stored? Did I miss something when I deployed?

(I have other connections in the package that are windows auth and they work fine)

Data Source=myserver;User ID=myuser;Initial Catalog=Staging;Provider=SQLNCLI.1;Persist Security Info=True;Auto Translate=False;

(I am just trying to get it to run on the other server, I know I may have other issues when I try to run it under sql agent)

Thx

Who is it package running as on the second server and what is the Package's protection level?|||

Thanks for the reply jaegd.

It is running under my id but I am using sql authentication to connect to a remote server and that is where my problem is not with the local server. The part of the package that connects locally under my id works fine, it's only when trying to connect to the remote sever that the password is not being used, I think it is trying to log in with a blank pwd.

Package protection is : EncryptSensitiveWithUserKey

|||

I had the same issue. Even on my own machine, no matter how many times I checked "[ ] Save my Password" it would continue to forget it and fail the connections (all 100+).

I finally have resorted to Windows Authentication which I've heard now from several sources is the preferred / encouraged method. Once I switched all my OLE DB connections over to it, it worked fine. Problem is, you have to have permission on the remote server.

I call BUG.

|||

Found this thread: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=193221&SiteID=1

Which basically says to set your package protection level to DontSaveSensitive and use package configurations for storing passwords, server names, etc.

Simple works for me, only small concern is the passwords are not encrypted (maybe they can be somehow through SSIS) but I can live with it..