Windows Task Scheduler nightmare!

[Konraden]

Originally Posted by TurcoLoco

And you are sure, UAC is not the cause for all this failures?
Another viable option could be to turn your batch file(s) into an executable in the form of "self extracting" zip file:
7-ZIP SFX Maker « teejee2008's Weblog

Positive. UAC is disabled (by user) on these machines.

I don't know the inner workings of Task Scheduler, but it would refuse to see the YYYYMM program inside of the C:\ directory, even though that is where the batch file was being run from, as well as the YYYYMM executable. Even with the full path name of YYYYMM inserted into the batch script, it still failed to run.

Entering in "C:\" in the Start In (Optional) field made the task run as designed. Definitely not related to UAC as far as I can tell.

[TurcoLoco]

Originally Posted by Konraden

Positive. UAC is disabled (by user) on these machines.

I don't know the inner workings of Task Scheduler, but it would refuse to see the YYYYMM program inside of the C:\ directory, even though that is where the batch file was being run from, as well as the YYYYMM executable. Even with the full path name of YYYYMM inserted into the batch script, it still failed to run.

Entering in "C:\" in the Start In (Optional) field made the task run as designed. Definitely not related to UAC as far as I can tell.

Sorry, I hadn't read your initial posts, so it seems the batch file run OK but the executable that was referenced in the batch script doesn't, right?

Well, as script is running, it creates an environment during the session so the reference points make sense and seem valid to the script. For example, if you mentioned an executable then as Tek mentioned, it checks the environment variables set on that particular machine to see if the referenced program resided in any of those locations or not. It also checks the same directory as the script to see if it is at that location which would still work.

I am not sure if this is a Task Scheduler issue. I never used it in this way but I always put either the full path for location or the applicable system variable as the path and always use quotation mark before and after the path just to be on the safe side. If any of the directory or file names is longer than 8 characters (and long file names are disabled) or if any of the names has a space in it due to multiple words, using quotation at the beginning and end is a must. Also after command parameters, commands and pointers (redirectors) I always enter a single space. So instead of this:

ECHO !!!!!!!!! ERROR WITH %BATNAME% IN %JOBNAME%
ECHO !!!!!!!!! %JOBNAME% ABNORMAL TERMINATION>>C:\BACKUPLOG\STATUSFILE\%JOBNAME%_1.B K
SET EL=100
yyyymm.exe -f?D?r>>C:\BACKUPLOG\STATUSFILE\%JOBNAME%_1.BK
PAUSE
GOTO ENDERR

I would instead use:

ECHO !!!!!!!!! ERROR WITH %BATNAME% IN %JOBNAME%
ECHO !!!!!!!!! %JOBNAME% ABNORMAL TERMINATION >> "C:\BACKUPLOG\STATUSFILE\%JOBNAME%_1.B K"
SET EL=100
C:\yyyymm.exe -f?D?r >> "C:\BACKUPLOG\STATUSFILE\%JOBNAME%_1.BK"
PAUSE
GOTO ENDERR

Also, as a side suggestion, you could try entering the command "start" followed by a single space before the yyymm.exe to see if it helped:

ECHO !!!!!!!!! ERROR WITH %BATNAME% IN %JOBNAME%
ECHO !!!!!!!!! %JOBNAME% ABNORMAL TERMINATION >> "C:\BACKUPLOG\STATUSFILE\%JOBNAME%_1.B K"
SET EL=100
start C:\yyyymm.exe -f?D?r >> "C:\BACKUPLOG\STATUSFILE\%JOBNAME%_1.BK"
PAUSE
GOTO ENDERR

I might try replicating using other scripts I have to see how it went on my system. Not sure if it matters but what flavor of Windows 7 is this machine running? Also is it 64bit or 32bit version?

[Tek_Freek]

^^ Memories!!!

[Konraden]

Originally Posted by TurcoLoco

Sorry, I hadn't read your initial posts, so it seems the batch file run OK but the executable that was referenced in the batch script doesn't, right?

Right, but only when run via the Task Scheduler. If you just run the batch on its own, it works without a problem.

Well, as script is running, it creates an environment during the session so the reference points make sense and seem valid to the script. For example, if you mentioned an executable then as Tek mentioned, it checks the environment variables set on that particular machine to see if the referenced program resided in any of those locations or not. It also checks the same directory as the script to see if it is at that location which would still work.

I am not sure if this is a Task Scheduler issue.

It's the only "variable" that changes. Run the batch, it works fine, schedule the batch, and it fails.

I never used it in this way but I always put either the full path for location or the applicable system variable as the path and always use quotation mark before and after the path just to be on the safe side. If any of the directory or file names is longer than 8 characters (and long file names are disabled) or if any of the names has a space in it due to multiple words, using quotation at the beginning and end is a must. Also after command parameters, commands and pointers (redirectors) I always enter a single space. So instead of this:
I would instead use:

Also, as a side suggestion, you could try entering the command "start" followed by a single space before the yyymm.exe to see if it helped:
I might try replicating using other scripts I have to see how it went on my system. Not sure if it matters but what flavor of Windows 7 is this machine running? Also is it 64bit or 32bit version?

I originally thought there was a problem with the batch file too. I tried START, I tried creating a separate batch to call the executable, and called that batch from the original one, I used full path names for the YYYYMM.exe (which I have if you want to try it out). I used quotes (although, it was only "C:\YYYYMM.exe" and "C:\BackupScript\YYYYMM.exe"). I tried a lot of things.

The only thing that made it work is adding the C:\ path to the "Start In" field of Task Scheduler's "Action" dialogue.

I just have not the slightest clue as to why that works.

Oh, and this is running on two different laptops (both had the same problem), and they're backing up to a network drive, Z:\. I ended up changing this to the network location (\\Server\etc) because it was more reliable. The computers weren't always logging into Z:\, but had no problem finding the network location.

The server is Win7 x64 too, but unrelated. The script balks whenever it tries to execute the YYYYMM.exe part.

[TurcoLoco]

Originally Posted by Konraden

I originally thought there was a problem with the batch file too. I tried START, I tried creating a separate batch to call the executable, and called that batch from the original one, I used full path names for the YYYYMM.exe (which I have if you want to try it out). I used quotes (although, it was only "C:\YYYYMM.exe" and "C:\BackupScript\YYYYMM.exe"). I tried a lot of things.

The only thing that made it work is adding the C:\ path to the "Start In" field of Task Scheduler's "Action" dialogue.

I just have not the slightest clue as to why that works.

Oh, and this is running on two different laptops (both had the same problem), and they're backing up to a network drive, Z:\. I ended up changing this to the network location (\\Server\etc) because it was more reliable. The computers weren't always logging into Z:\, but had no problem finding the network location.

The server is Win7 x64 too, but unrelated. The script balks whenever it tries to execute the YYYYMM.exe part.

It might be a bug with Task Scheduler or a design issue but if it works when you input the C:\ in the "Start In" field then it seems TS is jumping from location the location and since root of C drive is not one of the default locations for the executable files as listed in the "Environment Variables" table, you will have to continue doing that.
You could test this theory of mine by placing the YYYMM.exe file in the Windows or System32 folder then take out the C:\ part from the script and as well as the "Start In" field to see if it worked.

Other than that, it seems you have already tried everything I would have.