Scheduled Task - Move Command

[Andy]

I have a batch file on a server that runs a backup then
moves the backup files to a workstation. I have this
triggered by a scheduled task that runs nightly.

The backup portion runs fine but the move command fails.
I've tried using the move two ways:
1. Map a drive to the share on the workstation then move
the files.
2. Use the UNC reference to the share on the network
station in the move command.

Both fail. The odd thing is that if I run the 'move'
portion as a separate task it works fine.

Any help would be appreciated.

 

[Greg Stigers]

This first idea is a long shot, but is there anything in the SchedLgU.Txt
file? Does the backup operation backup the batch file? Could it be breaking
Scheduled Task's lock on the file?

For troubleshooting within Scheduled Tasks, you can redirect the output of
batch file into another file, and see what information, if any, that
captures. I have seen cases, with large files, were the disk buffers have
not flushed yet, leaving the file locked and unable to be copied / moved.
You could try adding a brief pause, if you have an appropriate tool for
pausing, like sleep.exe or choice.exe, or you can easily roll your own pause
routine. Or, if you have the NT Resource Kit, you could try using Robocopy,
which will retry the copy operation.

 

[Pegasus \(MVP\)]

I have a batch file on a server that runs a backup then
moves the backup files to a workstation. I have this
triggered by a scheduled task that runs nightly.

The backup portion runs fine but the move command fails.
I've tried using the move two ways:
1. Map a drive to the share on the workstation then move
the files.
2. Use the UNC reference to the share on the network
station in the move command.

Both fail. The odd thing is that if I run the 'move'
portion as a separate task it works fine.

Any help would be appreciated.

You must run the scheduled task under an account
that has sufficient privileges to perform the "move"
command. This has nothing to do with UNC paths,
and everything with NTFS permissions.

 

[Andy]

Thanks for the reply.

1. Rights is definitely not the issue here. As I said, I
tried the 'move' portion in a separate batch file and
scheduled task (same credentials of course) and it works.

2. I must beg to differ on the use of mapped drives vs.
UNC notation. I've found two contradictory messages
elsewhere that state that one works and the other doesn't.

 

[Andy]

Thanks for the reply.

I am currently appending all output of all commands to a
text file and I'm coming up with nothing. The schedule
logs are also less than helpful.

Also, just for fun I have tried putting in a 30
second 'sleep' between the end of the backup commands and
the start of the 'move' command. No joy unfortunately.

As a matter of fact, Robocopy was going to my next attempt

I had this working on these servers when they were domain
controllers but our plans have changed and these boxes are
now just member servers. Strange.....

Thanks for the suggestions.

 

[Pegasus \(MVP\)]

You said in a different branch of this thread that
you're already capturing all outputs to a file. Show
us your batch file so that we can see what you're
doing.

 

[Andy]

Here's one version:

rem let the system settle after doing backups especially
after full backups before moving files to WKS1
sleep 30

rem This section moves backup files of XYZ1 to WKS1
rem Time stamp to mark start of move operation
Echo Start time >> c:\log\XYZ1_System_Backup.log
date /t >> c:\log\XYZ1_System_Backup.log
time /t >> c:\log\XYZ1_System_Backup.log

rem map temporary drive to WKS1 backup repository, system
variable WKS1 is referenced here
Net use w: \\%WKS1%\backup

rem move D:\OWFG\Systembackup\work\*.bkf w: >>
c:\log\XYZ1_System_Backup.log
robocopy d:\owfg\systembackup\work w: /mov
c:\log\XYZ1_System_Backup.log
rem capture errorlevel from move command above to a
variable
set MOVEOK=%errorlevel%


rem Time stamp again to mark the end of the move operation
Echo End Time >> c:\pcmaster\log\MFS1_System_Backup.log
date /t >> c:\log\XYZ1_System_Backup.log
time /t >> c:\log\XYZ1_System_Backup.log

rem delete temporary map drive
net use w: /delete /y

rem exit batch file with results of move command
exit %MOVEOK%

 

[Pegasus \(MVP\)]

Try this version for improved tracking, then examine
not only the standard log but also the error log.

Also: It is not a good idea to map shares to drive letters
inside a background process. There is a good chance that
this drive will persist, causing all sorts of trouble until the
machine is rebooted. Use UNC coding instead, regardless
of the myths you may have heard elsewhere!

rem This section moves backup files of XYZ1 to WKS1
rem Time stamp to mark start of move operation
Echo Start date and time=%date% %time% >> c:\log\XYZ1_System_Backup.log

rem map temporary drive to WKS1 backup repository, system variable WKS1 is
referenced here
Net use w: \\%WKS1%\backup 1>> c:\log\XYZ1_System_Backup.log 2>>
c:\log\XYZ1_System_Backup.err

rem move D:\OWFG\Systembackup\work\*.bkf w: >> c:\log\XYZ1_System_Backup.log
robocopy d:\owfg\systembackup\work w: /mov c:\log\XYZ1_System_Backup.log 1>>
c:\log\XYZ1_System_Backup.log 2>> c:\log\XYZ1_System_Backup.err
rem capture errorlevel from move command above to a variable
set MOVEOK=%errorlevel%

rem Time stamp again to mark the end of the move operation
Echo End Date and Time=%date% %time%, ErrorLevel=%MoveOK% >>
c:\pcmaster\log\MFS1_System_Backup.log

rem delete temporary map drive
net use w: /delete /y

rem exit batch file with results of move command
exit %MOVEOK%

 

[Andy]

Pegasus,

Thanks for the input, I'll give it a try.

I have to disagree about UNC coding being a myth though.
I've experienced it myself. When these same test servers
were set up as domain controllers I found they failed
constantly until I switched from UNC reference to a mapped
drive, after that it worked every time though I'd often
experience 'semaphore timeout' errors with either method.

We've changed our configuration recently such that these
servers will just be members and neither method works at
this point.

PS. Robocopy also failed with both mapped drive and UNC
methods.

-----Original Message-----
Try this version for improved tracking, then examine
not only the standard log but also the error log.

Also: It is not a good idea to map shares to drive letters
inside a background process. There is a good chance that
this drive will persist, causing all sorts of trouble until the
machine is rebooted. Use UNC coding instead, regardless
of the myths you may have heard elsewhere!

rem This section moves backup files of XYZ1 to WKS1
rem Time stamp to mark start of move operation
Echo Start date and time=%date% %time% >> c:\log\XYZ1_System_Backup.log

rem map temporary drive to WKS1 backup repository, system variable WKS1 is
referenced here
Net use w: \\%WKS1%\backup 1>>

c:\log\XYZ1_System_Backup.log 2>>

c:\log\XYZ1_System_Backup.err

rem move D:\OWFG\Systembackup\work\*.bkf w: >> c:\log\XYZ1_System_Backup.log
robocopy d:\owfg\systembackup\work w: /mov

c:\log\XYZ1_System_Backup.log 1>>

 

[Greg Stigers]

I do not see where this batch file performs a backup.

What does XYZ1_System_Backup.log show?

Also, I very much recommend that, in Scheduled Tasks, you redirect the
output of the entire batch file into a log file, rather than doing this for
each individual line, if only because the former requires no maintenance as
you develop the batch file.

 

[Andy]

Greg,

I didn't include the backup part of the batch file, it's
working fine and isn't relevant to the problem.

The log file told me nothing I didn't already know. It
shows that the move started and stopped instaneously and
didn't move anything, no errors shown.

 

[Greg Stigers]

So, do you have a working answer at this point? I see that you test
errorlevel. What errorlevel do you get? And from what you write, apparently
the batch file does continue after this point, rather than catastrophically
failing, right? Does Robocopy continue retrying every thirty seconds and
failing, well, I guess you would not let it fail for the default one million
times, or more correctly, if you were, it's still running. I also gather
that you do not like the work around of running the move separately (I have
to wonder how you were doing this). In the interests of finding acceptable
workarounds, what if you either run the move in its own instance with cmd
/c, or call a separate batch file from the first one?