Kaseya Community

Getting a command to run in an agent procedure that requires an elevated command prompt.

This question is answered

We're trying to create a workaround to the current IE vulnerability.  One of MS's recommendations is to either unregister VGX.DLL or change the permissions on the file.

First we tried unregistering it and we found that required an elevated command prompt and could not get it to run as an agent procedure. I also tried writing it as a bat file and downloading and running it, but it would not run that way either.  Changing the permission on the file requires taking ownership of it and that requires an elevated command prompt.

I tried running the script commands 'as system' and specifying a user and running as that user, but apparently neither of these are equivalent to an elevated command prompt.

How can we get a command to run in an agent procedure that requires an elevated command prompt?  

Thanks,
- Marc

Verified Answer
  • Issue resolved!!!!

    The problem is the %CommonProgramFile% variable.   If I echo that locally, it gives me "C:\Program Files\Common Files".   If I write a kaseya script to echo it to a text file, it gives me "C:\Program Files (x86)\Common Files".

    I changed the script to use %CommonProgramW6432% and it successfully unregisters the DLL now.

    Thanks to Quentin Jimemez on another list that spotted that one.

    Thanks,

    - Marc

All Replies
  • Running as System in an Agent Procedure should negate the need for an elevated command prompt.  More often than not, there's some sort of "quirk" when running the command as System in an Agent Procedure (which actually runs the command using the built-in Windows SYSTEM account) that prevents the command from running.

    I'd recommend just doing a sanity check of running a command prompt as system per this TechNet article: http://blogs.technet.com/b/askds/archive/2008/10/22/getting-a-cmd-prompt-as-system-in-windows-vista-and-windows-server-2008.aspx

    I've found the psexec method to be the most reliable.

    Fire up the command prompt as system (verify with a whoami), then try to run the command that unregisters the DLL and see what happens.

  • Bronco, I'm 99.9% sure you are just running a bad command and your issue has nothing to do with elevation issues.

    I have used agent procedures running as the system account to modify permissions and take ownership of files before. Again, you are likely just not feeding in the correct command to the shell.

  • Ben,

    The issue isn't syntax.  In fact, both using a Shell Command and running a batch file result in the some outcome.  Procedure says that it works, but nothing actually occurs - in this particular case, unregistering a DLL (VGX.dll to be specific).

    Running regsvr32 /u /s "%ProgramFiles%\Common Files\Microsoft Shared\VGX\vgx.dll" from a Kaseya Shell in Live Connect also is indicative of success, but the DLL remains.

    That line can either be run directly, or written to a batch file and executed locally in system context or in user context (even when specified as a local admin) and fails - again, no direct failure, just doesn't succeed.  Even when the script is set to Halt on Fail.

    It looks like Brian's PSExec is the best option thus far.

  • mkopp
    ...but the DLL remains.

    It doesn't look like unregistering a DLL will actually delete it... it will just report to the OS that it's not registered.  Am I reading you right in saying that you think the DLL will be removed?  Or did you mean "remains registered?"

    This utility will help you identify whether or not it's registered before/after running the command in question: http://www.nirsoft.net/utils/registered_dll_view.html

  • The .dll will be 'unregistered' .  I tested the tool provided with the procedure I created.  When disabled the VGX.dll is not listed; when I execute the procedure to re-enable, it populates on RegDllview.

  • Could you post the procedure you used?  The one MKopp and I have been using does not seem to be working.  We've been watching the registry entries to verify if the DLL has been unregistered or not.  It only works if we run it manually at an elevated command prompt.

    Side note - How do you use quotes in an agent procedure?  For example if we need to enclose a path name with a space in quotes?   The only way I found to do it is to replace the quotes with $#34;

    Here's what we're trying:

    - <Statement name="ExecuteShellCommand" continueOnFail="false">

     <Parameter xsi:type="StringParameter" name="Command" value="regsvr32.exe -u -s "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"" />

     <Parameter xsi:type="EnumParameter" name="ExecuteAccount" value="System" />

     <Parameter xsi:type="BooleanParameter" name="Is64Bit" value="False" />

     </Statement>

    Thanks,

    - Marc

  • Brian can you provide details on using PSexec(How to ) We have around 700 PC's and doing them 1 by 1 is crazy. We tried the scripting tools in Kaseya (both Shell and Batch) with no sucess.

    Appreciate clear instructions.

    GJP

  • and :  What I was driving at is that there is no difference between running the command to unregister the DLL via the command prompt running as SYSTEM, or the Agent Procedure executeShellCommand option, when "Execute as System" is used.

    The Agent requires elevated credentials to install, and from that point forward, everything done via command line (both through LiveConnect and through executeShellCommand in Agent Procedures) using the SYSTEM account in Windows.

    PSExec is the means by which I can start a Command Prompt as SYSTEM so as to emulate the level of access that Kaseya's executeShellCommand step has to the system.  When I run a command in that context, I can see what (if any) errors are returned (i.e. what would run "in the background" using the executeShellCommand Agent Procedure Step that you might not see).

    One other thing that might be tripping you up--the executeShellCommand (according to the Help file) executes relative to the Agent's working directory: http://help.kaseya.com/WebHelp/EN/VSA/6050000/index.asp#674.htm

    Hope this helps.

  • Thanks .  The issue that we're encountering is that things aren't actually running under the System context.  Even if executing from the working directory, running a batch file as System should negate that risk.  Additionally regsvr32 is a system variable and won't matter what directory you're executing from - it will be found.

    The problem we're encountering is when running regsvr32 [...] as stated above, no change is made to the DLL registration.  The Registered DLLs Viewer reports its registration as well as the registry values remain.  When run at a console prompt (as admin) the DLL unregisters, the registry keys are removed and Registered DLLs Viewer shows no registration.

  • Oscar,

    If yours is working, could you post your script?  Below is what we are using.

    - <Statement name="ExecuteShellCommand" continueOnFail="false">

     <Parameter xsi:type="StringParameter" name="Command" value="regsvr32.exe -u -s "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"" />

     <Parameter xsi:type="EnumParameter" name="ExecuteAccount" value="System" />

     <Parameter xsi:type="BooleanParameter" name="Is64Bit" value="False" />

     </Statement>

    Side note - how can we use quotes in scripts to put around file names with spaces?  Using & # 3 4 ; in place of the quotes is the only thing I've found that works.  (That is what is in in the code above, but it looks like the forum translated it to quotes).

    Thanks,

    - Marc



    Added spaces to ascii code for quotes so forum doesn't translate it.
    [edited by: BroncoMarc at 11:11 AM (GMT -7) on Apr 29, 2014]
  • Your command is wrong. You need to use /u /s not -u -s :)

  • It should work with dashes or slashes.   I was going by the command that Microsoft specified which shows dashes.  

    technet.microsoft.com/.../2963983.aspx

    I tried running the command again with slashes and it still did not unregister the DLL.

    Thanks,

    - Marc

  • Give this a shot:

    community.kaseya.com/.../86511.aspx

  • I imported those scripts and ran them against my computer.   Same deal..  Didn't work.  Verified with RegDLLViewer and checked the registry entries and vgx.dll is still registered.

    Thanks,

    - Marc

  • Issue resolved!!!!

    The problem is the %CommonProgramFile% variable.   If I echo that locally, it gives me "C:\Program Files\Common Files".   If I write a kaseya script to echo it to a text file, it gives me "C:\Program Files (x86)\Common Files".

    I changed the script to use %CommonProgramW6432% and it successfully unregisters the DLL now.

    Thanks to Quentin Jimemez on another list that spotted that one.

    Thanks,

    - Marc