Windows 2000 scheduled task can not access shared drive

  • Thread starter Thread starter powdered_toast_man
  • Start date Start date
P

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?
 
"powdered_toast_man" <powderedtoastman@discussions.microsoft.com> wrote in
message news:81D01B94-2218-45CA-99C3-8E2883898004@microsoft.com...
> 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".
 
"Pegasus (MVP)" wrote:

>
> "powdered_toast_man" <powderedtoastman@discussions.microsoft.com> wrote in
> message news:81D01B94-2218-45CA-99C3-8E2883898004@microsoft.com...
> > 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".
>
>
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.
 
"powdered_toast_man" <powderedtoastman@discussions.microsoft.com> wrote in
message news:A7938743-8FE2-4ED4-9A1F-EBC15CFB8574@microsoft.com...
>
>
> "Pegasus (MVP)" wrote:
>
>>
>> "powdered_toast_man" <powderedtoastman@discussions.microsoft.com> wrote
>> in
>> message news:81D01B94-2218-45CA-99C3-8E2883898004@microsoft.com...
>> > 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".
>>
>>
> 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
 
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
 
"Dave Patrick" wrote:

> 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.)
 
"powdered_toast_man" <powderedtoastman@discussions.microsoft.com> wrote in
message news:0CF63EA6-765B-4F6E-A6A6-9C840410DB73@microsoft.com...
>
>
> "Dave Patrick" wrote:
>
>> 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."
 
Pegasus (MVP) wrote:

> "powdered_toast_man" <powderedtoastman@discussions.microsoft.com> wrote in
> message news:0CF63EA6-765B-4F6E-A6A6-9C840410DB73@microsoft.com...
>
>>
>>"Dave Patrick" wrote:
>>
>>
>>>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.
 
On May 5, 1:06 am, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
> "powdered_toast_man" <powderedtoast...@discussions.microsoft.com> wrote in
> messagenews:0CF63EA6-765B-4F6E-A6A6-9C840410DB73@microsoft.com...
>
>
>
>
>
>
>
> > "Dave Patrick" wrote:
>
> >> 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
 
On Jun 3, 2:50 pm, Jay Chan <jaykc...@hotmail.com> wrote:
> On May 5, 1:06 am, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
>
>
>
>
>
> > "powdered_toast_man" <powderedtoast...@discussions.microsoft.com> wrote in
> > messagenews:0CF63EA6-765B-4F6E-A6A6-9C840410DB73@microsoft.com...
>
> > > "Dave Patrick" wrote:
>
> > >> 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
 
"Jay Chan" <jaykchan@hotmail.com> wrote in message
news:a95c9932-5af5-4572-95a2-317fe5602aae@y38g2000hsy.googlegroups.com...
On Jun 3, 2:50 pm, Jay Chan <jaykc...@hotmail.com> wrote:
> On May 5, 1:06 am, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
>
>
>
>
>
> > "powdered_toast_man" <powderedtoast...@discussions.microsoft.com> wrote
> > in
> > messagenews:0CF63EA6-765B-4F6E-A6A6-9C840410DB73@microsoft.com...
>
> > > "Dave Patrick" wrote:
>
> > >> 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.
 
On Jun 3, 3:59 pm, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
> "Jay Chan" <jaykc...@hotmail.com> wrote in message
>
> news:a95c9932-5af5-4572-95a2-317fe5602aae@y38g2000hsy.googlegroups.com...
> On Jun 3, 2:50 pm, Jay Chan <jaykc...@hotmail.com> wrote:
>
>
>
>
>
> > On May 5, 1:06 am, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
>
> > > "powdered_toast_man" <powderedtoast...@discussions.microsoft.com> wrote
> > > in
> > > messagenews:0CF63EA6-765B-4F6E-A6A6-9C840410DB73@microsoft.com...
>
> > > > "Dave Patrick" wrote:
>
> > > >> 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.

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
 
On Jun 3, 3:42 pm, Jay Chan <jaykc...@hotmail.com> wrote:
> On Jun 3, 2:50 pm, Jay Chan <jaykc...@hotmail.com> wrote:
>
>
>
>
>
> > On May 5, 1:06 am, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
>
> > > "powdered_toast_man" <powderedtoast...@discussions.microsoft.com> wrote in
> > > messagenews:0CF63EA6-765B-4F6E-A6A6-9C840410DB73@microsoft.com...
>
> > > > "Dave Patrick" wrote:
>
> > > >> 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 /U:DomainName\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
 
"Jay Chan" <jaykchan@hotmail.com> wrote in message
news:aab2f1cf-5ead-4acb-9cf1-efcd0d755a94@26g2000hsk.googlegroups.com...
On Jun 3, 3:42 pm, Jay Chan <jaykc...@hotmail.com> wrote:
> On Jun 3, 2:50 pm, Jay Chan <jaykc...@hotmail.com> wrote:
>
>
>
>
>
> > On May 5, 1:06 am, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
>
> > > "powdered_toast_man" <powderedtoast...@discussions.microsoft.com>
> > > wrote in
> > > messagenews:0CF63EA6-765B-4F6E-A6A6-9C840410DB73@microsoft.com...
>
> > > > "Dave Patrick" wrote:
>
> > > >> 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 /U:DomainName\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.
 
Back
Top