FTP authentication information does not persist when deploying packages

I am trying to deploy a SSIS package which includes a FTP task. It works fine on the machine it was developed . When deploying the package on a production server, all other config changes work, but the FTP task is failing, with authentication error.

any help on how to persist the data would be appreciated

thanks

Maybe it's because the password was stored encrypted and couldn't be decrypted on the new machine... This is quite common and happens often when moving a package from machine to machine.

As far as I know you can get around this by using package passwords instead of the normal encryption. You can also save a package without encryption (what is not recommended...) or use a configuration to push the password back into the package i.e. using an XML file (but then the password is unencrypted in the XML)...

Frustrating Authentication Errors

I have a prospective client evaluating our software that uses a SQL backend
and we're struggling with some errors I can't recreate here in our lab.
When he logs into his laptop and tried to access the SQL db, he get's this
error:
"Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection"
However, when he or the SQL admin log into the SQL admin's PC both can
access the SQL db just fine.
This error only happens on the tester's PC. He even re-imaged the PC and it
still fails. He's running WinXP.
They are running SQL 2000 on a Windows Server 2003 box. Use a mix of AD and
SQL authentication. In this case they have created users for him in both AD
and SQL for this db.
Suggestions?
make named pipes the priority on the clients.
"smutny" <smutny@.discussions.microsoft.com> wrote in message
news:780B2EEF-7C85-4DCE-854B-25F4409DE61F@.microsoft.com...
>I have a prospective client evaluating our software that uses a SQL backend
> and we're struggling with some errors I can't recreate here in our lab.
> When he logs into his laptop and tried to access the SQL db, he get's this
> error:
> "Login failed for user '(null)'. Reason: Not associated with a trusted SQL
> Server connection"
> However, when he or the SQL admin log into the SQL admin's PC both can
> access the SQL db just fine.
> This error only happens on the tester's PC. He even re-imaged the PC and
> it
> still fails. He's running WinXP.
> They are running SQL 2000 on a Windows Server 2003 box. Use a mix of AD
> and
> SQL authentication. In this case they have created users for him in both
> AD
> and SQL for this db.
> Suggestions?

Frustrating Authentication Errors

I have a prospective client evaluating our software that uses a SQL backend
and we're struggling with some errors I can't recreate here in our lab.
When he logs into his laptop and tried to access the SQL db, he get's this
error:
"Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection"
However, when he or the SQL admin log into the SQL admin's PC both can
access the SQL db just fine.
This error only happens on the tester's PC. He even re-imaged the PC and it
still fails. He's running WinXP.
They are running SQL 2000 on a Windows Server 2003 box. Use a mix of AD and
SQL authentication. In this case they have created users for him in both AD
and SQL for this db.
Suggestions'make named pipes the priority on the clients.
"smutny" <smutny@.discussions.microsoft.com> wrote in message
news:780B2EEF-7C85-4DCE-854B-25F4409DE61F@.microsoft.com...
>I have a prospective client evaluating our software that uses a SQL backend
> and we're struggling with some errors I can't recreate here in our lab.
> When he logs into his laptop and tried to access the SQL db, he get's this
> error:
> "Login failed for user '(null)'. Reason: Not associated with a trusted SQL
> Server connection"
> However, when he or the SQL admin log into the SQL admin's PC both can
> access the SQL db just fine.
> This error only happens on the tester's PC. He even re-imaged the PC and
> it
> still fails. He's running WinXP.
> They are running SQL 2000 on a Windows Server 2003 box. Use a mix of AD
> and
> SQL authentication. In this case they have created users for him in both
> AD
> and SQL for this db.
> Suggestions'

Frustrating Authentication Errors

I have a prospective client evaluating our software that uses a SQL backend
and we're struggling with some errors I can't recreate here in our lab.
When he logs into his laptop and tried to access the SQL db, he get's this
error:
"Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection"
However, when he or the SQL admin log into the SQL admin's PC both can
access the SQL db just fine.
This error only happens on the tester's PC. He even re-imaged the PC and it
still fails. He's running WinXP.
They are running SQL 2000 on a Windows Server 2003 box. Use a mix of AD and
SQL authentication. In this case they have created users for him in both AD
and SQL for this db.
Suggestions'make named pipes the priority on the clients.
"smutny" <smutny@.discussions.microsoft.com> wrote in message
news:780B2EEF-7C85-4DCE-854B-25F4409DE61F@.microsoft.com...
>I have a prospective client evaluating our software that uses a SQL backend
> and we're struggling with some errors I can't recreate here in our lab.
> When he logs into his laptop and tried to access the SQL db, he get's this
> error:
> "Login failed for user '(null)'. Reason: Not associated with a trusted SQL
> Server connection"
> However, when he or the SQL admin log into the SQL admin's PC both can
> access the SQL db just fine.
> This error only happens on the tester's PC. He even re-imaged the PC and
> it
> still fails. He's running WinXP.
> They are running SQL 2000 on a Windows Server 2003 box. Use a mix of AD
> and
> SQL authentication. In this case they have created users for him in both
> AD
> and SQL for this db.
> Suggestions'