I have some Task Scheduler tasks set up on a windows server. The task appear to run every night. They were all giving me a status code of "0x2" under the last run result with no other information.
All 6 of the tasks call a batch file that uses robocopy to copy some files from one office to another office as a quick offsite backup. Someday we plan to replace our current backup to the remote site with an online backup.
It seems that even though the task were running, they were not actually copying files. I adjusted the batch files and they all ran last night except 1. It gave the status code above. I can not find that status code online. It seems that other folks are looking for its meaning too. Does anyone here know what the status "0x2" means?
You can see the status for the tasks in the image.
There are no other tasks scheduled to start at 11PM like the task with code 2. The other tasks appear to have started and stopped while this other task was running. There could be some overlap due to the length of time a scheduled task runs.
This server is not heavily used. It is DNS, DHCP, and AD Directory (for backup/secondary). That is why I placed these task on this server. It is not highly utilized at night.
I verified the scheduled task has the correct batch file name list with the correct absolute path.
If I run the batch file manually I can verify it works.
I deleted the task and recreated the task. I will check the task tomorrow and see if it ran successfully. When the task returns the result code of 2, it look like everything ran but no data is actually changed.
If it works when run manually, some sort of permissions issue is indicated. Scheduled tasks may have differing permissions than tasks run from the console (as in a test). Make sure the scheduled task specifies the user with the proper credentials.
I forgot to enable the task when I recreated it. The task did not run last night. The other 5 scheduled tasks all ran with a status of Completed Successfully 0x0.
When I recreated the task I did re-enter the account the task runs under. If the account credentials were messed up, that should no longer be an issue. All six tasks use the same account. The account the task use is a regular user account except the password does not expire and the account has read/write access to the data shares. We manually change the password on special account every so often but don't want the password to expire and break some automated task.