haai

Hi

The problem that I have is a little difficult to explain, but I'll try
as good as possible ;-)

First, I create a scheduled task with a WMI-script on all computers in
the network. A little code I use for it:
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & txtcomp & "\root\cimv2")
Set objNewJob = objWMIService.Get("Win32_ScheduledJob")
errJobCreated = objNewJob.Create ....

This works fine, and the scheduled script is listed in the "scheduled
tasks" of windows.

The scheduled task is \\myserver\myshare\myscript.vbs

At the second step, when the scheduled script will be executed, I get
an error (see below). The strange thing is, I only get this error on
some computers. On other computers in the network it works perfect.
There is no difference between W2K and XP.

Another strange thing: when I execute the script manually on the
computers where it fails, the script works fine! Also, when the task is
scheduled, and I change the "run as"-field in the properties to a
domain account, it works fine.

The problem is something with the "system"-account I think. (But it is
strange it works on some computers fine, and on others not).

Anyone a suggestion?

Thx in advance
Mathias


The error is raised at the following line:

Set objexplorer = wscript.CreateObject("InternetExplorer.Application ",
"objexplorer_")

The error is "ActiveX component can't create object". With an error
resume next, the next (logical) error is "object required".

james

I got this problem too. You have to check if the account you are running the
service with has a password set.
The account you used (local or domain) could have been created before
presence of any GPOs in the domain. These GPOs sometimes dictate the minimum
level of complexity of passwords usable when new users are created. It
definately doesn't like accounts that have no passwords - and this can be a
problem when you use a script to trigger it off.

Try this. execute a manual 'runas' on the target machines and see if it
works.

james

I got this problem too. You have to check if the account you are running the
service with has a password set.
The account you used (local or domain) could have been created before
presence of any GPOs in the domain. These GPOs sometimes dictate the minimum
level of complexity of passwords usable when new users are created. It
definately doesn't like accounts that have no passwords - and this can be a
problem when you use a script to trigger it off.

Try this. execute a manual 'runas' on the target machines and see if it
works.

mathias vissers

"james" <jamescliu@hotmail.com> schreef in bericht
news:egQ5HElVFHA.2420@TK2MSFTNGP12.phx.gbl...


Hi

Thanks for your answer. I have been looking for that. But when I right click
on "my computer" and choose for "manage" --> users & groups: I can't find a
account named "system".

I already tried to add the "system"-named account in the local admin group
so that the account has local admin right, but also that didn't solved my
problem :-(

A manual "runas" works as I said before.

Thanks

Mathias.

manfred braun

Hi,

the scheduled job you've created is in reality an "AT" job. WMI has no
interface to create that, what one calls a "Task Scheduler Job", which would
allow you to specify credentials. The AT job, create by WMI, is running with
"LocalSystem" account and has normally no network rights. I am wondering,
why it works somethimes. This could depend on the fact that the remote
comouter [your \\myserver\] trusts some of your workstation, but not all. If
you run the script interactively, your logged-on credentails are used to
execute the script and to connect to the remote server also. This can
explain, why this works.

Having no public scriptable interface to the Task Scheduler is a real pain
under windows :-(
but the times have changes a bit and there is one.

There is a COM dll, which is part of the "Site Server Resource Kit", this
has a scriptable interface also, but this is not publicly available. There
is a very little know automation interface, published in Technet or MSDN [a
quick search gave me:
http://www.microsoft.com/downloads/details.aspx?FamilyID=601d75e2-f907-4e51-ad88-adb818df1d27&displaylang=en ]
..

As part of the "Windows 2000 Resource Kit", you'll find also "jit.exe" [so
far I remember correctly], which allows to create and change Schdulted task
and also to specify the right permissions.

If you use net, there are some free libraries to interact with the Scheduled
Task COM interface.

No WMI :-(

Hope, this helps.
Best regards,
Manfred Braun

(Private)
Mannheim
Germany

mailto:_manfred.braun_@manfbraun.de
(Remove the anti-spam-underscore to mail me!)

haai

Hi

Thanks for your advice.
Do you know where I can edit the user-rights of the "system"-account?
Maybe I can fix the problem by that?

Mathias.

morten

Hi!

It might work if you execute the script as a user that exists (same user
name and password) on all your servers. The user would need admin rights.

Best regards

Morten

haai

Morten schreef:

user

rights.


Hi

The problem is, in wmi with this method:
Set objNewJob = objWMIService.Get("Win32_Sched*uledJob")
errJobCreated = objNewJob.Create ....

It isn't possible to say which user has to execute the script.
The alternative of Manfred Braun is ok, with the dll-files, but than I
have to run the command with wshshell.exec, and that gives some
problems :-(

Best regards

Mathias

manfred braun

Hi,

thats not possible! I am not too sure, but I can imagine, that setting a
null-session-share on the machine, which hosts your script, would help. But
if you create a scheduled task remotely, why not copying the script to
execute also onto the machine, which executes your task?

As I mentioned, there is also, the "JT.EXE" from the Resource Kit, which
could create the Scheduled Task on the target machine, it can also set the
credentials for that task.

Here a sample output from "JT.EXE" from my box:


[TRACE] Enumerating jobs and queues
AutoStart.job
Jo.job
m1--AllProfiles.job
NetMsg.job
PseudoCreateUserProfile1.job
RunAsMB.job
W2KP-E-OfflineBackup-20050531.job
xxcopy.job

May be, that helps.

I personally would really like to see a WMI class for the "Scheduled Task"
.... ;-)
even better would be a new solution, because the Task Scheduler is not
cluster-enabled :-(

Best regards,
Manfred

jim vierra

WHat's wrong with this - It just happens to be called "ScheduleJob instead of ScheduleTask.

Function ScheduleJob( strJobName,strCommand, strTime,strRepeat) 'As Boolean
' call WMI to scedule this job. ,"********012500.000000-420", WMI format
strComputer = "."
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonat e}!\\" & strComputer & "\root\cimv2")
Set objNewJob = objWMIService.Get("Win32_ScheduledJob")
errJobCreated = objNewJob.Create(strCommand,strTime,True , 4, strRepeat, True, JobId)
If errJobCreated <> 0 Then
Select Case errJobCreated
Case 1 : strErr = "Incorrect function called or unknown function called."
Case 10 : strErr = "The environment is incorrect."
Case &H8009000f: strErr = "General Access denied "
End Select
LogMsg "Error on task creation - " & strErr
ScheduleJob = False
Else
LogMsg "Job created:strJobName"
ScheduleJob = True
End If
End Function


--
Jim Vierra