I've tried a variety of things which I found on Google and cannot seem to make a scheduled task run once I deploy the .job file in my package. I made the .job with AT. On my test devices the job runs fine. When I look in the logs on my failed devices I see that there are mentions of file permission errors and access. Here is the log entry:

"Weekly Reporting.job" (reporting.cmd) 8/24/2009 1:30:39 PM ** ERROR **
The attempt to retrieve account information for the specified task failed; therefore, the task did not run. Either an error occurred, or no account information existed for the task.
The specific error is:
0x8004130f: No account information could be found in the Task Scheduler security database for the task indicated.

Since I made this with AT, it is using the System account. I have no more ideas as to why this is failing. I've also tried SCHTASKS and the job wizard in XP SP3 without much luck.

The end result I seek is to have the package call a VBScript each Friday afternoon. The script is also in the MSI and is placed in it's own directory. Any suggestions would be appreciated.

Jimm
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Additional Information:

I removed the inherited permissions on the file leaving only SYSTEM and the Local Administrators group. I then added my user account with full control and the job runs when I manually execute it.

I can now take one of two approachs:

1. Fix this and be done by simply calling CACLS on this file as it is installed. Which UID needs to be added?
2. Try to figure out why the file is not working as is and really correct the issue. I'm also thinking I could have the local admin account run this instead of system.

Ideas? Opinions? Best Practices?

Jimm
Answered 08/28/2009 by: JimmPanik
Orange Belt

Please log in to comment
0
Errrr........Is this really a "Package Development" issue ?
Answered 08/28/2009 by: michaelnowell
Second Degree Blue Belt

Please log in to comment
0
I think it is if thee package can be made to deploy this job correctly.
Answered 08/29/2009 by: JimmPanik
Orange Belt

Please log in to comment
0
Why do it the hard way? Forget packaging .JOB files: that'll never work. Try this: http://www.activexperts.com/activmonitor/windowsmanagement/adminscripts/taskscheduling/
Answered 08/29/2009 by: VBScab
Red Belt

Please log in to comment
0
This method is working exactly as it should. The one little issue is with cleanup. It's much easier to remove a .job file than having to itterate through all the ATx files to determine which job was created and should be removed during an uninstall.

Thanks for the help.
If you're ever in the metro detroit area, I'll buy ya a coffee.
Jimm
Answered 08/31/2009 by: JimmPanik
Orange Belt

Please log in to comment
0
Hmmm...if it was me, I'd record the Job ID that got assigned when you created the task to a registry entry. Then, using the enumeration script on the same page, your uninstall script would read the Job ID, loop through the jobs until it gets to the one with matching Job ID, then delete it.
Answered 09/01/2009 by: VBScab
Red Belt

Please log in to comment
0
That's a good approach but I wound up just enumerating the command line for the one I need and removing the jobid that way.

Thanks for all the help.
Jimm
Answered 09/01/2009 by: JimmPanik
Orange Belt

Please log in to comment
Answer this question or Comment on this question for clarity