Results 1 to 6 of 6
  1. #1
    New Lounger
    Join Date
    Sep 2015
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Schedule task to move files to network drive

    I need to schedule a task that will move files (fairly often, likely every 5 minutes) from a shared folder on a local D: drive to a network drive V:

    Here is what I have so far:
    A bat file that works when I run it manually I have it write a simple log file so that I can see where it gets through when run with the task.

    Code:
    echo Write log file > LogStart.txt
    C:\Windows\System32\robocopy.exe "\\PCICSWKS001\D$\ToBeMoved" "V:" /s /e /MOV /r:0 /W:0
    echo Write log file > LogEnd.txt
    When I run the bat file manually it moves the files. When I run it with the task, it does not move the files, but does write both log files.
    I have the machine name in the source part of the robocopy call because I was testing using the UNC path instead of the direct drive letter. This seems to work for the source but not the destination.

    Here is the task action I have setup:
    TaskAction.PNG

    Here is the General tab of the task:
    TaskGeneral.PNG

    Please help, I thought this would be simple, but its taking way too long haha.

  2. #2
    Silver Lounger
    Join Date
    Oct 2012
    Posts
    2,335
    Thanks
    13
    Thanked 267 Times in 260 Posts
    If not adverse to third party software, I'd try something like Allway Sync or Syncback, which also have modes for one direction. With Allway you can even set the delay for backup between 1 minute and 1 hour (5 min. is a choice) without even using the task scheduler, but TS is also in the options.

  3. #3
    Administrator
    Join Date
    Mar 2001
    Location
    St Louis, Missouri, USA
    Posts
    23,572
    Thanks
    5
    Thanked 1,057 Times in 926 Posts
    Does the account used for the scheduled task have access to "D$"?

    Joe

  4. #4
    4 Star Lounger
    Join Date
    Jan 2010
    Location
    Fort McMurray, Alberta, Canada
    Posts
    557
    Thanks
    51
    Thanked 68 Times in 66 Posts
    You are on the right track; I've done something very similar to this.

    Your use of UNC syntax and map drives looks backwards frankly. The local D: drive absolutely should not require a UNC reference. On the other hand that V: drive is potentially problematic.

    Most map drives are local account settings (V is a very high drive letter and I'm assuming it is a mapped network resource). If your scheduled task is running under a different account than what your interactive testing uses, very likely the issue is that the map to V: doesn't exist. That might explain the failures under task scheduler.

    More comments on your code generally. Logging the actions to a log file is a great idea. However I think you'll find that you can increase the intelligence of your log entries and file use. Use the double arrow (>>) to append entries to your log file (so use the same file name of course). Do this on every single log command and your log file will become perpetual, even across task runs. Don't worry about log growth; it will grow slowly enough that it's not a problem. If you ever have a concern about it you can manually clear this file.

    Next thing, log the date and time. Put this at the top of the script (you can have more, but at least once is needed for professional results). The result looks like this:

    Date /T >> LogFile.Txt
    Time /T >> LogFile.Txt
    While you're at it, log a line of characters to separate script runs. You should also "introduce" a log run by announcing it explicitly. This looks like the following:

    echo ++++++++++++++++++++++++++++++++++++++++++++++ >> LogFile.Txt
    echo Starting %0
    That %0 is a parameter variable and it contains the name of the running bat file itself. There's a lot more to variables and I'll only say one more thing at this point. Your log file name should be a variable name. It will repeat a lot and making it a variable gives you better control of that.

    Finally, I tended to stay away from fancier functions like RoboCopy. They can be great, especially when they do multiple things for you. However RoboCopy isn't available by default in Windows XP. Also, logging gets a bit more complicated because RoboCopy uses a slightly different logging model (not bad, just different).

    Therefore I found myself copying the files first, checking that the copy worked OK, and then manually deleting them from the source if the copy worked. It's more code and a nuisance, to be honest. However it was what I needed to do.

  5. #5
    New Lounger
    Join Date
    Jul 2015
    Location
    Montreal, Canada
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts
    I use a similar script to move files from application servers to a common shared drive. In my case, I use the following in the batch file:

    net use V: /delete
    net use V: "\\The UNC to the share" the password /user:Username

    The code to do whatever goes here....

    net use V: /delete

    I have been appending to a log file as BHarder mentioned in the previous post, but did not consider "Introducing" the log run (echo Starting %0)....very nice. Thanks Bharder.

    HTH,

    RoadKill

  6. #6
    4 Star Lounger
    Join Date
    Jan 2010
    Location
    Fort McMurray, Alberta, Canada
    Posts
    557
    Thanks
    51
    Thanked 68 Times in 66 Posts
    You are welcome RoadKill. I'd feel more proud but I forgot something in that intro code. I meant to log to a file, which requires the following:

    echo Starting %0 >> LogFile.Txt
    This is another aspect of batch file programming meant for automation. Where do the messages go?

    Durable & auditable automation requires logging to a file. However you must manually direct the messages there, otherwise your messages go to the console. Console messages get lost during automated runs... but when you want a "one-time" run, or for debugging, then it's hard to beat console messages for convenience and practicality.

    Long story short I find myself deliberately logging messages to both. That too is a pain and quite wordy (can code be wordy?). Yet when you commit to this you can develop very nice, multi-use utilities that have good batch and interactive characteristics.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •