Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Scheduled Jobs don't run anymore

First of all, I don't believe this is a Cirrus error. I had a daily job performing the standard configuration backups in my lab. It worked for a week. Then the system engineers came in and did 'something' (not specifically to my server, but to the environment). What...I don't know. The jobs stopped running, but remain listed as 'scheduled'. I can 'test' the job, but cannot run it manually. Manual attempts produce no errors in any logs that I can find, including the Event logs. If I try to change anything about the job and save it, I get this error:

"Automation Error
No mapping between account names and security IDs was done"

Sounds like a rights issue, doesn't it? I've always had admin rights to the server. That hasn't changed. Googling the error message brings up dozens of people getting the same error, but for other applications (Not Solar Winds). Elsewhere on Thwack I found instructions for setting Launch and Local Activation Permissions in Component Services. I took the steps, but nothing changed. The system admins have looked at it, said it was a Windows Error, but have not had time to take a hard look at it.

Does anyone have a suggestion as to what else I can check? I appreciate any and all replies.

Thanks

Find more posts tagged with

Accepted answers

rcahill

Check out:

http://support.microsoft.com/kb/308558

for some reason the .txt file is not always displayable. Alternative-
Path to windows\tasks select Advanced from the menu bar. You'lll notice several options one being View Log.
Another option is "Notify Me of Missed Tasks", could be intereting to note.

Referenced in the above article are the Windows scheduler codes.http://msdn2.microsoft.com/en-us/library/aa364454.aspx is a horrible document.
What you are looking for a successful run is:

"Result: The task completed with an exit code of (0)."

All comments

ShamChauthani

Based on the error message there are two possibilities that come to mind.

1. The credentials that the jobs are configured to run under are no longer valid. You should verify the windows account specified under the security tab is valid.

2. The scheduled job was created under a user that is no longer valid (deleted/diabled) etc. You should be able to verify if this is the issue by going into Windows Scheduled Tasks and opening one of the Cirrus tasks to edit. You may see all options grayed out. In this scenario you will need to take ownership of the task (Properties>Security>Advanced>Owner).

Based on your description issue 2 is more likely then 1. Let us know if either of the two options pan out.

tglass

I did get this to work but it is still somewhat of a mystery. I, like you, believe it to have something to do with the credentials. The creditials used to run the job are the same credentials that I use to log into the server - I run the job as me.

I took your advice and created an ID that is a local administrator. Then I replaced that ID in the security tab of the scheduled job. When I ran the job I received the same error.

So, I created the job from scratch (not editing an existing job). Used the newly created ID, and it worked. I don't believe for a second it acts this way because of Cirrus. It has to be something else with the server.

Thanks for the tip.

bleearg13

I would almost give my left eye to have Solarwinds create their own scheduling mechanism than rely on Windows Scheduled Tasks. Windows Scheduled Tasks is one of the most convoluted, complicated, worthless pieces of garbage on the Windows operating system. In fact, I would much rather have that stupid paper clip pop up every time I clicked a button than to have to mess with Task Scheduler. One tiny change to some permission that has nothing to do with anything else and you could screw up everything. Every time a server is upgraded and I have to move jobs over (whether they are Cirrus or some other type of script), it takes hours and sometimes days to figure out why scheduled tasks are no longer running - and TechNet is really no help at all.

One thing I have found, and it's not always helpful, is that there is a log for the scheduled tasks. When you go into the scheduled tasks control panel, click on Advanced, then View Log. This log can typically tell you if there was some problem with permissions, but not always. The error codes in the log file are undocumented, as far as I can tell. If someone has any info on them, please post.

DGoodale

Hmmm.....not sure what your issue is but I just installed Cirrus last week. The config backups ran for 3 days then stopped. No errors in the log and launching it by clicking on the start button didn't do anything either. I deleted the job and created a new one. We'll see tomorrow if it worked. I only chimed in because I know there were no changes made on my server between my installation and the problem occuring 3 days later.

chris.lapoint

For those that are experiencing these types of issues, I urge you to submit a ticket with support. The Cirrus team absolutely wants to get to the bottom of this strange job scheduling phenomena with config backups, but we really need your help in troubleshooting as we're not able to reproduce in house.

Once we have some cases assigned to the issue, we'd like to work with you directly on diagnosing. I expect that many of these are related to environmental issues so we can work with you to at least build in some better diagnostics and notification for helping with when/how/why jobs fail.

tglass

We are beginning a production install today. In this case, we are installing Orion and Cirrus on the same server. I'll document everything I can and pass the results on to you guys. In this regard, can you suggest specific areas of information that you want us to include?

Thanks.

BryanBecker

Somewhat related....I request a feature to define a seperate job account instead of relying on people to remember to go into Cirrus and change the password when your domain password was chnaged.

ShamChauthani

For this pirticular issue, it would be great to capture the following

1. Account used to install the product and it's group membership (admin? power user? etc). This account in turn is used to create the scheduled jobs.

2. Account specified in the installer to run the scheduled tasks under and it's group membership.

3. There is a scheduled task log file that should have some details about the job processing. The log file can be found in %systemroot%\schedlgu.txt

4. Event logs may contain information about failed authentication or other application errors so those would also help.

In addition there is an article on technet that talks about troubleshooting steps for scheduled tasks, so if you are running into issues with the jobs these are some steps to verify
http://technet2.microsoft.com/windowsserver/en/library/1f751799-84a2-414c-8cf7-8289eb5b5d461033.mspx

There is also a script out there that sends out notifications when a scheduled task fails. This could also help to identify issues with job execution.
http://www.jsifaq.com/SF/Tips/Tip.aspx?id=4663

tgoyette

I found this to be correct in my situation. The password for the ID was using had been changed but not reflected in the job(s). Once I updated the password in the jobs they ran fine

DirtySouth

I was having a similar issue with my weekly config backup not working. The event log indicated that that logon type 4 was failing. We have an NT account that is used to run the jobs. Our GPO was not allowing logons as a batch job. We just had to add the NT account to the approved logons for batch jobs and it seems to be working fine now.

Junyoure

"%systemroot%\schedlgu.txt"

is this a typo? I cannot find a log by this name on the server in question.