Problems with executing scheduled script

H

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".
 
J

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.
 
J

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.
 
M

Mathias Vissers

james said:
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.

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.
Also, when the task is scheduled, and I change the "run as"-field in the
properties to a domain account, it works fine.")

Thanks

Mathias.
 
M

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/...e2-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:[email protected]
(Remove the anti-spam-underscore to mail me!)
 
H

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.
 
M

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
 
H

haai

Morten schreef:
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

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
 
M

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
 
J

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=impersonate}!\\" & 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

Manfred Braun said:
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

haai said:
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.
 
M

Manfred Braun

Hi,

thats just the name MS gave to the wmi-class, which implements this job, this describes the usual "AT" job, not jobs from the TaskScheduler.

BTW, in line:

LogMsg "Job created:strJobName"

I think, this should possibly mean

LogMsg "Job created:" & strJobName

??

Best regards,
Manfred

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=impersonate}!\\" & 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

Manfred Braun said:
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

haai said:
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.
 
J

Jim Vierra

Look in Task scheduler and it will be there. You can query fr the jobin the scheduler and manage it.

--
Jim Vierra

Hi,

thats just the name MS gave to the wmi-class, which implements this job, this describes the usual "AT" job, not jobs from the TaskScheduler.

BTW, in line:

LogMsg "Job created:strJobName"

I think, this should possibly mean

LogMsg "Job created:" & strJobName

??

Best regards,
Manfred

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=impersonate}!\\" & 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

Manfred Braun said:
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

haai said:
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.
 
M

Manfred Braun

Hi,

behind the scene, it is much more complicated. After the "Scheduled task" have been introduced, MS would ensure compatibility with the old and long existing AT interface. So the new engine, represented by the "Task Scheduler Service" has to execute the "old" AT jobs also. You can create AT jobs with the commandline AT command and you'll see this jobs in the tasklist of the "Scheduled Task", but these jobs are executed under the service account [which is normally LocalSystem] and they do not have any users to impersonate to.

You can create a "Scheduled Task" with the taskschedulers GUI and you'll see both jobs, but that one, you've created with the GUI can have assigned an user to which the taskscheduler impersonates the job if it starts. This is not the case for the jobs created by the AT interface or by WMI. If you've created a job with the GUI, go to the commandline and issue an AT command. You will be surprised, but the jobs created with the GUI are NOT there!

On the other hand, if you use the taskschedulers GUI and you see an AT job, you can apply credentials. This essentially will convert the job from a AT job visible with the AT command and executed with LocalSystem, to a new schedulted task, which could have credentials and is finally only visible in the GUI.

Hope, this helps.

Best regards,
Manfred

Look in Task scheduler and it will be there. You can query fr the jobin the scheduler and manage it.

--
Jim Vierra

Hi,

thats just the name MS gave to the wmi-class, which implements this job, this describes the usual "AT" job, not jobs from the TaskScheduler.

BTW, in line:

LogMsg "Job created:strJobName"

I think, this should possibly mean

LogMsg "Job created:" & strJobName

??

Best regards,
Manfred

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=impersonate}!\\" & 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

Manfred Braun said:
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

haai said:
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.
 
J

Jim Vierra

Your right - sorry. I was in the middle of changing the message interface.


The job is listed in scheduler. It is owned by "LocalSystem" This is a security measure to prevent network tasks from gaining admin privileges.

The Scheduler service can get jobs from the "At" command which runs as "LocalSystem" when it creates a job. The difference is that WMI can't see jobs created by the Schedule Wizard and neither can "At". Change the account that the scheduler runs under and the scheduler can see everything. Cahnge the account WMI runs under and WMI can see everything.

Don't make the change though. It will create a hole in the security.
--
Jim Vierra

Hi,

thats just the name MS gave to the wmi-class, which implements this job, this describes the usual "AT" job, not jobs from the TaskScheduler.

BTW, in line:

LogMsg "Job created:strJobName"

I think, this should possibly mean

LogMsg "Job created:" & strJobName

??

Best regards,
Manfred

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=impersonate}!\\" & 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

Manfred Braun said:
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

haai said:
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.
 
J

Jim Vierra

The major difference is only what get into or stays in the registry. The scheduler still runs all of the jobs. I believe it's only ownership that is different.


--
Jim Vierra

Hi,

behind the scene, it is much more complicated. After the "Scheduled task" have been introduced, MS would ensure compatibility with the old and long existing AT interface. So the new engine, represented by the "Task Scheduler Service" has to execute the "old" AT jobs also. You can create AT jobs with the commandline AT command and you'll see this jobs in the tasklist of the "Scheduled Task", but these jobs are executed under the service account [which is normally LocalSystem] and they do not have any users to impersonate to.

You can create a "Scheduled Task" with the taskschedulers GUI and you'll see both jobs, but that one, you've created with the GUI can have assigned an user to which the taskscheduler impersonates the job if it starts. This is not the case for the jobs created by the AT interface or by WMI. If you've created a job with the GUI, go to the commandline and issue an AT command. You will be surprised, but the jobs created with the GUI are NOT there!

On the other hand, if you use the taskschedulers GUI and you see an AT job, you can apply credentials. This essentially will convert the job from a AT job visible with the AT command and executed with LocalSystem, to a new schedulted task, which could have credentials and is finally only visible in the GUI.

Hope, this helps.

Best regards,
Manfred

Look in Task scheduler and it will be there. You can query fr the jobin the scheduler and manage it.

--
Jim Vierra

Hi,

thats just the name MS gave to the wmi-class, which implements this job, this describes the usual "AT" job, not jobs from the TaskScheduler.

BTW, in line:

LogMsg "Job created:strJobName"

I think, this should possibly mean

LogMsg "Job created:" & strJobName

??

Best regards,
Manfred

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=impersonate}!\\" & 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

Manfred Braun said:
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

haai said:
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.
 
M

Manfred Braun

Hi Jim,

finally, it looks like, we see it the same way!
And both interfaces have their pros and cons. AT is just simply remotable by the commandline!

Anyway,
best regards,
Manfred
The major difference is only what get into or stays in the registry. The scheduler still runs all of the jobs. I believe it's only ownership that is different.


--
Jim Vierra

Hi,

behind the scene, it is much more complicated. After the "Scheduled task" have been introduced, MS would ensure compatibility with the old and long existing AT interface. So the new engine, represented by the "Task Scheduler Service" has to execute the "old" AT jobs also. You can create AT jobs with the commandline AT command and you'll see this jobs in the tasklist of the "Scheduled Task", but these jobs are executed under the service account [which is normally LocalSystem] and they do not have any users to impersonate to.

You can create a "Scheduled Task" with the taskschedulers GUI and you'll see both jobs, but that one, you've created with the GUI can have assigned an user to which the taskscheduler impersonates the job if it starts. This is not the case for the jobs created by the AT interface or by WMI. If you've created a job with the GUI, go to the commandline and issue an AT command. You will be surprised, but the jobs created with the GUI are NOT there!

On the other hand, if you use the taskschedulers GUI and you see an AT job, you can apply credentials. This essentially will convert the job from a AT job visible with the AT command and executed with LocalSystem, to a new schedulted task, which could have credentials and is finally only visible in the GUI.

Hope, this helps.

Best regards,
Manfred

Look in Task scheduler and it will be there. You can query fr the jobin the scheduler and manage it.

--
Jim Vierra

Hi,

thats just the name MS gave to the wmi-class, which implements this job, this describes the usual "AT" job, not jobs from the TaskScheduler.

BTW, in line:

LogMsg "Job created:strJobName"

I think, this should possibly mean

LogMsg "Job created:" & strJobName

??

Best regards,
Manfred

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=impersonate}!\\" & 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

Manfred Braun said:
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

haai said:
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.
 
J

Jim Vierra

Sow now that we have beat that dead horse.

Answer this.

WMI can set Win32_Printer.location on XP and not on Windows Server 2003. Why?
It doesn't make sense to have disabled this so why is it disabled?

--
Jim Vierra

Hi Jim,

finally, it looks like, we see it the same way!
And both interfaces have their pros and cons. AT is just simply remotable by the commandline!

Anyway,
best regards,
Manfred
The major difference is only what get into or stays in the registry. The scheduler still runs all of the jobs. I believe it's only ownership that is different.


--
Jim Vierra

Hi,

behind the scene, it is much more complicated. After the "Scheduled task" have been introduced, MS would ensure compatibility with the old and long existing AT interface. So the new engine, represented by the "Task Scheduler Service" has to execute the "old" AT jobs also. You can create AT jobs with the commandline AT command and you'll see this jobs in the tasklist of the "Scheduled Task", but these jobs are executed under the service account [which is normally LocalSystem] and they do not have any users to impersonate to.

You can create a "Scheduled Task" with the taskschedulers GUI and you'll see both jobs, but that one, you've created with the GUI can have assigned an user to which the taskscheduler impersonates the job if it starts. This is not the case for the jobs created by the AT interface or by WMI. If you've created a job with the GUI, go to the commandline and issue an AT command. You will be surprised, but the jobs created with the GUI are NOT there!

On the other hand, if you use the taskschedulers GUI and you see an AT job, you can apply credentials. This essentially will convert the job from a AT job visible with the AT command and executed with LocalSystem, to a new schedulted task, which could have credentials and is finally only visible in the GUI.

Hope, this helps.

Best regards,
Manfred

Look in Task scheduler and it will be there. You can query fr the jobin the scheduler and manage it.

--
Jim Vierra

Hi,

thats just the name MS gave to the wmi-class, which implements this job, this describes the usual "AT" job, not jobs from the TaskScheduler.

BTW, in line:

LogMsg "Job created:strJobName"

I think, this should possibly mean

LogMsg "Job created:" & strJobName

??

Best regards,
Manfred

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=impersonate}!\\" & 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

Manfred Braun said:
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

haai said:
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.
 
J

Jim Vierra

So who has a COM wrapper for mstask.dll?

I set out to build one but VB Express doesn't have support and I don't have
VB6 loaded at this time. It's fairly straight forward. Only a half dozen
interfaces to set up and it could be callable from scripts. I don't
understand why MS didn't build it.

--
Jim Vierra


Morten schreef:
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

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
 
M

Manfred Braun

Jim,

have you looked at google?? ;-)

I do not know excactly about membership on http://www.codeproject.com, but
there, I found the following references:

http://www.codeproject.com/csharp/taskschedulerlibrary.asp
http://www.codeproject.com/csharp/tsnewlib.asp

"Naturally", they offer the source too. It's not VB, it's C#, but you can
just use the libraries. I personally find it a pain to maintain my own class
library - which is only needed for my admin jobs !! - and to have/deploy
this on all boxes, I ever work with.

The taskscheduler is not well supported by MS and possibly more importent,
it is not "cluster-aware" !!!!!! Wether WMi nor CLR do have any support for
this :-(

So I can only still repeat my humble opinion [which is already somewhere
within this thread ;-) ], that there should come a new supported solution
.....

Hope, this helps!

Best regards,
Manfred
 
M

Manfred Braun

Hi,

from my point of view, this looks like a bug and not a feature ;-)
It make no sense so.

Regards,
Manfred
Sow now that we have beat that dead horse.

Answer this.

WMI can set Win32_Printer.location on XP and not on Windows Server 2003. Why?
It doesn't make sense to have disabled this so why is it disabled?

--
Jim Vierra

Hi Jim,

finally, it looks like, we see it the same way!
And both interfaces have their pros and cons. AT is just simply remotable by the commandline!

Anyway,
best regards,
Manfred
The major difference is only what get into or stays in the registry. The scheduler still runs all of the jobs. I believe it's only ownership that is different.


--
Jim Vierra

Hi,

behind the scene, it is much more complicated. After the "Scheduled task" have been introduced, MS would ensure compatibility with the old and long existing AT interface. So the new engine, represented by the "Task Scheduler Service" has to execute the "old" AT jobs also. You can create AT jobs with the commandline AT command and you'll see this jobs in the tasklist of the "Scheduled Task", but these jobs are executed under the service account [which is normally LocalSystem] and they do not have any users to impersonate to.

You can create a "Scheduled Task" with the taskschedulers GUI and you'll see both jobs, but that one, you've created with the GUI can have assigned an user to which the taskscheduler impersonates the job if it starts. This is not the case for the jobs created by the AT interface or by WMI. If you've created a job with the GUI, go to the commandline and issue an AT command. You will be surprised, but the jobs created with the GUI are NOT there!

On the other hand, if you use the taskschedulers GUI and you see an AT job, you can apply credentials. This essentially will convert the job from a AT job visible with the AT command and executed with LocalSystem, to a new schedulted task, which could have credentials and is finally only visible in the GUI.

Hope, this helps.

Best regards,
Manfred

Look in Task scheduler and it will be there. You can query fr the jobin the scheduler and manage it.

--
Jim Vierra

Hi,

thats just the name MS gave to the wmi-class, which implements this job, this describes the usual "AT" job, not jobs from the TaskScheduler.

BTW, in line:

LogMsg "Job created:strJobName"

I think, this should possibly mean

LogMsg "Job created:" & strJobName

??

Best regards,
Manfred

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=impersonate}!\\" & 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

Manfred Braun said:
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

haai said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top