Scheduled Task running as SYSTEM fails with logged-on user

[Guest]

Using Windows XP SP2 in a 2003 Native domain. I have configured a scheduled
task to run on each of the XP clients. This task triggers a VBScript which
uses WMI to connect to the event log provider, and save the Security event
log to a .EVT file on the local hard drive.

This task is configured to run under the SYSTEM account and was created
using the SCHTASKS.EXE command.

What I've found, is that the task runs when there is no user logged in. If
an Administrator logs in to the machine, the task runs. If a normal user,
without privileges to the Security Log is logged on to the machine, the task
fails.

By echoing extra commands from the vbscript file, it appears to be
connecting okay to \root\cimv2 with
{impersonationLevel=impersonate,(Security,Backup)}:\\.\root\cimv2 , then
obtaining a collection of security logs via ExecuteQuery. But, when I then
try to iterate "for each Log in colLogs" the script crashes citing an access
denied message.

Is there a trick to running this under the SYSTEM account that I don't know
about? Any help would be greatly appreciated.

 

[Steven L Umbach]

I don't know for sure what is going on but you might also try using the AT
command to schedule the task if it is time based and not event based. You
may need to use the /interactive switch also to get it to work the way you
want.

Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;313565 --- AT
command

 

[Guest]

Thanks for the tip. I've tried running it with AT, but it still gives an
error from WMI. This vbscript works correctly if no one is logged on, or if
an Administrator is logged on, but with a normal user logged into the console
it still fails. If I used schtasks.exe and assign an Administrative user
with a password for the task credentials, it works correctly regardless of
who's logged on interactively - this seems specific to running under the "NT
AUTHORITY\SYSTEM" account.

The "old" method I had for doing this was a Perl script which uses Perl's
Win32:EventLog rather than WMI. That method still works correctly and I may
need to revert to using it rather than VBScript/WMI. The old Resource Kit
utility "dumpel" is also working correctly, but I'd really like to save a
..EVT-formatted copy of the log.

Has anyone else encountered this problem?

 

[Guest]

Based on this and other tests I've run, it appears to be an issue in WMI, not
necessarily in the Task Scheduler or in VBScript. WMI is behaving
differently depending on which user is logged in interactively, but only when
running the task as NT AUTHORITY\SYSTEM. Is WMI having a problem because it
cannot resolve SYSTEM?