> "Al Dunbar" <AlanDrub[ at ]hotmail.com.nospaam> wrote in
> news:#bUtIZwvHHA.3500[ at ]TK2MSFTNGP04.phx.gbl:
>
>> "C.W." <c.w[ at ]nospam.com> wrote in message
>> news:OdaX1WvvHHA.3720[ at ]TK2MSFTNGP02.phx.gbl...
>>> Al, thanks for your reply. See my responses below:
>>>
>>> "Al Dunbar" <AlanDrub[ at ]hotmail.com.nospaam> wrote in message
>>> news:OnmvRZrvHHA.4244[ at ]TK2MSFTNGP04.phx.gbl...
>>>>
>>>> "C.W." <c.w[ at ]nospam.com> wrote in message
>>>> news:euh$xwkvHHA.3500[ at ]TK2MSFTNGP05.phx.gbl...
>>>>> 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.
>>
>> Agreed, but it seemed a possibility worth considering.
>>
>>>>> 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
>>
>> Logs into it? or creates a log entry?
>>
>>> 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.
>>
>> Now you are saying that when your script is run by the scheduler when
>> you are not logged in, that it does not even create the log entry? I
>> had understood otherwise from what you said previously.
>>
>>>> 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.
>>
>> Unfortunately, I'm stumped at this point. Have you been able to run
>> simple .cmd scripts and .vbs scripts as scheduled jobs, both while
>> logged in and while not logged in? I'd try to rule out some issue with
>> your current script itself.
>>
>> /Al
>>
>>
>>
>
> Just a thought - does the script do anything that relies on a mapped
> drive or similar resource (which won't be there when you are not logged
> in)? Make sure you use UNC paths, or create the drive mapping before it
> is used.
> Also, things such as environment variables like PATH may not be set the
> same as when you are logged in.