Showing results for 
Search instead for 
Did you mean: 
Create Post

FEATURE REQUEST - Powershell component - run as administrator

FEATURE REQUEST - Powershell component - run as administrator


This one is (in my head at least) quite simple and straight forward, how come we can't have a powershell component run with administrator permissions on a node with an agent installed?

My request should in theory be quite simple to add, just a checkbox in the powershell component saying "Run as administrator", and then it will do just that.

You should already have code that does just that only requiring minor adjustments, while remote deploying an agent you require the installer to run with administrator elevation to install.

My specific use-case is monitoring a scheduled task that is in a custom folder that requires local admin permissions, but there are many other scenarios where administrator permissions could be required to monitor something.

This request could also be extended to the "Windows Script monitor" and "Linux/Unix Script Monitor" (SUDO instead of administrator obviously)


Specifically I mean a powershell session elevated to full administrator permissions, a way to test this is with the script below:

$currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())

if ($currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {

write-host "Message:This powershell session does have administrator permissions"

write-host "Statistic:0"

} else {

write-host "Message:This powershell session does NOT have administrator permissions"

write-host "Statistic:100"


This will only return with statistic 0 if the powershell session is elevated to administrator permissions.


Level 7

Nice, I have also managed to get around it by disabling UAC on the server.
Both of our solution I agree work as a workaround, but I still belive that running with full administrator access really should be a built in thing from Orion APM, especially in cases where the agent is installed running as the local system account. Like, we're 98% of the way there already, just missing that little step.

Level 7

The example script I provided was not at all a script used to monitor anything productive at all really, that was just a way for me to give the developers a "here, when this works, you have delivered what I requested" (also should mention I have 2 accounts, one for private and one for work)

The reasons for wanting this is to, as I mentioned, monitor fx a scheduled task that is in a custom folder that requires local admin permissions, but as I also mentioned there are guaranteed to be a million and one things people could use this for to further enhance their monitoring setup.

Level 7

I would be very careful about disabling the UAC on a Windows Server. It's there for a reason. Also, unless you're using that user for anything else, then I would recommend that you place that script as a service for you to run remotely with a LUA created in its proper OU and GPO applied. Itd be easier to manage that execution from a remote session and as a service than allowing domain administrator privilege on a standalone object outside of administrator itself.

This will mitigate future issues. It may have been something as simple as updating a group policy. Get the RSOP at User and Computer level to see what policy may be in effect.

Level 8

I completely agree with you that disabling UAC is a very bad idea and I have not actually done it in a production environment, it was in a test environment for the purpose of seeing if it was possible to get my code working "by any means necessary".

I think the issue with this is really a Windows security problem, rather than something that SAM can resolve. As UAC scuppers all attempts to automate approval of elevated commands, and disabling UAC doesn't explicitly provide all further actions on the server with the 'highest privilege' of the executing user, if explicit 'run as admin' is required, we're a little stuck.

There are various articles about there which discuss different methods of how to elevate a script within the script body, but all of these fall foul of UAC in some way or another.

I doubt even having an agent installed, and therefore running the script under the context of the agent, would help.

For the OPs use case, perhaps adding the Orion server itself to the permissions of the folder in question, and then following the suggestion bobmarley​ shared, would fix this particular issue?