In my windows task scheduler, I have scheduled a task to run a c# console application executable on a daily basis. This application sends some data to the database and then sends an email.
When I run it normally it works but however when it is run through task scheduler, it sends data to the database but is unable to send the email.
Any ideas on how to fix this?
EDIT:
Yes I can send correctly through console application. It uses default network credentials..However when I look at the event logs I have the following .NET Runtime exception logged:
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.IOException
Stack:
at iTextSharp.text.pdf.PdfPages.WritePageTree()
at iTextSharp.text.pdf.PdfWriter.Close()
at iTextSharp.text.pdf.PdfDocument.Close()
at iTextSharp.text.Document.Close()
at ReadReutersRates.Program.SavePDF(System.DateTime)
at ReadReutersRates.Program.Main(System.String[])
I think it has something to do with pdf file which I am attaching to the email. But it's quite strange that this works when I manually run it.
This is a permissions error, the user you're running the task as when running through the console will have more permissions than the user running the task.
It appears the PDF app you are using is trying to write to a temp file or similar and it doesn't have permissions. (I'm assuming the email has a PDF attachment or similar that is being generated on the fly)
If you made your task run as an administrator that should work, you could then run it as a more restricted user and work out which permissions to apply to where to lock it down.
Related
Trying to execute a task scheduler from Windows. Have given a http path of the required file
to be executed. The history seems to be showing as its triggered, but the hit is not received at
the other end as have written a log to identify the hit. No log is created which means the expected code is not executed.
Is it possible to give a http url for windows task scheduler? The destination file is written in coldfusion language.
I have a Nancyfx console application, which I'm trying to deploy to an AWS EC2 Windows instance using AWS CodeDeploy. All steps show a successful run in CodeDeploy's Deployment dashboard, though the application is not actually starting correctly.
The problem is isolated to the ApplicationStart hook, which is a one line batch file that runs the application's exe. If I RDP into the instance and run the batch file manually, it operates as expected.
Expected Result:
- The application's console window opens
- Debug printouts indicate pulling some initial data from DynamoDB was successful
- Debug printout indicates the application is running.
- Console window is held open by waiting for any input (Nancyfx's default setup)
Actual Result:
- No console window opens, but CodeDeploy's logs show the stdout for the following
- Debug printouts indicate pulling the initial data failed
- Debug printout indicates the application is running
- Application is not running
I guess the problem lies with how CodeDeploy is executing the batchfile, but I couldn't find answers for such a specific and hard-to-Google problem. Please help!
Solved - I discovered that DynamoDB calls within the application were causing it to exit prematurely, which was resolved by giving the IAM role DynamoDB access.
I have scheduled windows task scheduler to upload different text files to oracle database. Till date its working fine. But i have an issue that if any uploading was disrupted because of following reasons.
1) Database Machine Shutdown
2) Internet Connectivity Issues
3) Miscellaneous
How i will get this information about failure of task scheduled?
Windows itself (in the event log; a filtered view for each scheduled task is available in the Task Scheduler application) will record if the task failed.
For anything more you'll need to add diagnostic logging to your task's implementation.
We have a legacy VB6 application that automatically emails reports. It runs from a scheduled task on a server. Occasionally a user will run the exe - it's in a folder that we can't lock them out of, and it has to remain in that folder for reasons too complicated to go into here. Is there a way to prevent users from running the exe while still letting it run from the scheduled task? I can modify the source code for the exe, so that's an option if someone can help me figure out how.
I'm going to call your existing app AppChild and a new VB6 (or other program language) program AppParent.
Modify AppChild to test for a command line parameter at either Sub Main() or at the first form loaded in the Form_Load() event. If the command line parameter isn't there, AppChild terminates.
AppParent would be in a location not accessible to the other users. The Scheduled task runs AppParent which runs AppChild and passes the required command line parameter. This could be secured somewhat by passing a calculated hash and decoding it in AppChild if needed.
Or, if the users don't have access to the Scheduled Tasks, you could just run AppChild , passing the required parameter from the Scheduled Task. If the users do have access to the Scheduled Task this won't work because they could then see the passed parameter and create a shortcut which passes the required parameter.
You didn't state which OS the server is running but you may have problems using network resources if you try to run the Scheduled Task without a logged in user. Task Manager got a major update to handle security issues to prevent hackers from running tasks without a logged in user. Essentailly, network resources, .e.g. eMail, are not available unless a user is logged in.
https://technet.microsoft.com/en-us/library/cc722152(v=ws.11).aspx
The only way I found around that problem is to run a machine with a user with the correct permissions logged in all the time.
Are you sure you cannot lock the user out?
You could restrict access to the folder so that the user cannot access it and set up the scheduled task to use an account with access to the folder.
Although the users can't be locked out of the folder (perhaps the reports end up in there?), in Windows you can set the permissions on a per file basis. Make a new user that has the full rights (the same as your users). Schedule the VB6 app to run with that user. Remove the rights for the regular users to see the app. You do this by changing the permissions on just the VB6 app.
We are accessing outlook through redemption DLL in c#.net. We are using various services like: importing contacts, calendar integration etc. Sometime we are getting exception from redemption COM like:
The file abc.ost is in use and cannot be accessed.
'MyApplication' exited without properly closing your Outlook data file
Could somebody help us to identify the root cause of this issue?
Exception details are mentioned below:
Exception1:
OutlookServices.OutlookService -
System.Runtime.InteropServices.COMException (0x80040119): Error in
IMAPISession.OpenEntry: MAPI_E_EXTENDED_ERROR
Error: 'MyApplication' exited without properly closing your Outlook
data file
'C:\Users\abc\AppData\Local\Microsoft\Outlook\abc#org.com.ost'.
'MyApplication' must be restarted. If this error message recurs,
contact support for 'MyApplication' for assistance.
at Interop.Redemption.IRDOSession.GetMessageFromID(String
EntryIDMessage, Object EntryIDStore, Object Flags)
Exception2:
OutlookService - System.Runtime.InteropServices.COMException
(0x8004011D): Error in IMAPISession::OpenMsgStore:
MAPI_E_FAILONEPROVIDER
Error: The file
C:\Users\abc\AppData\Local\Microsoft\Outlook\abc#sigmacare.com -
abc.ost is in use and cannot be accessed. Close any application that
is using this file, and then try again. You might need to restart your
computer.
at Interop.Redemption.IRDOSession.GetDefaultFolder(rdoDefaultFolders
FolderType)
Are you sure your application was terminated gracefully? Do you release Redemption objects as soon as you are done with them?
Are both your app and Outlook running in the same security context? Is either app running with elevated privileges (Run As Administrator)? Normally, OST files can be shared between different processes (e.g. outlook and your process) as long as the security contexts are the same.