scheduled task can not access shared drive

[powdered_toast_man]

This is actually on a Windows 2003 server but I didn't see it among the
options.

I've created a batch file on server A to generate a report and copy it to a
shared drive on server B. When I log onto server A and run the batch file it
works; when I use the task scheduler to run the batch it fails. A coworker
suggested using the unc path rather than the mapped drive letter designation
but that didn't help - all that did was generate a "CMD does not support UNC
paths as current directories" error message.

I have a hunch that the problem is because the shared drive is not
recognized unless the user physically logs onto the box. Is that the case and
is there a way to work around this?

 

[Pegasus \(MVP\)]

This is actually on a Windows 2003 server but I didn't see it among the
options.

I've created a batch file on server A to generate a report and copy it to
a
shared drive on server B. When I log onto server A and run the batch file
it
works; when I use the task scheduler to run the batch it fails. A coworker
suggested using the unc path rather than the mapped drive letter
designation
but that didn't help - all that did was generate a "CMD does not support
UNC
paths as current directories" error message.

I have a hunch that the problem is because the shared drive is not
recognized unless the user physically logs onto the box. Is that the case
and
is there a way to work around this?

Let's have a look at your batch file!

What account do you use for the scheduled task? Does it have access
to the shared resource?

About newsgroups: There are several with the word "Server" in it, e.g.
"windows.server.general".

 

[powdered_toast_man]

Let's have a look at your batch file!

What account do you use for the scheduled task? Does it have access
to the shared resource?

About newsgroups: There are several with the word "Server" in it, e.g.
"windows.server.general".

A domain level servce account is running the task; it does have access to
the resource. Again, when I actually remote desktop onto the server with the
service account id and run the batch file it works fine - it only fails as a
scheduled task. Perhaps I don't fully understand the difference between
physically logging onto a server and the way task scheduler "logs on" to run
the task but something tells me that's the difference and reason for failure.

As far as the batch file itself, it's very simple:
copy "C:\reports\daily_report" "Z:\transferred reports\daily_report"
Where "Z" is the mapped shared drive. As mentioned I also tried it with the
unc path of "\\servername\share\transferred reports\daily_report" but that
didn't do the trick either.

 

[Pegasus \(MVP\)]

A domain level servce account is running the task; it does have access to
the resource. Again, when I actually remote desktop onto the server with
the
service account id and run the batch file it works fine - it only fails as
a
scheduled task. Perhaps I don't fully understand the difference between
physically logging onto a server and the way task scheduler "logs on" to
run
the task but something tells me that's the difference and reason for
failure.

As far as the batch file itself, it's very simple:
copy "C:\reports\daily_report" "Z:\transferred reports\daily_report"
Where "Z" is the mapped shared drive. As mentioned I also tried it with
the
unc path of "\\servername\share\transferred reports\daily_report" but that
didn't do the trick either.

Your batch file has a couple of problems:
- Drive Z: is unlikely to exist. You MUST use UNC names.
- If the file exists in the target folder then the batch file may hang,
waiting for your comfirmation to overwrite it.

Try this instead:
1. @echo off
2. set TargetDir=\\Server\Share\transferred reports
3.
4. echo Start %date% %time% %UserName% >> c:\test.log
5. dir "%TargetDir%" 1>>c:\test.log 2>>&1
6. copy /y "C:\reports\daily_report" "%TargetDir%" 1>>c:\test.log 2>>&1
7. echo End %date% %time% >> c:\test.log
8. echo. >> c:\test.log

Watch out for wrapped lines! After running the job through
the scheduler, examine c:\test.log and post it if the problem
is not perfectly obvious. By the way - is "daily_report" a file
or a folder? If it is a folder then the code should look like so:
1. @echo off
2. set TargetDir=\\Server\Share\transferred reports
3.
4. echo Start %date% %time% %UserName% >> c:\test.log
5. dir "%TargetDir% 1>>c:\test.log 2>>&1
6. xcopy /y "C:\reports\daily_report\*.*" "%TargetDir%\daily_report\"
1>>c:\test.log 2>>&1
7. echo End %date% %time% >> c:\test.log
8. echo. >> c:\test.log

 

[Dave Patrick]

Also don't forget if the job connects to another machine you may need to add
the user/ group 'logon as batch job' rights (server side). Control
Panel|Admin Tools|Local Security Policy\Local Policies\User Rights
Assignments
"Log on as a batch job"


--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

 

[powdered_toast_man]

Also don't forget if the job connects to another machine you may need to add
the user/ group 'logon as batch job' rights (server side). Control
Panel|Admin Tools|Local Security Policy\Local Policies\User Rights
Assignments
"Log on as a batch job"


--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

Thanks to you both. I actually got it to work - feel a bit stupid about
this but noticed that I had left the "$" out of the unc path (duh.) I'll be
back if that wasn't the problem (I'll know tomorrow morning as these are
scheduled to run overnight.)

 

[Pegasus \(MVP\)]

Also don't forget if the job connects to another machine you may need to
add
the user/ group 'logon as batch job' rights (server side). Control
Panel|Admin Tools|Local Security Policy\Local Policies\User Rights
Assignments
"Log on as a batch job"


--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

Thanks to you both. I actually got it to work - feel a bit stupid about
this but noticed that I had left the "$" out of the unc path (duh.) I'll
be
back if that wasn't the problem (I'll know tomorrow morning as these are
scheduled to run overnight.)

Thanks for the feedback. It actually leaves me mystified because
I cannot reconcile it with this phrase from your initial post: "When
I log onto server A and run the batch file it works; when I use the
task scheduler to run the batch it fails."

 

[Bob I]

:

Also don't forget if the job connects to another machine you may need to
add
the user/ group 'logon as batch job' rights (server side). Control
Panel|Admin Tools|Local Security Policy\Local Policies\User Rights
Assignments
"Log on as a batch job"


--

Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

Thanks to you both. I actually got it to work - feel a bit stupid about
this but noticed that I had left the "$" out of the unc path (duh.) I'll
be
back if that wasn't the problem (I'll know tomorrow morning as these are
scheduled to run overnight.)

Thanks for the feedback. It actually leaves me mystified because
I cannot reconcile it with this phrase from your initial post: "When
I log onto server A and run the batch file it works; when I use the
task scheduler to run the batch it fails."

Originally the batch worked when he logged in because his profile had
"Z" mapped. After he changed it to UNC it still didn't work in task
scheduler because of the missing "$" in the path.

 

[Jay Chan]

message

Also don't forget if the job connects to another machine you may need to
add
the user/ group 'logon as batch job' rights (server side). Control
Panel|Admin Tools|Local Security Policy\Local Policies\User Rights
Assignments
"Log on as a batch job"
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

Thanks to you both.  I actually got it to work - feel a bit stupid about
this but noticed that I had left the "$" out of the unc path (duh.)  I'll
be
back if that wasn't the problem (I'll know tomorrow morning as these are
scheduledto run overnight.)

Thanks for the feedback. It actually leaves me mystified because
I cannot reconcile it with this phrase from your initial post: "When
I log onto server A and run the batch file it works; when I use
the taskscheduler to run the batch it fails."

I am in a similar situation as the original poster. A task cannot get
access to a mapped drive if I run it as a scheduled task in a
Windows-2000 server. On the other hand, the task can get access to
the mapped drive if I run it interactively through the command
prompt. Both cases are running under the same user account and
password.

The exactly same task runs perfectly fine as a scheduled task in other
two servers (Wndows 2003). And it runs fine in as a scheduled task as
of last week in that Windows-2000 server. Something might have
changed during the weekend or on Monday.

Last time (years ago) when I had this same problem, I fixed the
problem by making sure I used the same user account that I used to
startup the server to run the scheduled task (something to do with
allowing the scheduled task to get access to the user desktop). This
also might or might not have to do with the capitalization of the user
name (I might have confused this with the use of RSH in Unix); I use
exactly the same capitalization for startup logon and scheduled task
any way to play safe. This works -- at least up to last week.
Somehow, this doesn't work now for that Windows-2000 server.

I can re-create this problem by scheduling a simple task like this in
the Windows-2000 server:

cmd /c dir S:\ > C:\Temp\JayTest.txt

Here, S: is the mapped drive letter. If I run it through a command
prompt, it saves the file listing of S:\ to a text file. If I run it
as a scheduled task, it creates an empty file. The same command works
fine as a scheduled task in the other two servers (Windows 2003).

I have asked around, and no one has changed anything on that server.
Therefore, I really don't know what caused this problem.

The alternative is to use UNC. But this would mean that I need to
customize the scheduled task for each branch office because the same
drive letter is mapped to different shared folder for each branch
office. The original idea of using a mapped drive letter is to allow
the same program to run in all different branch offices. Yes, I can
do this by using a different mean to tell the program where it should
retrieve the info; but I prefer to figure out what goes wrong in that
Windows-2000 server; afterall, the same task works fine in other two
servers.

Thanks in advance for any suggestion.

Jay Chan

 

[Jay Chan]

messagenews:[email protected]...

:
Also don't forget if the job connects to another machine you may needto
add
the user/ group 'logon as batch job' rights (server side). Control
Panel|Admin Tools|Local Security Policy\Local Policies\User Rights
Assignments
"Log on as a batch job"
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect
Thanks to you both.  I actually got it to work - feel a bit stupid about
this but noticed that I had left the "$" out of the unc path (duh.)  I'll
be
back if that wasn't the problem (I'll know tomorrow morning as these are
scheduledto run overnight.)

Thanks for the feedback. It actually leaves me mystified because
I cannot reconcile it with this phrase from your initial post: "When
I log onto server A and run the batch file it works; when I use
the taskscheduler to run the batch it fails."

I am in a similar situation as the original poster.  A task cannot get
access to a mapped drive if I run it as a scheduled task in a
Windows-2000 server.  On the other hand, the task can get access to
the mapped drive if I run it interactively through the command
prompt.  Both cases are running under the same user account and
password.

The exactly same task runs perfectly fine as a scheduled task in other
two servers (Wndows 2003).  And it runs fine in as a scheduled task as
of last week in that Windows-2000 server.  Something might have
changed during the weekend or on Monday.

Last time (years ago) when I had this same problem, I fixed the
problem by making sure I used the same user account that I used to
startup the server to run the scheduled task (something to do with
allowing the scheduled task to get access to the user desktop).  This
also might or might not have to do with the capitalization of the user
name (I might have confused this with the use of RSH in Unix); I use
exactly the same capitalization for startup logon and scheduled task
any way to play safe.  This works -- at least up to last week.
Somehow, this doesn't work now for that Windows-2000 server.

I can re-create this problem by scheduling a simple task like this in
the Windows-2000 server:

   cmd /c dir S:\ > C:\Temp\JayTest.txt

Here, S: is the mapped drive letter.  If I run it through a command
prompt, it saves the file listing of S:\ to a text file.  If I run it
as a scheduled task, it creates an empty file.  The same command works
fine as a scheduled task in the other two servers (Windows 2003).

I have asked around, and no one has changed anything on that server.
Therefore, I really don't know what caused this problem.

The alternative is to use UNC.  But this would mean that I need to
customize the scheduled task for each branch office because the same
drive letter is mapped to different shared folder for each branch
office.  The original idea of using a mapped drive letter is to allow
the same program to run in all different branch offices.  Yes, I can
do this by using a different mean to tell the program where it should
retrieve the info; but I prefer to figure out what goes wrong in that
Windows-2000 server; afterall, the same task works fine in other two
servers.

Thanks in advance for any suggestion.

Jay Chan

I changed the test script a bit to read this:

cmd /c net use > C:\Temp\JayTest_ShowMapDrives.txt

When I open the JayTest_ShowMapDrives.txt file, I see this:

Status Local Remote Network
-------------------------------------------------------------------
Unavailable R: \\MyServer\MyFolderA Microsoft Windows Network
Unavailable S: \\MyServer\MyFolderB Microsoft Windows Network

You can see that the status of all the mapped drives are
"Unavailable". The status should have been either "OK" or
"Disconnected".

Seem like the drive letters are there. But the scheduled task doesn't
have access to them. This is odd because the scheduled task is
running the same user account as the one that I use to boot up the
server.

Jay Chan

 

[Pegasus \(MVP\)]

in
messagenews:[email protected]...

:
Also don't forget if the job connects to another machine you may need
to
add
the user/ group 'logon as batch job' rights (server side). Control
Panel|Admin Tools|Local Security Policy\Local Policies\User Rights
Assignments
"Log on as a batch job"
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect
Thanks to you both. I actually got it to work - feel a bit stupid
about
this but noticed that I had left the "$" out of the unc path (duh.)
I'll
be
back if that wasn't the problem (I'll know tomorrow morning as these
are
scheduledto run overnight.)

Thanks for the feedback. It actually leaves me mystified because
I cannot reconcile it with this phrase from your initial post: "When
I log onto server A and run the batch file it works; when I use
the taskscheduler to run the batch it fails."

I am in a similar situation as the original poster. A task cannot get
access to a mapped drive if I run it as a scheduled task in a
Windows-2000 server. On the other hand, the task can get access to
the mapped drive if I run it interactively through the command
prompt. Both cases are running under the same user account and
password.

The exactly same task runs perfectly fine as a scheduled task in other
two servers (Wndows 2003). And it runs fine in as a scheduled task as
of last week in that Windows-2000 server. Something might have
changed during the weekend or on Monday.

Last time (years ago) when I had this same problem, I fixed the
problem by making sure I used the same user account that I used to
startup the server to run the scheduled task (something to do with
allowing the scheduled task to get access to the user desktop). This
also might or might not have to do with the capitalization of the user
name (I might have confused this with the use of RSH in Unix); I use
exactly the same capitalization for startup logon and scheduled task
any way to play safe. This works -- at least up to last week.
Somehow, this doesn't work now for that Windows-2000 server.

I can re-create this problem by scheduling a simple task like this in
the Windows-2000 server:

cmd /c dir S:\ > C:\Temp\JayTest.txt

Here, S: is the mapped drive letter. If I run it through a command
prompt, it saves the file listing of S:\ to a text file. If I run it
as a scheduled task, it creates an empty file. The same command works
fine as a scheduled task in the other two servers (Windows 2003).

I have asked around, and no one has changed anything on that server.
Therefore, I really don't know what caused this problem.

The alternative is to use UNC. But this would mean that I need to
customize the scheduled task for each branch office because the same
drive letter is mapped to different shared folder for each branch
office. The original idea of using a mapped drive letter is to allow
the same program to run in all different branch offices. Yes, I can
do this by using a different mean to tell the program where it should
retrieve the info; but I prefer to figure out what goes wrong in that
Windows-2000 server; afterall, the same task works fine in other two
servers.

Thanks in advance for any suggestion.

Jay Chan

I changed the test script a bit to read this:

cmd /c net use > C:\Temp\JayTest_ShowMapDrives.txt

When I open the JayTest_ShowMapDrives.txt file, I see this:

Status Local Remote Network
-------------------------------------------------------------------
Unavailable R: \\MyServer\MyFolderA Microsoft Windows Network
Unavailable S: \\MyServer\MyFolderB Microsoft Windows Network

You can see that the status of all the mapped drives are
"Unavailable". The status should have been either "OK" or
"Disconnected".

Seem like the drive letters are there. But the scheduled task doesn't
have access to them. This is odd because the scheduled task is
running the same user account as the one that I use to boot up the
server.

Jay Chan

=======================

Don't use fixed drive letters for shares in your scheduled
tasks - use UNC coding instead.

 

[Jay Chan]

in
message
:
Also don't forget if the job connects to another machine you may need
to
add
the user/ group 'logon as batch job' rights (server side). Control
Panel|Admin Tools|Local Security Policy\Local Policies\User Rights
Assignments
"Log on as a batch job"
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect
Thanks to you both. I actually got it to work - feel a bit stupid
about
this but noticed that I had left the "$" out of the unc path (duh.)
I'll
be
back if that wasn't the problem (I'll know tomorrow morning as these
are
scheduledto run overnight.)
Thanks for the feedback. It actually leaves me mystified because
I cannot reconcile it with this phrase from your initial post: "When
I log onto server A and run the batch file it works; when I use
the taskscheduler to run the batch it fails."

I am in a similar situation as the original poster. A task cannot get
access to a mapped drive if I run it as a scheduled task in a
Windows-2000 server. On the other hand, the task can get access to
the mapped drive if I run it interactively through the command
prompt. Both cases are running under the same user account and
password.

The exactly same task runs perfectly fine as a scheduled task in other
two servers (Wndows 2003). And it runs fine in as a scheduled task as
of last week in that Windows-2000 server. Something might have
changed during the weekend or on Monday.

Last time (years ago) when I had this same problem, I fixed the
problem by making sure I used the same user account that I used to
startup the server to run the scheduled task (something to do with
allowing the scheduled task to get access to the user desktop). This
also might or might not have to do with the capitalization of the user
name (I might have confused this with the use of RSH in Unix); I use
exactly the same capitalization for startup logon and scheduled task
any way to play safe. This works -- at least up to last week.
Somehow, this doesn't work now for that Windows-2000 server.

I can re-create this problem by scheduling a simple task like this in
the Windows-2000 server:

cmd /c dir S:\ > C:\Temp\JayTest.txt

Here, S: is the mapped drive letter. If I run it through a command
prompt, it saves the file listing of S:\ to a text file. If I run it
as a scheduled task, it creates an empty file. The same command works
fine as a scheduled task in the other two servers (Windows 2003).

I have asked around, and no one has changed anything on that server.
Therefore, I really don't know what caused this problem.

The alternative is to use UNC. But this would mean that I need to
customize the scheduled task for each branch office because the same
drive letter is mapped to different shared folder for each branch
office. The original idea of using a mapped drive letter is to allow
the same program to run in all different branch offices. Yes, I can
do this by using a different mean to tell the program where it should
retrieve the info; but I prefer to figure out what goes wrong in that
Windows-2000 server; afterall, the same task works fine in other two
servers.

Thanks in advance for any suggestion.

Jay Chan

I changed the test script a bit to read this:

   cmd /c net use > C:\Temp\JayTest_ShowMapDrives.txt

When I open the JayTest_ShowMapDrives.txt file, I see this:

   Status       Local  Remote                Network
   -------------------------------------------------------------------
   Unavailable  R:     \\MyServer\MyFolderA  Microsoft WindowsNetwork
   Unavailable  S:     \\MyServer\MyFolderB  Microsoft WindowsNetwork

You can see that the status of all the mapped drives are
"Unavailable".  The status should have been either "OK" or
"Disconnected".

Seem like the drive letters are there.  But the scheduled task doesn't
have access to them.  This is odd because the scheduled task is
running the same user account as the one that I use to boot up the
server.

Jay Chan

=======================

Don't use fixed drive letters for shares in your scheduled
tasks - use UNC coding instead.

This is odd. I have been using mapped drive letters for years without
any problem as long as I use the same user account to startup the
server and to run the scheduled task. I don't know what's been
changed recently.

If I have to use UNC, I will need to change the script and assign the
UNC to the script through a parameter or something in order to run the
exact same script in multiple branch offices. Sigh...

Jay Chan

 

[Jay Chan]

message
:
Also don't forget if the job connects to another machine you may need to
add
the user/ group 'logon as batch job' rights (server side). Control
Panel|Admin Tools|Local Security Policy\Local Policies\User Rights
Assignments
"Log on as a batch job"
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect
Thanks to you both.  I actually got it to work - feel a bit stupidabout
this but noticed that I had left the "$" out of the unc path (duh.)  I'll
be
back if that wasn't the problem (I'll know tomorrow morning as theseare
scheduledto run overnight.)
Thanks for the feedback. It actually leaves me mystified because
I cannot reconcile it with this phrase from your initial post: "When
I log onto server A and run the batch file it works; when I use
the taskscheduler to run the batch it fails."

I am in a similar situation as the original poster.  A task cannot get
access to a mapped drive if I run it as a scheduled task in a
Windows-2000 server.  On the other hand, the task can get access to
the mapped drive if I run it interactively through the command
prompt.  Both cases are running under the same user account and
password.

The exactly same task runs perfectly fine as a scheduled task in other
two servers (Wndows 2003).  And it runs fine in as a scheduled task as
of last week in that Windows-2000 server.  Something might have
changed during the weekend or on Monday.

Last time (years ago) when I had this same problem, I fixed the
problem by making sure I used the same user account that I used to
startup the server to run the scheduled task (something to do with
allowing the scheduled task to get access to the user desktop).  This
also might or might not have to do with the capitalization of the user
name (I might have confused this with the use of RSH in Unix); I use
exactly the same capitalization for startup logon and scheduled task
any way to play safe.  This works -- at least up to last week.
Somehow, this doesn't work now for that Windows-2000 server.

I can re-create this problem by scheduling a simple task like this in
the Windows-2000 server:

   cmd /c dir S:\ > C:\Temp\JayTest.txt

Here, S: is the mapped drive letter.  If I run it through a command
prompt, it saves the file listing of S:\ to a text file.  If I run it
as a scheduled task, it creates an empty file.  The same command works
fine as a scheduled task in the other two servers (Windows 2003).

I have asked around, and no one has changed anything on that server.
Therefore, I really don't know what caused this problem.

The alternative is to use UNC.  But this would mean that I need to
customize the scheduled task for each branch office because the same
drive letter is mapped to different shared folder for each branch
office.  The original idea of using a mapped drive letter is to allow
the same program to run in all different branch offices.  Yes, I can
do this by using a different mean to tell the program where it should
retrieve the info; but I prefer to figure out what goes wrong in that
Windows-2000 server; afterall, the same task works fine in other two
servers.

Thanks in advance for any suggestion.

Jay Chan

I changed the test script a bit to read this:

   cmd /c net use > C:\Temp\JayTest_ShowMapDrives.txt

When I open the JayTest_ShowMapDrives.txt file, I see this:

   Status       Local  Remote                Network
   -------------------------------------------------------------------
   Unavailable  R:     \\MyServer\MyFolderA  Microsoft WindowsNetwork
   Unavailable  S:     \\MyServer\MyFolderB  Microsoft WindowsNetwork

You can see that the status of all the mapped drives are
"Unavailable".  The status should have been either "OK" or
"Disconnected".

Seem like the drive letters are there.  But the scheduled task doesn't
have access to them.  This is odd because the scheduled task is
running the same user account as the one that I use to boot up the
server.

Jay Chan

I finally find some information about this problem. According to an
article "Troubleshooting AT Command Using /k Switch" in
http://support.microsoft.com/support/kb/articles/q142/0/40.asp, the
"Task Scheduler" service should run under "Local System" account.
Unfortunately doing this will cause the scheduled task to lose network
connectivity. This is by design. I guess the fact that my scheduled
task didn't lose network connectivity previously was just by chance
and was not meant to happen.

According to the same article, there is one way to get around with
this problem. We can run this command inside the scheduled task (but
before it starts using the mapped drive):

net use \\ServerName\ShareName /UomainName\UserName Password

I tried this tip, and my scheduled task has no problem getting access
to the mapped drive. Having said this, I decide not to use this tip.
I just don't think this is a good idea to embed the password in a
scheduled task that is in plain text. As I said in my previous
message, I will have to pass the UNC as a parameter to the scheduled
task instead of asking the scheduled task to use a mapped drive
letter.

Thanks for Pegasus in setting me straight.

Jay Chan

 

[Pegasus \(MVP\)]

"powdered_toast_man" <[email protected]>
wrote in
message
:
Also don't forget if the job connects to another machine you may
need to
add
the user/ group 'logon as batch job' rights (server side). Control
Panel|Admin Tools|Local Security Policy\Local Policies\User Rights
Assignments
"Log on as a batch job"
--
Regards,
Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect
Thanks to you both. I actually got it to work - feel a bit stupid
about
this but noticed that I had left the "$" out of the unc path (duh.)
I'll
be
back if that wasn't the problem (I'll know tomorrow morning as these
are
scheduledto run overnight.)
Thanks for the feedback. It actually leaves me mystified because
I cannot reconcile it with this phrase from your initial post: "When
I log onto server A and run the batch file it works; when I use
the taskscheduler to run the batch it fails."

I am in a similar situation as the original poster. A task cannot get
access to a mapped drive if I run it as a scheduled task in a
Windows-2000 server. On the other hand, the task can get access to
the mapped drive if I run it interactively through the command
prompt. Both cases are running under the same user account and
password.

The exactly same task runs perfectly fine as a scheduled task in other
two servers (Wndows 2003). And it runs fine in as a scheduled task as
of last week in that Windows-2000 server. Something might have
changed during the weekend or on Monday.

Last time (years ago) when I had this same problem, I fixed the
problem by making sure I used the same user account that I used to
startup the server to run the scheduled task (something to do with
allowing the scheduled task to get access to the user desktop). This
also might or might not have to do with the capitalization of the user
name (I might have confused this with the use of RSH in Unix); I use
exactly the same capitalization for startup logon and scheduled task
any way to play safe. This works -- at least up to last week.
Somehow, this doesn't work now for that Windows-2000 server.

I can re-create this problem by scheduling a simple task like this in
the Windows-2000 server:

cmd /c dir S:\ > C:\Temp\JayTest.txt

Here, S: is the mapped drive letter. If I run it through a command
prompt, it saves the file listing of S:\ to a text file. If I run it
as a scheduled task, it creates an empty file. The same command works
fine as a scheduled task in the other two servers (Windows 2003).

I have asked around, and no one has changed anything on that server.
Therefore, I really don't know what caused this problem.

The alternative is to use UNC. But this would mean that I need to
customize the scheduled task for each branch office because the same
drive letter is mapped to different shared folder for each branch
office. The original idea of using a mapped drive letter is to allow
the same program to run in all different branch offices. Yes, I can
do this by using a different mean to tell the program where it should
retrieve the info; but I prefer to figure out what goes wrong in that
Windows-2000 server; afterall, the same task works fine in other two
servers.

Thanks in advance for any suggestion.

Jay Chan

I changed the test script a bit to read this:

cmd /c net use > C:\Temp\JayTest_ShowMapDrives.txt

When I open the JayTest_ShowMapDrives.txt file, I see this:

Status Local Remote Network
-------------------------------------------------------------------
Unavailable R: \\MyServer\MyFolderA Microsoft Windows Network
Unavailable S: \\MyServer\MyFolderB Microsoft Windows Network

You can see that the status of all the mapped drives are
"Unavailable". The status should have been either "OK" or
"Disconnected".

Seem like the drive letters are there. But the scheduled task doesn't
have access to them. This is odd because the scheduled task is
running the same user account as the one that I use to boot up the
server.

Jay Chan

I finally find some information about this problem. According to an
article "Troubleshooting AT Command Using /k Switch" in
http://support.microsoft.com/support/kb/articles/q142/0/40.asp, the
"Task Scheduler" service should run under "Local System" account.
Unfortunately doing this will cause the scheduled task to lose network
connectivity. This is by design. I guess the fact that my scheduled
task didn't lose network connectivity previously was just by chance
and was not meant to happen.

According to the same article, there is one way to get around with
this problem. We can run this command inside the scheduled task (but
before it starts using the mapped drive):

net use \\ServerName\ShareName /UomainName\UserName Password

I tried this tip, and my scheduled task has no problem getting access
to the mapped drive. Having said this, I decide not to use this tip.
I just don't think this is a good idea to embed the password in a
scheduled task that is in plain text. As I said in my previous
message, I will have to pass the UNC as a parameter to the scheduled
task instead of asking the scheduled task to use a mapped drive
letter.

Thanks for Pegasus in setting me straight.

Jay Chan

======================

Thanks for the feedback.