Re: script will not run as a scheduled service unless logged on

Al, thanks for your reply. See my responses below:

"Al Dunbar" <AlanDrub@xxxxxxxxxxxxxxxxxxx> wrote in message
news:OnmvRZrvHHA.4244@xxxxxxxxxxxxxxxxxxxxxxx

"C.W." <c.w@xxxxxxxxxx> wrote in message
news:euh$xwkvHHA.3500@xxxxxxxxxxxxxxxxxxxxxxx
Hi

I have run into a really bizzare issue. I have created a vbscript that
refreshes pivot tables and database queries on excel spreadsheets. I can
run the script interactively, and I can run the script as a scheduled job
so long I am logged on.

OK, at this point, when you say *you* are logged on, what account are you
logged into? And below you say the scheduled task is configured to use the
domain administrator's account - is this the case in the scenario you
describe above?

I am logged into the domain administrator's account, and the scheduled task
is configured to run under that account.


BTW, is there any difference between calling
CreateObject vs WScript.CreateObject in a vbscript?

I believe that there is a difference, and recall it was discussed here
years ago, but for the life of me I do not remember the details. I think
the two functions attache slightly different meanings to the parameters
provided.

The command line of the script is
cscript "J:\Reports\SS Report Engine\GenerateReports.vbs" 0 1

I assume that the .vbs accepts and processes the two parameters, zero and
one. Are you sure that these are being passed to the script when it runs
as a scheduled job?


They are passed successfully when I run the script from command line or when
I kick off the script from task scheduler manually.

The job is set up in the task scheduler to use the domain administrator
account. The task scheduler log does not report the detail of the error.
From what I can see the script failed to run completely as I create an
entry to the application log on the first line of the script. The exit
code is 1.

depending on how long the job takes to run, you might need to specify a
longer than default timeout parameter to cscript.

If it runs successfully from command line and from task scheduler
(manually), I wouldn't have thought timeout should be a problem.


I have already given Batch user full access to cscript.exe,

There is no reason in the world why this would be necessary or useful. You
only need read and execute permission. But, what do you mean by the "batch
user" - is this the domain admin account?


I know it shouldn't be necessary. However, I was deperate and was trying
everything possible. Batch is a security principle on windows 2003.

and I have also assigned the domain administrator account right to log
on as a batch job in local security policy -> user right assignment.

I would have thought that an administrator would already have all the
rights necessary to do virtually anything.

Administrator is not set up to log on as a batch job in windows 2003. It
doesn't mean it couldn't. However, I assigned the additional permission
anyway, not that it made any difference.


Anyway, if your script ran up to the point where it created the
application log entry before you made these permissions/rights changes,
then I would suggest they were not necessary.

The script logs into the Application Log successfully when I run it from
command line or kicked off manually in task scheduler. Nothing happens when
I log off. I don't think anything actually gets run at all.

So, what else does your script actually do, in general terms. Perhaps
something it does can only be done in an interactive environment.

/Al

The script simply uses ADODB object to retrieve report parameters, and then
update excel reports with these parameters using Excel.Application object.
Excel in turn calls Microsoft Query to refresh pivot tables and database
queries embedded in excel reports.


.