Reputation: 109
I have a couple of SSIS packages that resides on my local drive at work that run scheduled jobs. I will be leaving my current position in a couple off days, and would like to help my department transition smoothly.
My question is, for the person that will be picking up my duties, how can I transfer these dtsx packages to their computer short of recreating the packages from scratch on their local drive? If I'm not mistaken the SQL Agent runs off the user login account? After my last day my account will be deleted and none of the jobs will run.
Please provide some insight on what's the best approach. Thank you.
Upvotes: 0
Views: 2448
Reputation: 4585
While I agree with HLGEM about best practice, you have a couple of "quick and dirty" options.
One really dirty way is to mess with the service account that the SQL Agent uses. Usually it runs as Local Service or Network Service, but you can make it run under domain credentials that have access to the appropriate data sources. Careful, this is a big security hole.
SQL Agent also has a mechanism for running particular job steps under different credentials. Look into "Credentials" and "Proxies". This setup is really valuable at the server level, but is a lot of extra work just to run a job from a developer's machine.
Finally, there is no reason that SQL Agent has to be involved at all. You can run a dtsx package from command line or from an SSIS repository under the current user's credentials. This works fine if you are running packages as needed. Not so good for scheduled runs.
Upvotes: 0
Reputation: 96572
The best approach is to stop running things locally. SSIS packages should be set up and run on the database server and should use server accounts that won't disappear when people leave. We have a separate account for dev, QA, and staging as well as prod as some of the other environments are onteh same server.
Upvotes: 2