Guest Joe Grover Posted October 10, 2008 Posted October 10, 2008 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!
Guest Joe Grover Posted October 10, 2008 Posted October 10, 2008 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!
Guest Pegasus \(MVP\) Posted October 10, 2008 Posted October 10, 2008 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! >
Guest Joe Grover Posted October 10, 2008 Posted October 10, 2008 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! >> > >
Guest Pegasus \(MVP\) Posted October 10, 2008 Posted October 10, 2008 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! >>> >> >> >
Recommended Posts