Hi,
Does your ASP.NET application runs under impersonation account. If yes then that account needs to be given permission to run DTEXEC command..
Thanks
Mohit
Hi Jon,
This could be due to the ProtectionLevel setting for the individual packages - that's my guess.
By default, the Package ProtectionLevel property is set to EncryptSensitiveWithUserKey. This means as long as you personally execute the packages, your credentials are picked up and the packages execute in your security context. This is true even if you're connected to a remote machine, so long as you're using the same AD credentials you used when you built the packages.
When the page you created executes, it runs under the ASP.Net Service logon credentials.
There are a couple proper long-term solutions but the one that makes the most sense is to use the EncryptSensitiveWithPassword Package ProtectionLevel option and supply a good strong password. You will need to supply the password when you call the package from ASP as well, and this should allow the package to run without needing your security credentials.
Note: You will also need this password to open the packages in BIDS (or Visual Studio) from now on... there's no free lunch.
Hope this helps,
Andy
First of all I would to the homework and find out what is the actual error you are getting. I don't understand what you mean by "quit execution without any hint of an error nor a failure message".
There are lots of ways to get more information about package execution:
Find out what error you are getting. Trying to fix the problem without knowing what it is can cause lots of wasted time. And the infrastructure you create today will ease support and troubleshooting of the application in the future.
Jon Limjap wrote:
I proceeded with trying out Andy's suggestion, that is, setting the package ProtectionLevel property to EncryptSensitiveWithPassword but to my surprise (and frustration) exactly the same errors occured. This is despite the fact that I both deployed the packages using the password I set, and supplied the password in the Password property of the package object in VB.NET.
Did you supply the password when you load the package in the ASP.NET code
Hi Jon,
Sorry to hear about the continuing issues.
Are you able to run the package by logging into SQL Server Integration Services
Andy
Hi Jon,
I am still curious why you're seeing the Network Service account - I bet you are too. ;) It's as if you're changing users (and security contexts) mid-package-execution and that doesn't seem possible. I don't doubt what you're saying, I'm extremely curious as to how (and why) this is occurring in the first place.
The only way I know to get parameters into a job is to land them (the parameters) inside the database first, then pick them up in the job step via a query - which seems an awful way to call an SSIS package (to me, at least).
Andy
Good work Jon!
:)
Andy