VDanner
asked on
SSIS Package containing XCopy will not run as Job in Mgmt Studio
I have an SSIS package which runs fine thru BIDS, as well as when I log on to Mgmt Studio and Execute it manually as a Package. However when set up as a Job, it doesn't seem to run, although it does not fail. It just continues to display "Executing." Research thus far seems to indicate that it is related to the particular step within the package which contains a literal filename path (I'm performing an XCopy). I've tried all different encryption options within the package security settings but it still doesn't run as a job. Does anyone know if I need to set up a Proxy Account, and if so, can you explain exactly how to do this? I am more of a developer than a DBA, but I'm hoping I can at least get enough information to work with our DBA toward a resolution.
ok.. this is actually a three step process..
1) I would create a user account that has permission to the directories in question..
2) go in to SQL 2005 Managment Studio(MS), under security, credentials right click and choose new credential.. fill in a name and then link to the user account you created in step 1.. Fill in the password..
3) in SQL MS click on sql server agent, proxies, Operating System. Right click and and choose new proxy, fill in a name and point to the credential you created in step 2..
now all you need to do is allow the user who is running the job access to the proxy by clicking on principals and choosing who can use it..
This will give your code the needed permissions to run an OS step.. by linking it up to the credential..
If you tell me how you run the step I will try and help you with that as well
1) I would create a user account that has permission to the directories in question..
2) go in to SQL 2005 Managment Studio(MS), under security, credentials right click and choose new credential.. fill in a name and then link to the user account you created in step 1.. Fill in the password..
3) in SQL MS click on sql server agent, proxies, Operating System. Right click and and choose new proxy, fill in a name and point to the credential you created in step 2..
now all you need to do is allow the user who is running the job access to the proxy by clicking on principals and choosing who can use it..
This will give your code the needed permissions to run an OS step.. by linking it up to the credential..
If you tell me how you run the step I will try and help you with that as well
ASKER
DocCan11 - thanks for your response. Remember I'm not much on security so here are my questions:
Since I have access to this path can I not just use my Windows user account? I'm hoping that I can although the way I have attempted it thus far hasn't worked. Not sure how to create a new user account.
Whatever account I do use in Step 2, do I precede this with the DOMAIN? ie DOMAIN\User?
In Step 3 I also added option to Run SSIS packages, because when editing the Job, in the Step page, I can change from "Run As SQL Server Agent" to "Run As proxyname".
Do I need to change anything else within the Job properties, such as name of owner?
Since I have access to this path can I not just use my Windows user account? I'm hoping that I can although the way I have attempted it thus far hasn't worked. Not sure how to create a new user account.
Whatever account I do use in Step 2, do I precede this with the DOMAIN? ie DOMAIN\User?
In Step 3 I also added option to Run SSIS packages, because when editing the Job, in the Step page, I can change from "Run As SQL Server Agent" to "Run As proxyname".
Do I need to change anything else within the Job properties, such as name of owner?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
DocCan11: In working more with our DBA, we tried another approach. The troublesome task within the package seemed to be the one running an executable bat file. The bat file is on the same machine as SQL Server. When building the SSIS package on MY machine, I included the full UNC pathname to the file, tested it, then deployed it to the Server machine's SSIS Package Store. It ran fine as a package, but not as a Job. Our DBA tried redoing the package, modifying the bat file pathname to just the drive letter and filename, then saving out to the file system of the server machine. It now runs as a job!
I don't understand why the UNC approach would not work, but at least we have the problem fixed.
Thank you for your time and thoughts on a resolution.
I don't understand why the UNC approach would not work, but at least we have the problem fixed.
Thank you for your time and thoughts on a resolution.
ASKER
I'm not sure if your approach would have worked since I needed to go with what our DBA recommended, but thanks very much for your help.
Are they set to the default of something like "NT Network Service".
You could try running thes services as a user with permission to access the file path.