Scheduler "Path not found" err

This is really bugging me....

I've written a vbscript to copy some files round the network.

The vbs file works fine when I run it maually but when I run it under Task
Scheduler it fails to retrieve the remote files. The vb err I'm trapping is
Err 76 "Path not found".

Here's what really bugs me:

1. I'm using UNC paths in the vbs so no issues with mapped drives and logons.
2. Schedueler runs under the Local System Account but I have specifically
set the tasks properties to use another domain account (I also changed
scheduler to use the same domain account).
3. Logging in with the tasks domain account, the vbs runs fine manually, but
not from scheduler.

The scheduler log reports the error as "Invalid working directory...The
system can not find the file specified" which I assume is just schedulers
version of the vb err "path not found"

Any ideas????


--
Steve Morgan
MCDBA
Production DBA

Michael
Fri Nov 05 13:30:06 CST 2004

> The scheduler log reports the error as "Invalid working
> directory...The system can not find the file specified" which I
> assume is just schedulers version of the vb err "path not found"

In the definition of the task, what is 'Start in' set to?

--
Michael Harris
Microsoft.MVP.Scripting

SteveMorgan
Mon Nov 08 03:49:04 CST 2004

Hi Micheal

The task is set to start in CScript (I've tried WScript as well but the same
problems occur).

The task runs ok (the vbs produces a couple of logs successfully proving
that its actually being run) but the err traps in the vvbs always pick up the
"Path not found" err.

Steve


"Michael Harris (MVP)" wrote:

> > The scheduler log reports the error as "Invalid working
> > directory...The system can not find the file specified" which I
> > assume is just schedulers version of the vb err "path not found"
>
> In the definition of the task, what is 'Start in' set to?
>
> --
> Michael Harris
> Microsoft.MVP.Scripting
>
>

SteveMorgan
Mon Nov 08 05:25:01 CST 2004

Have tried 2 more things.

First created a .cmd file containg an XCOPY command. Same symptons as before
- manual run was fine but failed under scheduler.

Then tried running both the XCOPY cmd file and the origional vbscript using
the AT API rather than the scheduler gui with the same errs as before.

Reading around technet MS state that jobs running under AT scheduler are run
under the local Ststem Account and this can't be changed. As I got the same
errs from AT and the Scheduler GUI I'm wondering if the scheduler GUI is
failing to use the domain account I applied.

Is there an easy way to capture the user info during exec? Bit Like the SET
dos command?

Steve


"Michael Harris (MVP)" wrote:

> > The scheduler log reports the error as "Invalid working
> > directory...The system can not find the file specified" which I
> > assume is just schedulers version of the vb err "path not found"
>
> In the definition of the task, what is 'Start in' set to?
>
> --
> Michael Harris
> Microsoft.MVP.Scripting
>
>

Michael
Mon Nov 08 10:36:57 CST 2004

> The task is set to start in CScript (I've tried WScript as well but
> the same problems occur).

The task has input boxes for 'Run: ...' and 'Start in: ...'. You are
describing the Run value (i.e., the commandline/arguments the job executes)
and I asked about the Start in value (what to establish as the working
directory for the job).

If the 'Start in' directory path is invalid or otherwise unusable (as
implied by the entry in the scheduler log) and your *.vbs script depends on
that being the active working directory for folder/file access, then that
would explain the trapped 'path not found' errors in your script.

--
Michael Harris
Microsoft.MVP.Scripting

Michael
Mon Nov 08 18:55:29 CST 2004

> Reading around technet MS state that jobs running under AT scheduler
> are run under the local Ststem Account and this can't be changed. As
> I got the same errs from AT and the Scheduler GUI I'm wondering if
> the scheduler GUI is failing to use the domain account I applied.
>
> Is there an easy way to capture the user info during exec? Bit Like
> the SET dos command?

set net = createObject("wscript.network")
wscript.echo "username:", net.username, "userdomain:", net.userdomain

--
Michael Harris
Microsoft.MVP.Scripting
Sammamish WA US

SteveMorgan
Wed Nov 10 08:47:04 CST 2004

Hi Micheal

Thnx for help so far, here's where I'm at.

The "wscript.network" code has allowed me to trap the user account being
used in my err logs and scheduler is runing the job under the correct domain
account.

The script tries to connect to 2 locations, the first is the destination for
files (defined as a UNC using IP address rather than server name) and this
results in the undocumented err number "-2147023570" (is there a
patern/reasoning behind these undocumented minus err codes?), no err
description.

The following attempted connection to the source (UNC path using IP address)
generates the err 76 "Path not found".

All this only under the Scheduled Task execution which is configured as
follows:

RUN: CScript C:\<dir>\CopyFile.vbs
START IN: CScript
RUN AS: <correct domain account>

What is the START IN property (no metion in win2k help files or in knowledge
base). Should this be "C:\WINNT\system32" as cscript runs under a command
shell?

Any ideas would be greate because at the moment I'm having to kick the vbs
script maually at 5pm then check it the next morning...

Steve


"Michael Harris (MVP)" wrote:

> > Reading around technet MS state that jobs running under AT scheduler
> > are run under the local Ststem Account and this can't be changed. As
> > I got the same errs from AT and the Scheduler GUI I'm wondering if
> > the scheduler GUI is failing to use the domain account I applied.
> >
> > Is there an easy way to capture the user info during exec? Bit Like
> > the SET dos command?
>
> set net = createObject("wscript.network")
> wscript.echo "username:", net.username, "userdomain:", net.userdomain
>
> --
> Michael Harris
> Microsoft.MVP.Scripting
> Sammamish WA US
>

Bob
Wed Nov 10 08:58:57 CST 2004

If you log in as that domain account, can you manually do the things you
want the script to do?

Bob Barrows
Steve Morgan wrote:
> Hi Micheal
>
> Thnx for help so far, here's where I'm at.
>
> The "wscript.network" code has allowed me to trap the user account
> being used in my err logs and scheduler is runing the job under the
> correct domain account.
>
> The script tries to connect to 2 locations, the first is the
> destination for files (defined as a UNC using IP address rather than
> server name) and this results in the undocumented err number
> "-2147023570" (is there a patern/reasoning behind these undocumented
> minus err codes?), no err description.
>
> The following attempted connection to the source (UNC path using IP
> address) generates the err 76 "Path not found".
>
> All this only under the Scheduled Task execution which is configured
> as follows:
>
> RUN: CScript C:\<dir>\CopyFile.vbs
> START IN: CScript
> RUN AS: <correct domain account>
>
> What is the START IN property (no metion in win2k help files or in
> knowledge base). Should this be "C:\WINNT\system32" as cscript runs
> under a command shell?
>
> Any ideas would be greate because at the moment I'm having to kick
> the vbs script maually at 5pm then check it the next morning...
>
> Steve
>
>
> "Michael Harris (MVP)" wrote:
>
>>> Reading around technet MS state that jobs running under AT scheduler
>>> are run under the local Ststem Account and this can't be changed. As
>>> I got the same errs from AT and the Scheduler GUI I'm wondering if
>>> the scheduler GUI is failing to use the domain account I applied.
>>>
>>> Is there an easy way to capture the user info during exec? Bit Like
>>> the SET dos command?
>>
>> set net = createObject("wscript.network")
>> wscript.echo "username:", net.username, "userdomain:", net.userdomain
>>
>> --
>> Michael Harris
>> Microsoft.MVP.Scripting
>> Sammamish WA US

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

Michael
Wed Nov 10 16:38:53 CST 2004

> The "wscript.network" code has allowed me to trap the user account
> being used in my err logs and scheduler is runing the job under the
> correct domain account.

If that domain account has no share access permissions to the
\\server\sharename share point (as opposed to being granted NTFS permissions
on the folder path being shared), then any FSO access via a UNC path for
that share will result in a path not found error.

I've seen this problem here at work with 'service accounts' created/used
specifically for batch processes where the service account is not a member
of any standard, default domain group, not even 'All Domain Users'. If the
service account has been given access to a given share, it appears to that
account as if the UNC path does not even exit.

--
Michael Harris
Microsoft.MVP.Scripting

Michael
Wed Nov 10 17:47:51 CST 2004

> ... If the service account has been given

If the service account has *NOT* been given

> access to a given share, it appears to that account as if the UNC
> path does not even exist.

--
Michael Harris
Microsoft.MVP.Scripting
Sammamish WA US