SSIS deployed on different server to creation

[mossbs]

Hi guys,

Pulling my hair out on this one.

I have an SSIS package that imports data, runs some SPs to create a report, then exports this data to excel, then emails the excel file off.

Problem I'm getting i think is to do with the fact i am creating and building the package locally - then promoting it to the Live SQL SVR.

What are the fundemental 'rules'/'pre-requsites' for building on one machine and deploying to another?

I think i have them all checked off...

- Same User account creates as runs (with windows auth for SQL)
- user account has access to all relevant areas of folder structure (shares) to read/write the import/export files.
- user account has access to SMTP to email the report.

Is there anything i am missing?

I have tried the different package encryption (withUSerKey and withPassword) neither seem to work!

If you could possibly provide a 'check list' or any kind of advice that would be awesome.

Cheers guys

 

[SQLBill]

Do you have to encrypt it? Try using the last option on the drop down - Rely on the Server Storage and Roles for Access Control. As far as I understand it, encryption is based on a hash built partially on the computer mac address....so when you load it on a different machine from where it was created, the encryption changes.

-SQLBill

The following is part of my signature block and is only intended to be informational.
Posting advice: FAQ481-4875

 

[SQLScholar]

Are there any passwords involved (to connect to anywhere)- do you have a password written in the SSIS?

----------------------------------------

http://www.fountain.me.uk

Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind - Bernard Baruch

Computer Science is no more about computers than astronomy is about telescopes - EW Dijkstra
----------------------------------------

 

[mossbs]

Cheers for the replies guys, turns out I had everything checked - someone had been in and changed the credential i had assigned against the user account running the SQL Job (Grrrrr!) meaning the SQL Proxy account didnt actually have access to the required places.

All sorted though!

Cheers again.