Scheduling XCOPY issue

[David Graham]

Hi all,

I found lots of hits on this subject but no resolution. I have a bat
file that I wrote to XCOPY the contents of a local directory to a
network share. It runs 100% reliable when I launch the bat file from
Explorer, but nearly always fails when scheduled with the task
scheduler. The funny thing is, it's actually worked OK a total of two
times out of about 50 attempts, and I have no idea what was different
about the times it worked vs. the times it didn't. In addition, the
log shows "Result: The task completed with an exit code of (0)." after
each run, but nothing happens.

Here's the bat file contents:

net use G: \\SRV2\accounting [password*] /USER:admin /PERSISTENT:no
xcopy C:\SQLTest G:\Backups\ADP_Server /E /Y /C
net use G: /DELETE

* the real password has been ommitted for obvious reasons

Please help me before I pull all of my hair out!

- Dave
(e-mail address removed)

 

[David Graham]

As which user does it run?

admin (not system)

What is the environment and path and default
directory when it runs?

I'm not sure about this - I'm brand new to this. Can you recommend
something?

What rights and permissions does that user have

It's the system administrator account.

-- and how is that changed by the "right to run as
a batch file" vs. Interactive?

I'm not sure.

Thanks for the help!

--

Dave Graham
(e-mail address removed)

--
Herb Martin

Hi all,

I found lots of hits on this subject but no resolution. I have a bat
file that I wrote to XCOPY the contents of a local directory to a
network share. It runs 100% reliable when I launch the bat file from
Explorer, but nearly always fails when scheduled with the task
scheduler. The funny thing is, it's actually worked OK a total of two
times out of about 50 attempts, and I have no idea what was different
about the times it worked vs. the times it didn't. In addition, the
log shows "Result: The task completed with an exit code of (0)." after
each run, but nothing happens.

Here's the bat file contents:

net use G: \\SRV2\accounting [password*] /USER:admin /PERSISTENT:no
xcopy C:\SQLTest G:\Backups\ADP_Server /E /Y /C
net use G: /DELETE

* the real password has been ommitted for obvious reasons

 

[Dean Wells [MVP]]

Hi all,

I found lots of hits on this subject but no resolution. I have a bat
file that I wrote to XCOPY the contents of a local directory to a
network share. It runs 100% reliable when I launch the bat file from
Explorer, but nearly always fails when scheduled with the task
scheduler. The funny thing is, it's actually worked OK a total of two
times out of about 50 attempts, and I have no idea what was different
about the times it worked vs. the times it didn't. In addition, the
log shows "Result: The task completed with an exit code of (0)." after
each run, but nothing happens.

Here's the bat file contents:

net use G: \\SRV2\accounting [password*] /USER:admin /PERSISTENT:no
xcopy C:\SQLTest G:\Backups\ADP_Server /E /Y /C
net use G: /DELETE

* the real password has been ommitted for obvious reasons

Please help me before I pull all of my hair out!

- Dave
(e-mail address removed)

I tried it myself and couldn't repro. your failure. I would suggest
adding some logging to the script by appending -

1>>%TEMP%\XCOPY-DEBUG.LOG 2>&1

This will create a log of both successful and errored responses. Note,
this file will grow indefinitely so you may like to remove these
modifications if you locate the flaw.

HTH

Dean

 

[Herb Martin]

admin (not system)


I'm not sure about this - I'm brand new to this. Can you recommend
something?

Build a batch file to output this to a known location, e.g.,
C:\temp\test.txt or
whatever.
@Echo %path% >C:\temp\test.txt
@echo etc.....

If it doesn't run AT ALL, of course this won't help....

It's the system administrator account.

One is tempted to (jokingly) say, "So what?" <GRIN> -- The admin
account may not have "run as batch" either. Use the security
policy to make sure you have granted this right to the account/group
of the account.

I'm not sure.

Batch is now a special group (like Everyone, Interactive, etc) but
it is very unlikely that you have specific permissions that affect file
or object access based on this.

The most likely is that "run a Batch" RIGHT (not permission.)

 

[Musafir]

Hi all, [...]
Here's the bat file contents:

net use G: \\SRV2\accounting [password*] /USER:admin /PERSISTENT:no
xcopy C:\SQLTest G:\Backups\ADP_Server /E /Y /C
net use G: /DELETE

[...]

I am guessing here because I have faced a similar issue before. The
problem might have to do with mapping network drives. It is a known
issue that mapping of network drives is not reliable when jobs are run
via Task Scheduler (see
<http://www.winscriptingsolutions.com/Articles/Index.cfm?ArticleID=20769>
). I would suggest using UNC paths (as the author of the article does
too). In my case I did not have the option to use UNC and I wrote some
code to verify that the mapping succeeded - if I remember right, in
the failure case it would send notifications about mapping problems.
If you want that code, I can dig it out.

Hope this helps. Let us know,
Sharad Agarwal 'Musafir'

 

[David Graham]

Herb,

Thanks so much for the reply. I think we're getting somewhere ... I just
don't know where yet! ;-)

Build a batch file to output this to a known location, e.g.,
C:\temp\test.txt or
whatever.
@Echo %path% >C:\temp\test.txt
@echo etc.....
If it doesn't run AT ALL, of course this won't help....

OK ... so the PATH contains the following (and some other non-relevant
items):
C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem ...

How can I pipe the output of each statement to a log file?

One is tempted to (jokingly) say, "So what?" <GRIN> -- The admin
account may not have "run as batch" either. Use the security
policy to make sure you have granted this right to the account/group
of the account.

OK ... so I'm admittedly a newbie on Windows sysadmin so thanks for
going easy on me.

That said, unless I'm missing something ...

1) The system admin account has unrestricted access, right?
2) I couldn't find a security policy setting for 'run as batch'. Are you
referring to 'Log on as a batch job'? If so, I did verify that the
System Administrator account does indeed have rights under that policy.

Batch is now a special group (like Everyone, Interactive, etc) but
it is very unlikely that you have specific permissions that affect file
or object access based on this.

The most likely is that "run a Batch" RIGHT (not permission.)

As a follow-up, I did run accross some posts that mentioned problems
with rights, but in those cases they got error messages. In my case, I
don't get an error message even when it fails.

Thanks,

Dave

 

[Herb Martin]

Herb,

Thanks so much for the reply. I think we're getting somewhere ... I just
don't know where yet! ;-)



OK ... so the PATH contains the following (and some other non-relevant
items):
C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem ...

How can I pipe the output of each statement to a log file?

Usually on each SEPARATE command, you use: >> c:\temp
( you can use 1 ">" on the first to initialize the file but each subsequent
redirect must use ">>" to avoid wiping the file.)

If you want to make sure to grab "standard errors" too (a good idea
when troubleshooting) then use ">>c:\log.txt 2>&1" (IN THAT ORDER),
e.g.,

@echo Starting batch run (init file and no errors possible) >c:\log.txt
@xcopy c:\temp c:\t\ /s >>c:\log.txt 2>&1
REM etc...

When running from the command line you can "redirect an entire
batch" but we don't have that option here (unless we play games
with the scheduler command which I don't want to suggest.)

OK ... so I'm admittedly a newbie on Windows sysadmin so thanks for
going easy on me.

Sure, but the reason for the jibe is to "burn it in" for the future so you
will always realize that Admins are ONLY special (or most special
<grin) because they have more "rights" and typically "more permisssions"
but they cannot necessarily do everthing (by default.)

That said, unless I'm missing something ...

1) The system admin account has unrestricted access, right?

No -- see above. Check you local security policy if this is
a machine account -- Domain Group Policy if not.

2) I couldn't find a security policy setting for 'run as batch'. Are you
referring to 'Log on as a batch job'? If so, I did verify that the
System Administrator account does indeed have rights under that policy.

Yes -- I don't always know the "exact" name of these things as this
refers to the "right to logon as a batch file" but has the above name
in the security settings.

As a follow-up, I did run accross some posts that mentioned problems
with rights, but in those cases they got error messages. In my case, I
don't get an error message even when it fails.

Try the logging then, because the IF it "runs at all" you have the batch
right set correctly.

 

[Herb Martin]

(e-mail address removed) (David Graham) wrote in message

Hi all, [...]
Here's the bat file contents:

net use G: \\SRV2\accounting [password*] /USER:admin /PERSISTENT:no
xcopy C:\SQLTest G:\Backups\ADP_Server /E /Y /C
net use G: /DELETE

[...]

I am guessing here because I have faced a similar issue before. The
problem might have to do with mapping network drives. It is a known
issue that mapping of network drives is not reliable when jobs are run
via Task Scheduler (see

If this is the issue you can always "map explicitly", e.g., net use P:
\\server\share
OR just use the UNC name directly, e.g.,

xcopy *.* \\server\share\backupPath\etc\ /v >>log.txt 2>1

 

[David Graham]

Musafir (Sharad?),

You win the prize! It works every time with UNC paths, and fails 99% of
the time with drive mappings if the batch file is run from the task
scheduler. Weird!?!?

Anyway, thanks to Dean for the help with the debugging code ...

1>>%TEMP%\XCOPY-DEBUG.LOG 2>&1

( FYI ... I had to remove the %TEMP% variable as they don't work in
scheduled tasks AFAIK. )

I was able to verify the exact cause of the problem:

"Invalid drive specification. 0 File(s) copied"

It's still weird that it exits without an error and even weirder that it
doesn't just work the way it is, but I'm on to the next project and I'm
not looking back.

A big thanks to all of you who helped me on this one.

- Dave

 

[Herb Martin]

( FYI ... I had to remove the %TEMP% variable as they don't work in

scheduled tasks AFAIK. )

You can use environment variables in batch files, it's just
that they may not be set (or set the way you expect).

 

[Dean Wells [MVP]]

Musafir (Sharad?),

You win the prize! It works every time with UNC paths, and fails 99%
of the time with drive mappings if the batch file is run from the task
scheduler. Weird!?!?

Anyway, thanks to Dean for the help with the debugging code ...


( FYI ... I had to remove the %TEMP% variable as they don't work in
scheduled tasks AFAIK. )

I was able to verify the exact cause of the problem:

"Invalid drive specification. 0 File(s) copied"

It's still weird that it exits without an error and even weirder that
it doesn't just work the way it is, but I'm on to the next project
and I'm not looking back.

A big thanks to all of you who helped me on this one.

- Dave


<http://www.winscriptingsolutions.com/Articles/Index.cfm?ArticleID=20769

Glad to hear you got it resolved.

Oddly enough though, I am again unable to repro. the issue you reference
with regard to the %TEMP% variable ... it remains populated regardless
of the context under which the scheduled task runs. When executed under
the Administrator, TEMP contains -

TEMP=C:\DOCUME~1\Administrator\LOCALS~1\Temp

.... when executed under the LSA, TEMP contains -

TEMP=C:\WINDOWS\TEMP

These results are based on Windows XP behavior which may be the cause of
the anomolies (assuming you're running an alternative OS).

Oh well, either way the errant results are little more than a curiosity!

Dean

 

[Herb Martin]

Oddly enough though, I am again unable to repro. the issue you reference

These results are based on Windows XP behavior which may be the cause of
the anomalies (assuming you're running an alternative OS).

Even though I was the first one to suggest the environment
MIGHT be different, I pretty much find what you find today.

I do seem to remember such problems from earlier times;
perhaps NT4 or even earlier.