task scheduler returns (0x1) code when 'Run whehter user is logged on or not' options selected
I have setup a task using Task Scheduler that I would like to use to launch a batch file at a certain time each day. The batch file works correctly when launched manually and the task also works correctly when the option 'Run only when user is logged
on'. However, as soon as I mark 'Run whether user is logged on or not' using the Administrator login, the task returns a Last Run Result of (0x1). This happens when trying to launch the file on demand or when it is scheduled at it's daily time
to run.
From some research I have done, I don't believe I should see the actions of the batch file and the program that it launches when this option is marked, but I know it is not running correctly in the background due to the fact the log files are not generated
from the task it is to complete. I have marked 'Run with highest privileges' and also entered information in the Start in field under Edit Action with no quotes. The history logs show that the task successfully finished, despite the lack of the
Last Run Result code and no log files being generated. I have also verified the user being added to the Log on as a batch job option and that there are full permissions to the files (all on the local machine).
Does anyone have any insight to what I could be missing? If helpful, i could post the history logs as well.
Thanks!
November 22nd, 2011 1:17am
Does the account you're running the task under have the "logon as batch" user right?
November 22nd, 2011 2:18am
Thanks for the reply - yes, we have set this user up with this user right, but unfortunately to no avail. I'm starting to think that it may be related to the program that is trying to launch and the process it is trying to run instead of the Task Scheduler
after testing some more, so I'm planning to do some more research on that.
Thanks for your response however!
November 22nd, 2011 8:00pm
I had a similar issue today when I enabled "Run whether user is logged in or not" on a task that runs overnight. The task was configured to run a batch file with a simple copy command in it. After I enabled "Run with highest privileges", the task ran successfully.
Also remember that the user account you are using for the task has the privileges necessary for the programs in the batch file to complete successfully; i.e. if a command to copy something to a server is ran with a user account that exists on the local machine,
but not on the server you are copying to, the task will fail silently and may or may not report a result. The same will happen if the username on the local machine and the server is the same, but the password is not.
-
Proposed as answer by
Jeremy - Plus I.T. _
Friday, January 06, 2012 7:03 PM
January 6th, 2012 7:03pm
I had a similar issue today when I enabled "Run whether user is logged in or not" on a task that runs overnight. The task was configured to run a batch file with a simple copy command in it. After I enabled "Run with highest privileges", the task ran successfully.
Also remember that the user account you are using for the task has the privileges necessary for the programs in the batch file to complete successfully; i.e. if a command to copy something to a server is ran with a user account that exists on the local machine,
but not on the server you are copying to, the task will fail silently and may or may not report a result. The same will happen if the username on the local machine and the server is the same, but the password is not.
- Proposed as answer by
Jeremy - Plus I.T. _
Friday, January 06, 2012 7:03 PM
January 6th, 2012 10:03pm
Is Microsoft ever going to a) publish a fix for this; or b) give a comprehensive solution for it? They seem to ignore it. I have done everything in every forum thread I've found to fix this and nothing works. It's a simple batch job that works with my personal
account but no other. It accesses local files and a WinSCP upload. The user is in local administrators. It has batch logon privileges.
I've tried running the WinSCP directly with the same results. 0x1.
Could MS at least explain what return code 1 is? Is that the really useful "unexpected error?" If it's a permissions issue, shouldn't it state that instead of claiming to have finished? Now I have to update this job every time I change my password and I
have no idea what will happen if I should leave the firm.
This is very poor design and even worse documentation. Support by forum should be illegal.
July 11th, 2012 8:36pm
Check your relative paths in the batchfile. If you are using drive letters that points to a network drive. (drive that the is assigned to the user when logged on) then you wont be able to run the task with "Run whether user is logged in or not".
To use "Run whether user is logged in or not" you need to use UNC paths or point to the physical disk (if local drive).
Depending on the program executed in the batch file, it is however not always possible to use UNC paths.
Agrree that MS has total F..... up the task scheduler. The log feature is just not usable with error codes like 0x1 or 0xFF. There are better 3. part alternatives....
August 22nd, 2012 3:25pm
I have found that entering the directory path to the "Start in (optional):" block for where the script originates works for me. If you put in the quotations around the directory, even though there is a space, within the Start in box I find
it doesn't work, so you see I didn't put them in. Check out the screenie ..
-
Proposed as answer by
Skrigz
Monday, October 08, 2012 8:02 PM
September 12th, 2012 11:29pm
I have found that entering the directory path to the "Start in (optional):" block for where the script originates works for me. If you put in the quotations around the directory, even though there is a space, within the Start in box I find
it doesn't work, so you see I didn't put them in. Check out the screenie ..
- Proposed as answer by
Skrigz
Monday, October 08, 2012 8:02 PM
September 13th, 2012 2:29am
I have found that entering the directory path to the "Start in (optional):" block for where the script originates works for me. If you put in the quotations around the directory, even though there is a space, within the Start in box I find
it doesn't work, so you see I didn't put them in. Check out the screenie ..
Thanks worked for me!
-
Proposed as answer by
FrankM68
Wednesday, July 31, 2013 9:03 PM
October 8th, 2012 8:02pm
I have found that entering the directory path to the "Start in (optional):" block for where the script originates works for me. If you put in the quotations around the directory, even though there is a space, within the Start in box I find
it doesn't work, so you see I didn't put them in. Check out the screenie ..
Thanks worked for me!
- Proposed as answer by
FrankM68
Wednesday, July 31, 2013 9:03 PM
October 8th, 2012 11:02pm
Thank you - this worked for me too! :D
October 22nd, 2012 6:38pm
But did not worked for me...
November 1st, 2012 10:31am
thanks - adding the directories as shown, run with priv's, changed to only run when user is logged on all worked for me.
December 15th, 2012 12:28am
That worked for me too
Thanks
March 20th, 2013 11:43am
Another thing often forgotten, is to grant explicit directory rights for the execution account. Typically this becomes a problem, if the batch job needs to create a log file or in any other way modify contents of the target folder.
March 20th, 2013 1:25pm
Thanks for tip, I got it to work finally!
My variation - just put the file name under 'Program/Script', no quotes and the directory under 'Start in' as described, again no quotes.
August 1st, 2013 12:03am
I have found that entering the directory path to the "Start in (optional):" block for where the script originates works for me. If you put in the quotations around the directory, even though there is a space, within the Start in box I find
it doesn't work, so you see I didn't put them in. Check out the screenie ..
Thanks worked for me!
This one also has worked for me. Putting the directory name (without quotes) in the 'Start in' fixed the error.
August 7th, 2013 7:32pm
Thanks,
This solved my problem.
Problem.
OS: win 7 starter.
One Batch file with a copy command. This file didnt work with scheduler
but it works manually.
One Batch file with a ftp command. This file works fine with the scheduler and manually.
Solution.
In the scheduler of the copy bath file: filed in the directory in the start in field.
August 18th, 2013 11:53am
I had this same exact issue.
I later found out that the script I was using to create the scheduled task didn't copy the file that the scheduled task referenced. I felt rather silly.
September 19th, 2013 8:39pm
I had this issue too but the above techniques didn't work for me. I then worked out that the file name of the script was too long, so once I shortened it - it worked :)
Hope this helps!
Cheers
Steve
October 30th, 2013 5:46am
Thank you, Worked like a bomb!
December 9th, 2013 10:32am
Life saver! Add the directory in "Start in (optional)" fixed my problem!
January 10th, 2014 2:30pm
In my case, I configured a web server to email me an alert via Task Scheduler when a tester attempted to log in. I was seeing (0x1) appear in the Task Scheduler results pane.
On investigation, Exchange 2010 was treating email from this server as spam.
In the Exchange 2010 Management Console -> Organisation Configuration -> Hub Transport -> Anti-spam -> Content Filtering -> Custom Words -> Allow messages containing these words or phrases:
...I added the title of the email being blocked as a phrase.
Click "OK"
Retest from source server. ...all then worked for me.
- Edited by
lwoody7110
2 hours 27 minutes ago
January 18th, 2014 3:58am
In my case, I configured a web server to email me an alert via Task Scheduler when a tester attempted to log in. I was seeing (0x1) appear in the Task Scheduler results pane.
On investigation, Exchange 2010 was treating email from this server as spam.
In the Exchange 2010 Management Console -> Organisation Configuration -> Hub Transport -> Anti-spam -> Content Filtering -> Custom Words -> Allow messages containing these words or phrases:
...I added the title of the email being blocked as a phrase.
Click "OK"
Retest from source server. ...all then worked for me.
-
Edited by
lwoody7110
Saturday, January 18, 2014 8:58 AM
January 18th, 2014 8:54am
GMSteel... Did you ever get a resolution to this? I have tried (I think) every supposed answer/solution in this forum and still my task fails with the same (0x1) result.
March 6th, 2014 9:02pm
I have the same issue where I have a Task which runs the Powershell script to Compress a whole bunch of bak & trn files from a local drive to create a RAR file using the locally installed WinRAR application. This process with RAR commandline also ensures
deletion of all the files added to the archive.
Another task scheduled at a later stage picks the created .RAR file and transfers(MOVE - CUT PASTE) across to another server with UNC path reference.
When I run the script manually as Admin with Powershell, it works fine in both cases, but when attached to the Task Scheduler task, it comes up with the 0x1 error.
All these options:
- Run whether user is logged on or not
- Run with highest privileges
- Actions -> Edit -> Program/Script : I invoke Powershell and pass the ps1 file as the argument
- Start in : C:\Windows\System32\WindowsPowerShell\v1.0\
- task which is for the copying of the file on to the remote folder is run as this user which has Local Admin rights on both the machine it is running on and the remote server as well.
Any help would be deeply appreciated.
March 9th, 2014 8:30pm
...even added .\<scriptfilename>.ps1 in the additional arguments, and tried to run and the result is still the same 0x1 error!
March 9th, 2014 9:41pm
Very useful thread, solved my issues, thanks all.
April 9th, 2014 10:27am
Verify that you are allowed to run PowerShell scripts - Get-ExecutionPolicy, default is Restricted which doesn't allow custom scripts to run
April 22nd, 2014 5:38pm
of all things - When I went back and put a few REM statements in the .bat script for documentation, now the task reports "completed successfully" instead of (0x1) - guess this is just Microsofts hint to document well - go figure -
May 26th, 2014 4:18pm
It worked for me, Gracias!
May 28th, 2014 4:06pm
Just FYI, cant explain it. Don't know why, but I re-wrote my scripts that were failing, from scratch... The problem went away.
Initially the batch files would run manually no problem but would consistently fail through the task scheduler. Out of frustration, I deleted them and re-wrote... suddenly no problem! Go Figure...
I deleted the old ones so I can not go back and compare. Obviously something was wrong but I could never find it.
May 28th, 2014 4:57pm
Hii,
Thanks it's work for me
June 30th, 2014 10:16am
Hi,
I m facing the same problem in Windows 8.1 task schedular i have tried all the proposed solution mention above but nothing is working for my case.
In my case i m invoking the task from System account where the folder where the batch script resides has full control of System account.
The same scenarion i have checked in Windows 7 but it was working fine in that.
Please advice how to proceed for Windows 8.1.
-Lisham
July 8th, 2014 1:23pm
In the task scheduler, edit the properties of the action and check you have the correct "start in" folder as that is likely to be an issue, even if the folder is specified in the Program/script field
August 29th, 2014 5:28am
I used the UNC path in my script to where I was moving the file, and everything is now fixed. I had mapped the path to my Y: drive but that was not working. When I did \\machinename\sharepath\ in my script to move the file, it now moves it
correctly.
December 5th, 2014 8:59pm
On the General tab, Check the last drop down and make sure it is pointing to correct OS. In my case , it was default set to Windows Vista ,Windows 2008 and my server was windows 2008R2. Once i changed it to Windows 2008R2 , it just worked fine with whether
or not user logged in option. Hope that helps!
-
Proposed as answer by
Poonam K Gill
Thursday, December 11, 2014 6:44 PM
December 11th, 2014 6:43pm
There are three important options to make sure your task will run: 1 - Create your task using the "Create Task" option instead of the "Create Basic Task" (this gives you more options for the server type, usually the default server
will work - Windows Server 2003, Windows XP, or Windows 2000). 2 - Use only UNC paths in your batch files and in the "Actions" Tab. You can map drives on your computer, but you must use the UNC paths throughout your task. 3 - On
the "General" Tab, select the "Change User or Group" and add the correct credentials even if you are already signed into the account with the correct credentials. These options should work if you select to run the task when the
user is logged on or not. Place a pause at the end of your batch file so you can see any errors and test run the job.
NOTE: if you are trying to connect to an AS400 network folder, open an AS400 session. You do not have to sign in, just start the session.
January 12th, 2015 3:56pm
I tried everything that everyone suggested, but the only thing that I got to work was to put a command in the batch file to output a directory listing.
DIR C:\ > DIRECT.TXT
This makes absolutely no sense at all; however, it was the only way that I could get the batch file to run without any problems.
BTW, my batch file was running an FTP script to download files from IBM AS/400.
February 19th, 2015 3:38pm
This was the one that worked for me (thanks You Rocke!)
My bat file would run fine when executed manually, just the task wouldn't run it!
Creating a 'New Task' rather than a 'Basic Task' gives you a Windows 7 option in the server type (which is what I needed in my case)
I also put the path (without quotes) into the 'Start In' box and ticked the 'Run with Highest Privileges' box.
Thanks all
Mark...
March 10th, 2015 9:46am
Glad I could help out, Mark.
March 11th, 2015 1:17pm
This was the fix for me: Add start in directory and put only the batch file name. Thanks!
May 12th, 2015 3:55pm
I must say it was rather nice to figure out that (0x1) could mean that the batch file couldn't be found. The batch file I was trying to run had an amperstand (&) in the file name which evidently caused Task Scheduler problems when trying to run it. Meanwhile,
I was able to run the batch file outside of TS without any problems.
Tip: If TS isn't running the batch file as schedule, try running it via the 'Run' command within TS, either via the right click menu or the option on the right hand side panel.
May 26th, 2015 3:32pm
Running WinSCP exe file script and keep getting 0X1 return code. Finally SHORTENED the name of the exe file and it worked without the return code. (Upload_HR_File_To_Offsite.exe -> HR_To_Offsite.exe) Worked.
May 27th, 2015 1:18pm
Thanks, this did worked for me...
June 10th, 2015 3:50pm
Hi,
Try Changing Server in Configure Box on General Tab of Task. I changed it from Windows vista to windows xp which worked for me :)
July 1st, 2015 7:03pm
I had this issue. How I resolved it was to explicitly state all paths used in the .bat file.
e.g. the code in runTest.bat
call test.bat > test.log
became
call "C:\test.bat" > "C:\test.log"
This worked like a charm.
July 29th, 2015 10:09am
Thank you man! you saved my life
September 4th, 2015 7:53pm