Stupid batch files...

[X-13]

Not sure if this should be in Server 2008 R2 or in Scripts... or coding... or "how do?"

 

I've got a quick and dirty batch file to backup our staff drive to a couple of network HDDs... It works if I manually run it, but not if I schedule it.

 

@echo off
echo %DATE% - %TIME% - BEGIN! >> log.txt
net use Y: "\\[server]\[share]" && echo %TIME% - set first drive letter! >> log.txt || echo %TIME% - map first drive failed >> log.txt 
echo %TIME% - copy started! >> log.txt
robocopy "D:\RMDelivery\RMStaff" Y:\ /mir && echo %TIME% - First backup complete! >> log.txt || echo %TIME% - First copy failed! >> log.txt
net use Y: /delete
echo %TIME% - Cleared first drive letter! >> log.txt
net use Z: "[server]\[share]" && echo %TIME% - set second drive letter! >> log.txt || echo map %TIME% - second drive failed >> log.txt 
robocopy "D:\RMDelivery\RMStaff" Z:\ /mir && echo %TIME% - Second backup complete! >> log.txt
echo %TIME% - copy started! >> log.txt
net use Z: /delete
echo %TIME% - Cleared second drive letter! >> log.txt
echo %TIME% - ALL DONE! >> log.txt
exit

 

When I let the schedule run, or I run the task manually, it gets as far as the first line... then nothing.

 

The task says it completed, but continues to run [doesn't kill it either].

 

 

Any ideas what the pauseballs is going on?

 

 

Le EDIT: [command] && [other command] || ['nother command] is a success/fail indicator... I just learned this.

Edited June 11, 2014 by X-13

[sted]

what user is it running as and does that user have access to the nas? best bet is to set task scheduler to run it as the same user you use to manually test it

[X-13]

what user is it running as and does that user have access to the nas? best bet is to set task scheduler to run it as the same user you use to manually test it

 

It's running as SYSTEM because the scheduler doesn't want to save credentials.

Fails on my domain admin account as well... even when I'm logged in.

 

I have access to the drive.

[featured_spectre]

you may well have access to the drive, but what about permissions to the drive to run these sorts of things?

[sted]

is uac turned on on the server? might not have access to the files. If it fails on you domain admin account how does it work when you run it manually?

[strawberry]

might be worth deleting the y drive before you connect to it.

[X-13]

you may well have access to the drive, but what about permissions to the drive to run these sorts of things?

 

It runs the .bat file, gets as far as the first line, then just stops.

 

Running it manually has no problems.

 

If the account didn't have permission to run it, it wouldn't even get to the first line.

 

might be worth deleting the y drive before you connect to it.

 

I have been doing that.

Edited June 11, 2014 by X-13

[X-13]

is uac turned on on the server? might not have access to the files. If it fails on you domain admin account how does it work when you run it manually?

 

It works if I manually run it, but not if I schedule it.

 

^^^^

[sted]

shouldnt

 @echo offecho %DATE% - %TIME% - BEGIN! >> log.txt

be

 @echo off
echo %DATE% - %TIME% - BEGIN! >> log.txt

Edited June 11, 2014 by sted

[X-13]

shouldnt

 @[u][url="http://www.edugeek.net/member.php?u=16971"]echo[/url][/u] offecho %DATE% - %TIME% - BEGIN! >> log.txt

be

 @[u][url="http://www.edugeek.net/member.php?u=16971"]echo[/url][/u] off
echo %DATE% - %TIME% - BEGIN! >> log.txt

 

In the file, it is...

 

Copy/paste broke it.

[jinnantonnixx]

You should specify a full path for the log.txt file.

When it's running as a schedule, unless you specify the 'start in' path, it has no relative location for log.txt. You can understand its confusion - where on earth should log.txt live?

 

Even if you use the 'start in' option, it's always better for specify full paths in all scripts.

 

I'm mostly Linux these days, but if my DOS memory is still working, you might want to try something like this to give you more flexibility if you need to change/rename the log file.

SET LOGFILE=c:\someplace\log.txt

....


echo 'stuff I want' >> $LOGFILE

Edited June 11, 2014 by jinnantonnixx

[X-13]

You should specify a full path for the log.txt file.

When it's running as a schedule, unless you specify the 'start in' path, it has no relative location for log.txt.

 

Even if you use the 'start in' option, it's always better for specify full paths in all scripts.

 

I'm mostly Linux these days, but if my DOS memory is still working, you might want to try something like this to give you more flexibility if you need to change/rename the log file.

SET LOGFILE=c:\someplace\log.txt

....


echo 'stuff I want' >> $LOGFILE

 

Again... That part works.

 

It does the first [stuff] >> log.txt without any issues... then just stops.

 

It doesn't even attempt to map the drive, if it did it would output whether it worked or not.

 

 

It used to work perfectly fine as 2 robocopy commands using IPs... then it just stopped working for some reason.

[jinnantonnixx]

Ah. Are you running it as a particular user with the correct permissions in Task Manager?

 

Get back to basics, change the code to direct errors to a file to see if that helps

net use > wtf.txt
net use Y: "\\[server]\[share]" >> wtf.txt

Edited June 11, 2014 by jinnantonnixx

[AlexB]

Try adding echo %username% >> [logfile] near the top to see what user the script is running as, it may have permission to run, but not permission the connect to the shares.

[X-13]

Ah. Are you running it as a particular user with the correct permissions in Task Manager?

 

Get back to basics, change the code to direct errors to a file to see if that helps

net use > wtf.txt
net use Y: "\\[server]\[share]" >> wtf.txt

 

 

huh... "cannot find the path specified"

[Arthur]

I would use UNC paths in that script rather than mapped drives. Much easier!

[AlexB]

I would use UNC paths in that script rather than mapped drives. Much easier!

 

agreed

[themightymrp]

Try renaming the file to .cmd instead of .bat

 

Then also fill in the "Start in" box to be the path to the folder containing the script. I've had issues like this before and this solved it

[X-13]

Try renaming the file to .cmd instead of .bat

 

Then also fill in the "Start in" box to be the path to the folder containing the script. I've had issues like this before and this solved it

 

I already changred the "Start in".

 

I'll give .cmd a try.

 

I would use UNC paths in that script rather than mapped drives. Much easier!

 

\\ip\share?

 

I already did that...

 

I may start again with a test version that just dumps everything into a log file so I can see what the butts is going on.

 

If the scheduler actually saved credentials, I doubt I'd be having problems...

[AlexB]

If the scheduler actually saved credentials, I doubt I'd be having problems...

 

I may have missed the OS you were using, but Windows Task Scheduler does store credentials....

[X-13]

I may have missed the OS you were using, but Windows Task Scheduler does store credentials....

 

2008 R2.

 

And it just fails to save them if I try... It's a known problem.

 

The annoying thing is that it USED to have the details. It decided not to save any more when I wanted to remove my account from it and use the generic sysadmin one.

[SHimmer45]

I used 2008R2 to backup to a buffalo NAS using XCOPY and a scheduled task, i created a user for the job and added it to the RUN JOB AS in security options and it worked. i didnt realise there was an issue with adding a user to the RUN JOB AS function.

 

if its just sitting there is it waiting for a prompt in the script perhaps

Edited June 11, 2014 by SHimmer45

[sted]

when running it manually might be worth removing the @echo off so youi can see what its doing but by the looks it dosent like your share location either dosent have access or cant find it

[superfletch]

Not sure if some of the echo strings might need to be in quotations?

 

For instance:

 

[color=#333333]net use Y: "\\[server]\[share]" && echo %TIME% - set first drive letter! >> log.txt || echo %TIME% - map first drive failed >> log.txt [/color]

 

Might be:

 

[color=#333333]net use Y: "\\[server]\[share]" && echo "%TIME% - set first drive letter!" >> log.txt || echo "%TIME% - map first drive failed" >> log.txt [/color]

 

 

 

Maybe??

 

Can you test that the system account is normally able to map that drive - ie) open a command window as the system account and test you can map the drive.

 

------

 

Also has a user other than system already got this share mapped as a drive in a different session on this server? (eg you or the administrator account is logged in with a mapped drive using it)?

Edited June 11, 2014 by superfletch

[Arthur]

I already did that...

For both the source and destination locations? i.e.

 

@ECHO OFF
SETLOCAL ENABLEDELAYEDEXPANSION
SET SCRIPTDIR=%~dp0
SET SCRIPTDIR=%SCRIPTDIR:~0,-1%

robocopy "\\Server\RMStaff" "\\Server\Share1" /MIR /V /R:0 /W:0 /NP /LOG+:"%SCRIPTDIR%\RoboCopy.log"
robocopy "\\Server\RMStaff" "\\Server\Share2" /MIR /V /R:0 /W:0 /NP /LOG+:"%SCRIPTDIR%\RoboCopy.log"