none
Permissions required to run: ExecNotificationQueryAsync RRS feed

  • Question

  • This is a VBScript program that is failing to run as an unprivileged user via Task Scheduler. I'm trying to get the following bit of code to work on a Windows Server 2016 Domain Controller:

    Set objWMIServiceRoot = GetObject("WinMgmts:\\.\root\cimv2")
    Set objSink = WScript.CreateObject("WbemScripting.SWbemSink","objSink_")
    	objWMIServiceRoot.ExecNotificationQueryAsync objSink, "SELECT * FROM __InstanceDeletionEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'"

    It fails at:

    ExecNotificationQueryAsync

    With the error:
    -2147217400
    Invalid parameter

    This works fine when I run the task as an administrator but I do not want the program to have administrative rights.

    Any suggestions?
    Thanks!


    • Edited by DJX995 Thursday, November 9, 2017 8:27 PM
    • Moved by Bill_Stewart Thursday, January 25, 2018 10:16 PM This is not "fix/debug/rewrite my script for me" forum
    Thursday, November 9, 2017 2:50 PM

All replies

  • Only Administrators can create instances in WMI.

    This should work when run as logged on user.

    wql = "SELECT * FROM __InstanceDeletionEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'"
    Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
    Set colMonitorProcess = objWMIService.ExecNotificationQuery(wql) 
    WScript.Echo "Waiting for process to be terminated ..."
    While True
    	Set objLatestEvent = colMonitorProcess.NextEvent
    	Wscript.Echo VbCrLf & "Process Name: " & objLatestEvent.TargetInstance.Name
    	Wscript.Echo "Process ID: " & objLatestEvent.TargetInstance.ProcessId
    	WScript.Echo "Time: " & Now
    Wend

    The output will have to be directed to a file.  It must be started with CScript and not by other means.


    \_(ツ)_/

    Thursday, November 9, 2017 8:12 PM
  • My script is a lot more complex than just the code I posted and this section has to run asynchronously as I have two loops that need to be run at the same time.

    Here is more to give you a better idea:

    Set objWMIServiceWin32Process = GetObject("WinMgmts:\\.\root\cimv2:Win32_Process")
        objWMIServiceWin32Process.Create strCmd1, Null, Null, intID1
        objWMIServiceWin32Process.Create strCmd2, Null, Null, intID2

    Set objWMIServiceRoot = GetObject("WinMgmts:\\.\root\cimv2")
    Set objSink = WScript.CreateObject("WbemScripting.SWbemSink","objSink_")
        objWMIServiceRoot.ExecNotificationQueryAsync objSink, "SELECT * FROM __InstanceDeletionEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'"

    Do
    ' Loop that runs at the same time '
        WScript.Sleep(60000)
    Loop
    Sub objSink_OnObjectReady(objLatestEvent, objWMIAsyncContext) Select Case objLatestEvent.TargetInstance.ProcessID Case intID1 objWMIServiceWin32Process.Create strCmd1, Null, Null, intID1 Case intID2 objWMIServiceWin32Process.Create strCmd2, Null, Null, intID2 End Select End Sub

    Is there any solution now that you see more of the picture?


    • Edited by DJX995 Thursday, November 9, 2017 8:28 PM
    Thursday, November 9, 2017 8:21 PM
  • This is much more reliable and easier in PowerShell.  PS also events on deletion asynchronously.

    $action = {
        Write-Host $event.MessageData -ForegroundColor green
        Write-Host $event.SourceEventArgs.NewEvent.TargetInstance.CommandLine
        $global:evt = $event
    }
    
    $wqlCreated = [System.Management.WqlEventQuery]::New('__InstanceDeletionEvent',[TimeSpan]::new(0, 0, 1),'TargetInstance isa "Win32_Process"');
    $watcher = [System.Management.ManagementEventWatcher]::New()
    $watcher.Query = $wqlCreated
    
    # register for async notification
    Register-ObjectEvent -InputObject $watcher -EventName EventArrived -Action $action -MessageData 'Process Deleted'
    
    #if in a script uncomment next line
    #while(1){sleep -Milliseconds 100}
    
    #Or just wait for the event.
    #$event = $watcher.WaitForNextEvent()
    #$event.TargetInstance
    


    \_(ツ)_/

    Thursday, November 9, 2017 9:58 PM
  • I believe that, at a minimum, the user has to have "Run As a Service" and "batch" rights.

    You also need to capture the exact error to see what the actual error is.


    \_(ツ)_/

    • Proposed as answer by jrv Thursday, November 9, 2017 10:05 PM
    • Unproposed as answer by jrv Thursday, November 9, 2017 10:06 PM
    Thursday, November 9, 2017 10:02 PM
  • Sorry.  I see you posted the error.

    Invalid parameter makes sense.


    \_(ツ)_/

    Thursday, November 9, 2017 10:06 PM
  • I have no idea how to convert my entire VBScript into PS.

    It is fairly complex and it would take me a long time to learn PS.

    The only error I could capture is:
    -2147217400
    Invalid parameter

    Since it's running via Task Scheduler, I accomplished this by doing the following:

    objFSO.CreateTextFile(strDirRoot & Err.Number)
    objFSO.CreateTextFile(strDirRoot & Err.Description)
    I put that at various parts of the script until I found where it was dying.


    I had to grant run as batch rights to the user for the script to run but if the user isn't made an Administrator, it always fails at:

    ExecNotificationQueryAsync

    I don't think it needs logon as a service because when I look at the current security policy, Administrators are not part of that policy anyway.

    Thursday, November 9, 2017 10:08 PM
  • A standard user does not have "creation" rights in WMI for events. You would have to grant that on the WMI namespace/class


    \_(ツ)_/

    Thursday, November 9, 2017 10:12 PM
  • I see, how would I accomplish that?
    Thursday, November 9, 2017 10:13 PM
  • "WMI Control" properties in CompMgmt/Services and Applications

    \_(ツ)_/

    Thursday, November 9, 2017 10:17 PM
  • Which one of these do I modify and what do I change?

    Sorry, I've never been in here before.


    • Edited by DJX995 Thursday, November 9, 2017 10:19 PM
    Thursday, November 9, 2017 10:18 PM
  • Well, in that WMI Control area I tried giving the user all of the "Allow" permissions on the root and made it propagate to all lower name spaces. It still didn't work. I then tried to also grant logon as service and I got the same result.
    Thursday, November 9, 2017 11:25 PM
  • I don't know as I have never done this as it can be a security risk.  Once a user can create an event they can create a script event that will run any arbitrary script at an elevated level.  Not full admin but with extra capabilities.

    You will have to test to find the least privilege required to execute your script.  At a minimum you will need "write" on "root\subscriptions"


    \_(ツ)_/

    Thursday, November 9, 2017 11:27 PM
  • Well, in that WMI Control area I tried giving the user all of the "Allow" permissions on the root and made it propagate to all lower name spaces. It still didn't work. I then tried to also grant logon as service and I got the same result.

    That would  be a BIG mistake.  Be sure to remove all changes if you can.

    Also the user has to have proper permissions on DCOM.


    \_(ツ)_/

    Thursday, November 9, 2017 11:28 PM
  • Well, in that WMI Control area I tried giving the user all of the "Allow" permissions on the root and made it propagate to all lower name spaces. It still didn't work. I then tried to also grant logon as service and I got the same result.

    That would  be a BIG mistake.  Be sure to remove all changes if you can.

    Also the user has to have proper permissions on DCOM.


    \_(ツ)_/

    I did, I'm just trying to figure this out.

    I just added the permissions to subscription like you suggested.

    Now what do I do in DCOM?

    Thursday, November 9, 2017 11:32 PM
  • Give the user permissions on the WMI object.


    \_(ツ)_/

    Thursday, November 9, 2017 11:40 PM
  • The DCOM Config object: "Windows Management and Instrumentation"?

    What settings should I change here?

    Sorry to keep at you but I don't know much about these settings.

    Thursday, November 9, 2017 11:43 PM
  • Tried giving full permissions in all of those and it still didn't work.
    This was with the WMI root\subscription granted Full Write+Execute as well.

    Removed my changes from DCOM "Windows Management and Instrumentation".

    Friday, November 10, 2017 12:06 AM
  • Have you actually tried logging is as a standard user and running this at a prompt?


    \_(ツ)_/

    Friday, November 10, 2017 12:25 AM
  • The target is a domain controller and regular users can't login to the console on a DC.

    I was hoping to accomplish without an interactive login.

    This worked great as two separate scripts (didn't use the async sink at that point) and I thought I could make it better by combining all operations in one script.

    The way this is going, it looks like running this as an administrator is the only way to go.

    I guess it's not possible.

    Friday, November 10, 2017 12:36 AM
  • Users cannot remotely access WMI on any system.  I think what you are trying to do is not possible.  Why do you think a user needs remote access to processes on a DC?


    \_(ツ)_/

    Friday, November 10, 2017 12:42 AM
  • The script is being run from Task Scheduler on the DC, not remotely.
    Friday, November 10, 2017 12:49 AM
  • So run it under  an admin account to prove it works.


    \_(ツ)_/

    Friday, November 10, 2017 12:56 AM
  • This is a VBScript program that is failing to run as an unprivileged user via Task Scheduler. I'm trying to get the following bit of code to work on a Windows Server 2016 Domain Controller:

    [...]

    This works fine when I run the task as an administrator but I do not want the program to have administrative rights.

    Any suggestions?
    Thanks!



    Friday, November 10, 2017 12:57 AM
  • You have not explained why this ahs to run as standard user?

    \_(ツ)_/

    Friday, November 10, 2017 1:15 AM
  • Sorry.

    Just best practice to run things as separate users with least permission possible.

    Plus, I'm coming from a previous two script approach and I had a dedicated user to run those two scripts before I combined them into this one.

    Friday, November 10, 2017 1:18 AM
  • That does not explain the purpose for needing to run a task as user. Also you can get all process termination events in the event log.


    \_(ツ)_/

    Friday, November 10, 2017 1:23 AM
  • No specific reason other than I know it's best practice to do so.
    I don't see anything in the Event Log under Application or System pertaining to my issue.
    Friday, November 10, 2017 1:33 AM
  • That is still not the question I  am asking.  Why do you need to run this script?


    \_(ツ)_/

    Friday, November 10, 2017 1:35 AM
  • Sorry, I misunderstood your question.

    This script executes a program to record video streams and then sorts and cleans up the files based on a retention schedule.

    Friday, November 10, 2017 2:04 AM
  • And why does that require WMI events and Why would you run this in a DC?


    \_(ツ)_/

    Friday, November 10, 2017 2:21 AM
  • In order to run the two loops at the same time.

    I first execute the program.

    Then, loop through my organization/cleanup code every minute as the files are written to disk.

    Then use the WMI async sink to keep the program running (if it crashes, for instance).

    Both loops are running at the same time via the same script.

    I only have two servers to choose from in this instance and they are both DCs.

    Friday, November 10, 2017 2:28 AM
  • Well. I have been designing systems for decades and this sounds like a Rube Goldberg.  Why not just run this on a workstation?  You are trying t synthesize a service with a task.  This then puts you in a bad spot.

    I can't  help you resolve this issue since I have no access to your system.  I also do not believe this is an= scripting issue.  It is a design issue and you may need to contact a consultant with system skills to help you sort this out.  As you have noted the script works fine outside of the en vironment you are trying to use it in.

    Good luck.


    \_(ツ)_/

    Friday, November 10, 2017 2:34 AM
  • There is one other thing I just thought of. The account running the script has to have login rights on the host.  Standard users do not have login rights on a DC.  Also events may require a profile.  If the user has never logged in then there will be no profile.

    Test this on a workstation after you have logged in the user at least once.

    This issue effects many programs (Office) and subsystems when running as a task.


    \_(ツ)_/

    Friday, November 10, 2017 2:40 AM