Error running scheduled task, Windows Server 2008

  • Thread starter Thread starter Joe Grover
  • Start date Start date
J

Joe Grover

Guest
I am setting up a new fileserver on a Windows Server Standard 2008 machine.
The machine is currently running in evaluation mode. I installed it on
9/11/2008.

On our existing fileserver we have a data replication script that copies
data from remote office fileshares to the local system for backup every
night. I have copied the script to the new fileserver, making one change to
the path (the target for copied files is on the C: drive instead of the D:
drive now). Here is the script:

robocopy \\aa-dc1.company.local\share c:\datamirrors\AA /R:3 /MIR > AA.Log
robocopy \\gr-dc1.company.local\share c:\datamirrors\GR /R:3 /MIR > GR.Log
robocopy \\tc-1.company.local\share c:\datamirrors\TC /R:3 /MIR > TC.Log

robocopy \\10.251.20.1\c$\db-backup c:\datamirrors\Kaseya\db-backup /R:3
/MIR > Kaseya.Log
robocopy \\10.251.20.1\c$\kaseya c:\datamirrors\Kaseya\Kaseya /R:3 /MIR >>
Kaseya.Log

- Both the old and new fileservers are members of the domain, as are the
remote fileservers
- The script on both servers is configured to use the domain admin account
credentials
- If I manually run the script from the new fileserver, it starts running
fine
- If I create a scheduled task to run the script, it fails with error 0x10

Any help is appreciated. I'd really like this script to run on a schedule.
Thanks!
 
Re: Error running scheduled task, Windows Server 2008

As an update, the script runs fine if I don't have it go to a log file. I
tried using the /LOG command (changing > AA.log to
/LOG:"c:\datamirrors\aa.log") and it worked as well.

I've updated the script with this information (using /LOG+ for the kaseya
log that we append to) and it seems to be working fine.

"Joe Grover" <grover.joe@acd.net> wrote in message
news:um$aHUtKJHA.1160@TK2MSFTNGP05.phx.gbl...
>I am setting up a new fileserver on a Windows Server Standard 2008 machine.
>The machine is currently running in evaluation mode. I installed it on
>9/11/2008.
>
> On our existing fileserver we have a data replication script that copies
> data from remote office fileshares to the local system for backup every
> night. I have copied the script to the new fileserver, making one change
> to the path (the target for copied files is on the C: drive instead of the
> D: drive now). Here is the script:
>
> robocopy \\aa-dc1.company.local\share c:\datamirrors\AA /R:3 /MIR > AA.Log
> robocopy \\gr-dc1.company.local\share c:\datamirrors\GR /R:3 /MIR > GR.Log
> robocopy \\tc-1.company.local\share c:\datamirrors\TC /R:3 /MIR > TC.Log
>
> robocopy \\10.251.20.1\c$\db-backup c:\datamirrors\Kaseya\db-backup /R:3
> /MIR > Kaseya.Log
> robocopy \\10.251.20.1\c$\kaseya c:\datamirrors\Kaseya\Kaseya /R:3 /MIR >>
> Kaseya.Log
>
> - Both the old and new fileservers are members of the domain, as are the
> remote fileservers
> - The script on both servers is configured to use the domain admin account
> credentials
> - If I manually run the script from the new fileserver, it starts running
> fine
> - If I create a scheduled task to run the script, it fails with error 0x10
>
> Any help is appreciated. I'd really like this script to run on a
> schedule. Thanks!
 
Re: Error running scheduled task, Windows Server 2008

Your script probably ran all along but you were looking at the wrong log
files. When running batch files then it is highly recommended to fully
qualify all file names with drive and folder names. When running scheduled
tasks then it is compulsory. Your output file are "TC.log" and "Kaseya.Log",
with no drive or folder stated. Where should the scheduled task locate this
file?

Have a look in c:\windows\system32. You'll be pleasantly surprised!


"Joe Grover" <grover.joe@acd.net> wrote in message
news:OkivoOuKJHA.3080@TK2MSFTNGP06.phx.gbl...
> As an update, the script runs fine if I don't have it go to a log file. I
> tried using the /LOG command (changing > AA.log to
> /LOG:"c:\datamirrors\aa.log") and it worked as well.
>
> I've updated the script with this information (using /LOG+ for the kaseya
> log that we append to) and it seems to be working fine.
>
> "Joe Grover" <grover.joe@acd.net> wrote in message
> news:um$aHUtKJHA.1160@TK2MSFTNGP05.phx.gbl...
>>I am setting up a new fileserver on a Windows Server Standard 2008
>>machine. The machine is currently running in evaluation mode. I installed
>>it on 9/11/2008.
>>
>> On our existing fileserver we have a data replication script that copies
>> data from remote office fileshares to the local system for backup every
>> night. I have copied the script to the new fileserver, making one change
>> to the path (the target for copied files is on the C: drive instead of
>> the D: drive now). Here is the script:
>>
>> robocopy \\aa-dc1.company.local\share c:\datamirrors\AA /R:3 /MIR >
>> AA.Log
>> robocopy \\gr-dc1.company.local\share c:\datamirrors\GR /R:3 /MIR >
>> GR.Log
>> robocopy \\tc-1.company.local\share c:\datamirrors\TC /R:3 /MIR > TC.Log
>>
>> robocopy \\10.251.20.1\c$\db-backup c:\datamirrors\Kaseya\db-backup /R:3
>> /MIR > Kaseya.Log
>> robocopy \\10.251.20.1\c$\kaseya c:\datamirrors\Kaseya\Kaseya /R:3 /MIR
>> >> Kaseya.Log
>>
>> - Both the old and new fileservers are members of the domain, as are the
>> remote fileservers
>> - The script on both servers is configured to use the domain admin
>> account credentials
>> - If I manually run the script from the new fileserver, it starts running
>> fine
>> - If I create a scheduled task to run the script, it fails with error
>> 0x10
>>
>> Any help is appreciated. I'd really like this script to run on a
>> schedule. Thanks!
>
 
Re: Error running scheduled task, Windows Server 2008

Yeah, I thought about that, but there was nothing there. The script would
never run with the "> filename.log" statement in it. If I set it to run a
minute from now and watched it, it'd just change to "last ran at XX:XX" with
a "Last Run Result" of 0x10, which from everything I could find was pointing
to a permissions issue.

If I took the log statements out and set it to run a minute from then, it'd
start running just dandy. I wasn't actually using the log files to
determine if it ran, but the Modified date of the folders themselves (each
office always has updated files to copy), and they hadn't been modified
since 10/7/2008 (the day I mirrored the data from the old fileserver to the
new one).

Apparently the 2003 box was much more tolerant of that logfile syntax (the
previous admin used that output just because it was normal script syntax,
and not robocopy-specific) and always worked, so I didn't think of changing
it when I copied it all over to the 2008 box. Ah well. Now I know (and
knowing is half the battle).


(Yo) Joe

"Pegasus (MVP)" <I.can@fly.com.oz> wrote in message
news:%23BkyFkuKJHA.4292@TK2MSFTNGP03.phx.gbl...
> Your script probably ran all along but you were looking at the wrong log
> files. When running batch files then it is highly recommended to fully
> qualify all file names with drive and folder names. When running scheduled
> tasks then it is compulsory. Your output file are "TC.log" and
> "Kaseya.Log", with no drive or folder stated. Where should the scheduled
> task locate this file?
>
> Have a look in c:\windows\system32. You'll be pleasantly surprised!
>
>
> "Joe Grover" <grover.joe@acd.net> wrote in message
> news:OkivoOuKJHA.3080@TK2MSFTNGP06.phx.gbl...
>> As an update, the script runs fine if I don't have it go to a log file.
>> I tried using the /LOG command (changing > AA.log to
>> /LOG:"c:\datamirrors\aa.log") and it worked as well.
>>
>> I've updated the script with this information (using /LOG+ for the kaseya
>> log that we append to) and it seems to be working fine.
>>
>> "Joe Grover" <grover.joe@acd.net> wrote in message
>> news:um$aHUtKJHA.1160@TK2MSFTNGP05.phx.gbl...
>>>I am setting up a new fileserver on a Windows Server Standard 2008
>>>machine. The machine is currently running in evaluation mode. I
>>>installed it on 9/11/2008.
>>>
>>> On our existing fileserver we have a data replication script that copies
>>> data from remote office fileshares to the local system for backup every
>>> night. I have copied the script to the new fileserver, making one
>>> change to the path (the target for copied files is on the C: drive
>>> instead of the D: drive now). Here is the script:
>>>
>>> robocopy \\aa-dc1.company.local\share c:\datamirrors\AA /R:3 /MIR >
>>> AA.Log
>>> robocopy \\gr-dc1.company.local\share c:\datamirrors\GR /R:3 /MIR >
>>> GR.Log
>>> robocopy \\tc-1.company.local\share c:\datamirrors\TC /R:3 /MIR > TC.Log
>>>
>>> robocopy \\10.251.20.1\c$\db-backup c:\datamirrors\Kaseya\db-backup /R:3
>>> /MIR > Kaseya.Log
>>> robocopy \\10.251.20.1\c$\kaseya c:\datamirrors\Kaseya\Kaseya /R:3 /MIR
>>> >> Kaseya.Log
>>>
>>> - Both the old and new fileservers are members of the domain, as are the
>>> remote fileservers
>>> - The script on both servers is configured to use the domain admin
>>> account credentials
>>> - If I manually run the script from the new fileserver, it starts
>>> running fine
>>> - If I create a scheduled task to run the script, it fails with error
>>> 0x10
>>>
>>> Any help is appreciated. I'd really like this script to run on a
>>> schedule. Thanks!
>>
>
>
 
Re: Error running scheduled task, Windows Server 2008

If the account used for the scheduled task has full access to the log file
then it makes no difference to the task whether you redirect its output to a
file or not. The task does not even know where the output goes - it only
sees a device to which it sends it data stream.

"Joe Grover" <grover.joe@acd.net> wrote in message
news:eLI%23KyvKJHA.4996@TK2MSFTNGP03.phx.gbl...
> Yeah, I thought about that, but there was nothing there. The script would
> never run with the "> filename.log" statement in it. If I set it to run a
> minute from now and watched it, it'd just change to "last ran at XX:XX"
> with a "Last Run Result" of 0x10, which from everything I could find was
> pointing to a permissions issue.
>
> If I took the log statements out and set it to run a minute from then,
> it'd start running just dandy. I wasn't actually using the log files to
> determine if it ran, but the Modified date of the folders themselves (each
> office always has updated files to copy), and they hadn't been modified
> since 10/7/2008 (the day I mirrored the data from the old fileserver to
> the new one).
>
> Apparently the 2003 box was much more tolerant of that logfile syntax (the
> previous admin used that output just because it was normal script syntax,
> and not robocopy-specific) and always worked, so I didn't think of
> changing it when I copied it all over to the 2008 box. Ah well. Now I
> know (and knowing is half the battle).
>
>
> (Yo) Joe
>
> "Pegasus (MVP)" <I.can@fly.com.oz> wrote in message
> news:%23BkyFkuKJHA.4292@TK2MSFTNGP03.phx.gbl...
>> Your script probably ran all along but you were looking at the wrong log
>> files. When running batch files then it is highly recommended to fully
>> qualify all file names with drive and folder names. When running
>> scheduled tasks then it is compulsory. Your output file are "TC.log" and
>> "Kaseya.Log", with no drive or folder stated. Where should the scheduled
>> task locate this file?
>>
>> Have a look in c:\windows\system32. You'll be pleasantly surprised!
>>
>>
>> "Joe Grover" <grover.joe@acd.net> wrote in message
>> news:OkivoOuKJHA.3080@TK2MSFTNGP06.phx.gbl...
>>> As an update, the script runs fine if I don't have it go to a log file.
>>> I tried using the /LOG command (changing > AA.log to
>>> /LOG:"c:\datamirrors\aa.log") and it worked as well.
>>>
>>> I've updated the script with this information (using /LOG+ for the
>>> kaseya log that we append to) and it seems to be working fine.
>>>
>>> "Joe Grover" <grover.joe@acd.net> wrote in message
>>> news:um$aHUtKJHA.1160@TK2MSFTNGP05.phx.gbl...
>>>>I am setting up a new fileserver on a Windows Server Standard 2008
>>>>machine. The machine is currently running in evaluation mode. I
>>>>installed it on 9/11/2008.
>>>>
>>>> On our existing fileserver we have a data replication script that
>>>> copies data from remote office fileshares to the local system for
>>>> backup every night. I have copied the script to the new fileserver,
>>>> making one change to the path (the target for copied files is on the C:
>>>> drive instead of the D: drive now). Here is the script:
>>>>
>>>> robocopy \\aa-dc1.company.local\share c:\datamirrors\AA /R:3 /MIR >
>>>> AA.Log
>>>> robocopy \\gr-dc1.company.local\share c:\datamirrors\GR /R:3 /MIR >
>>>> GR.Log
>>>> robocopy \\tc-1.company.local\share c:\datamirrors\TC /R:3 /MIR >
>>>> TC.Log
>>>>
>>>> robocopy \\10.251.20.1\c$\db-backup c:\datamirrors\Kaseya\db-backup
>>>> /R:3 /MIR > Kaseya.Log
>>>> robocopy \\10.251.20.1\c$\kaseya c:\datamirrors\Kaseya\Kaseya /R:3 /MIR
>>>> >> Kaseya.Log
>>>>
>>>> - Both the old and new fileservers are members of the domain, as are
>>>> the remote fileservers
>>>> - The script on both servers is configured to use the domain admin
>>>> account credentials
>>>> - If I manually run the script from the new fileserver, it starts
>>>> running fine
>>>> - If I create a scheduled task to run the script, it fails with error
>>>> 0x10
>>>>
>>>> Any help is appreciated. I'd really like this script to run on a
>>>> schedule. Thanks!
>>>
>>
>>
>
 
Back
Top