I have an 2005 SSIS package that I'm calling in a service created in VS 2005. The package will not run. The purpose of the package is to parse a file and put data into a "Load Table".
The package runs perfectly on its own, but will not run at all when executed programatically - when I'm stepping through the code. The Event Viewer indicates that the package has started but then it indicates that it has failed. I don't get any more information than that.
It's not throwing an exception. It's just returning "Failure". I've tried executing against different databases - Same result. The file it's parsing is valid becuase it runs fine when run on it's own.
The only other thing that I can think of is that I'm having some problem with user permissions, but I have no idea on how to go about looking into that issue. Does anyone have any ideas?
Sounds like a permissions issue. Make sure the process it is running as has the same permissions as the account which you are using to run it interactively.
Without more information it's hard to tell, but this sounds like a permissions issue.
When it's running from code, does the person or user account the code is running under have the appropriate permissions?
For example, if you run it manually, you're most likely using your own credentials. As the developer, I'd assume you have admin rights, so you can perform the task.
However, when run from a program you need to know what user account the program runs under. Is it Asp.Net? The default user is Network Service. Is it a Scheduled Task running under the default Local System account? You'd need to change the account it runs under or grant permissions on the DB appropriately.
When you loaded it from Studio to Integration Services, what Package Protection Level did you use? I've had the best luck with the last in the list: Rely on Server Storage and roles for access control.
Does your package have error logging set up? It could help you to see what the problem is.
Also, does the account for the service running the package have the correct rights to the directory where the file to be picked up is stored not just correct rights in SQL Server? We've had that problem before.
Have you attached Events to the execution of the package? Are you calling the package by code? Which Method are you using?
Please check Loading and Running a Remote Package...
Then when debugging, add a break point at the Console.Write Line where gets info of the error.
Hope it helps,
Arturo
Related
I'm getting "Unable to start program http://localhost:[port] Access is denied." when I try to debug an ASP.NET MVC app. Here are some more details, some of which may not be relevant.
This is happening under a somewhat different context for this project. I recently obtained an elevated account on the network, so now I'm running VS 2017 (15.5.4) as Admin every time I start it so that I can access the TFS server. Previous to this, I had been working offline with my non-elevated account and passing code changes to another developer for him to check in to TFS. I am still logged on to the local PC (Windows 10) with my non-elevated account. I just start VS as an admin and when prompted enter the credentials for the elevated account.
This morning was the first time I ran VS under this new context, got the latest code, and tried to do some work. I had to delete an existing TFS workspace, but I did get a complete refresh of the code from TFS.
The first time I went to F5 the code in this new context I get a warning about the app using SSL and VS wanting to self-sign a certificate. I said yes. I forget exactly what happened at that point, I think the browser (Firefox) timed out trying to connect. Anyway, I tried a different browser (Chrome) and still no luck.
Yet now, whether I , +, , or , I very quickly get the message from above "Unable to start program..." I've done a lot of searching on this problem, but have had no success in getting close to a solution. Here's what I've tried:
Cleaned the build and done a fresh rebuild. Building works, no issues.
Use netsh to look for (and delete) URL reservation. There wasn't one.
Tried using a different port.
Deleted temporary asp.net files.
Turn JavaScript debugging option off in VS.
Crtl+F5, w/o debugger.
Turn SSL off for the project.
Checked, Windows Authentication is on in web.config.
Used Process Monitor to look for any "access denied" for either devenv.exe or iisexpress.exe
So what I'm hoping for here is not so much a silver bullet (though that would be great), but more some help in troubleshooting. Access denied means some resource--a file, a registry setting, a network share, something--is inaccessible in the context in which I'm running. Exactly what that is has got to be recorded somewhere, I hope. What log files does VS write to when you hit ? I've looked at the output during build and there's nothing there.
I'm sure I haven't exhausted all resources in troubleshooting this, I just need some help on where to look. Also, I had to leave that project/site and head to another, so I won't be able to try any ideas you all throw at me until tomorrow, at the earliest.
Please take a look at these answers in a similar question. From the list you provided it appears some of these may be new things to try for your case.
Specifically, I have run across the following answers in that linked question that have worked for me at various times in my career:
If you're using Anonymous Authentication, IIS 7 will use the "IUSR"
account for directory access (unless you've set it to use the app
pool identity. If you haven't granted IUSR sufficient permissions on
your site's folders and files, you'll get this error
For me in windows 7 it started to work only after I gave 'Read &
execute', 'List folder contents', 'Read' permissions to site folder
for both users
IUSR
NETWORK SERVICE
I had the same problem, I enabled "Anonymous Authentication" but it
still did not work. So I also ENABLED "Forms Authentication" Then it
worked without any problems. (also try windows auth)
For me, nothing worked except the following, which solved the
problem: open IIS, select the site, open Authentication (in the IIS
section), right click Anonymous Authentication and select Edit,
select Application Pool Identity.
I gave access to "IIS_IUser" but instead it should be "IUSR". That
solved the problem.
I have a very similar problem with yours and my architecture uses windows authentication and what works for me is selecting my project and going to properties. Then select "Enabled" on Windows Authentication.
I wrote a .NET console application that needs to be scheduled trough Windows scheduler. Such console performs some network and database activities and write a logfile. The application work if run on Desktop/Command prompt but if I try to run it trough the scheduler it refuse to start. Another issue I faced is the write access to the app folder. Even if I set permissions to the folder containing application binaries to be wrote by 'Everyone' the app seems unable to create the log file and/or append data to it. The problem fixes if I run the application with Administrator priviledges (on desktop) but if I define the Activity in the scheduler to Run with higher privildegs this will not fix it anyway.
Best course of action is to create a Service account with admin privileges and schedule the task under such account and select the option to run whether the user is logged on or off.
This approach is even more relevant where Active Directory is in place.
Hope this helps,
Apex
I found the issue... http://support.microsoft.com/kb/2452723
It seems that the "Start In" parameter of the Action should not contain quotes.
Of course the folder should be 'writetable' for the user assigned to the task.
I have an issue regarding wix setup generation, here is my scenario
I have created a setup and tried to install on completion of installation I have done code to create a key in HKCU(H key current user), upto here it is fine.
Now if I try to install with non admin rights then it asked for admin password, then I have entered, installation is completed, problem is the key which I tried to insert in HKCU (Current User) is inserted into the admin account not in the current account where I am installing.
FYI
I am using C# winforms and WIX to generate setup
Any help would be greatly appreciated..
Kind Regards,,
Raghu.M.
You can create an installer that can be executed by non-administrator: https://stackoverflow.com/a/14358274/129269
As mentioned you can no longer install things that require elevated privileges. But on the other hand, when trying to add values to the HKCU my guess is you don't want to install system wide resources.
Update your application to write the default HKCU registry data on first launch. It is much easier than having your setup do the job.
For a description on how you can manage HKCU values after they have been written - in case they need modification, deletion or changing during a reinstall of the application - you can check this thread: http://forum.installsite.net/index.php?showtopic=21552
Thanks for your reply,
This is the way, I approached to solve this.
I have created a component where it inserts key in Local Machine Which will be common for all, and thereby proceed further.
Kind Regards,
Raghu.M
I want to try out to run my C# console application from SQL Job. So to test it, I simply created a console application and using C# and SMO, wrote few lines to create a database. I could run it successfully and it creates a database in the SQL Server as expected.
Then in IDE, I clicked on Build-->Publish myProject to E:\myFolder\MakeNewDB24 because that's where my SQL Server resides on.
The above action copied the following files to the specified location i.e., E:\myFolder\MakeNewDB24
Application Files
setup.exe
myProject.application
Then I opened my SQL Server, created a job by
rt. clicking Jobs Folder-->New Job.
I filled all the information in General.
In Steps, I have under Command,
\\mySQLServer\myFolder\MakeNewDB24\setup.exe
Type: Operating System(CmdExec)
Run as: SQL Server Agent Service Account
I ran the job. It showed the result as "Success"
When I viewed the History,
Executed as user: mySQLServer\SYSTEM. The step did not generate any output. Process Exit Code 0. The step succeeded.
I was happy. But when I went to check the database that was supposed to be created, its not available, meaning the SQL JOb didn't do its job to create my db.
I don't know what am I missing here? If anyone has knowledge on this, please kindly share with me. I really really want to see my SQL Job do this work. The reason I m using SQL job is because all of my automation tasks start from here. Thanks.
Your problem almost certainly has to do with permissions. You need to check the user id used for running the SQL Server Agent job. My guess is that it doesn't have permissions somewhere along the line.
The reason that your job returns success is because CMD jobs always return success if they successfully launch the CMD executable. It has nothing to do with whether or not your code succeeded.
In environments where I don't have to worry about security, I have gotten into the unfortunate habit of giving everything admin privileges, so I don't have to worry about what privileges are needed where. Good luck.
I have written a C# console application that uses the Interop.domino.dll assembly to interact with domino / notes to create, update and delete documents. The application runs successfully when running it manually through a cmd prompt or through Visual Studio. However, when we try to set the application up as a scheduled task (running under a domain service account) it fails with the following error:
System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following
error: 80004005 Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL)).
The error occurs as soon as we try to use an object from the Interop.domino.dll, specifically when try to create an instance of the NotesSession object as per the following:
ISession notesSession = new NotesSession();
After some investigation I found that the interop assembly requires a desktop to interact with and that if we ran the scheduled task with the service account logged into the machine that the scheduled was running on the scheduled task would run successfully. While logged in as the service account you could see that the application would bring up a svchost.exe window while the application was running and that is the reason it requires the desktop.
However, having the service account logged into the machine all the time is not an acceptable solution as it means that the account has to be logged in again each time the server restarts. There are also some security concerns around having about allowing a service account to login to machines.
So, I was wondering if anyone had any suggestions on how to get around this issue? Is there a way to suppress any UI that the assembly tries to show? Alternatively, can anyone suggest an alternate to a scheduled task which would achieve a similar result. What we need to do is:
Have the application run at a set interval (IE - once a day / once an hour)
Ideally, have it run under a domain service account (as opposed to a local system account)
Run without requiring the service account to be logged into the machine / UI elements from the Interop.domino.dll suppressed
We have thought about writing a similar application making use of the notes web services rather than the Interop assmebly and will go down that path if we can't get the console app running as a scheduled task. However, we would like to make use of what I have already written if possible.
Update 01/05/12
I have tried etting the NOTESNTSERVICE OS environment variable as per #dna-man solution. However, this did not solve the issue.
For now we have set the application up as a windows service running under the local system account and with interactivity with the desktop allowed. This is not ideal as it does not allow us to schedule it as easily and it is not running under a domain service account, but the application does work so we will go with this approach for now.
There was an answer that suggested this approach, but it seems to have been removed so I can't mark it as correct. I might leave the question open a bit to see if anyone else has any suggestions.
If your code is running on a Domino server you must make sure the OS environment variable NOTESNTSERVICE=1 is set. You can find out more abou this environment variable in the Lotus C API documentation, but it applies to the COM API as well when running as a service. I had created way back in 2003 a VB.NET application that had to run as a service, and setting this environment variable was the key. If it wasn't set, the service would stop working as soon as I logged off the machine. To make sure somebody didn't forget to set this environment variable when installing the service in the future I simply had my service manager start code set this environment variable directly on startup using the VB.NET call to SetEnvironmentVariable. It had to be set before creation of the Domino session object.
It's hard to say exactly why, but I believe it's failing to read the registry information for the Lotus interop classes. Obviously the entries are there, otherwise it would not work while running manually. So let's consider other possibilities.
I don't even know if this is possible, but os your application running as 32 bit when run manually, but 64 bit when scheduled? IBM doesn't support the Domino COM classes on Win64, and I'm pretty sure that the first symptom of that is that the registry l
A more mundane possibility is that the service account just doesn't have access to read the registry entries for the Notes/Domino install on the machine, possibly because the software was installed under a specific user account.
I ended up modifying the application slightly to set it up as a windows service running under the local system account and with interactivity with the desktop allowed. This is not ideal as it does not allow us to schedule it as easily and it is not running under a domain service account. However, this approach does allow the application to run without requiring an account to always be logged in and does allow for the interop UI elements to be shown (thus avoiding the error).
To schedule the windows service to perform the task at a set interval (which I set at once a day) I used the Timer solution proposed here.