So, perhaps the original problem is related to the permissions set for the user account the Windows Service is login as ? It is installed through WiX ( ) with default ServiceInstall options (ownProcess + type auto) and configured to LogOn with a local administrator user account.
When running from a custom Windows Service that only do PowerShell -NonInteractive -File d:\pathto\script.ps1: all is OK.įor technical details, the Windows Service is written in Go language (using /x/sys/windows/svc) : no specific manifest. When running from administrator mode interactive session ( Run as administrator and then confirm in UAC) : all is OK. PowerShell by using the Run as Administrator option, and then try running the script again. The current Windows PowerShell session is not running as Administrator. \script.ps1 : The script 'script.ps1' cannot be run because it contains a "#requires" statementįor running as Administrator. When running from normal interactive session : got the following error :. Tested today in Windows 2012R2 context and #Requires -RunAsAdministrator tagged PowerShell script : A better solution would be to run the service as an account which is already a true administrator, not the cheap imitation going under the pompous name of "Local Administrator".ĭefinitively aggree with that, thanks a lot to Harry for this clear answer : I was in doubt for a long time until now :-). Therefore, UAC, as configured by default, cannot grant "true administrator" rights on demand.Īpparently, you can configure UAC to never prompt, and instead grant the rights (which basically nullifies the security benefits, if any, of UAC) see for instance this blog post). This means that there is no user to prompt. Services do not run in a session, but "as a service". From the point of view of the process, everything works as if it had been a "true administrator" all along. If the user says "yes, go on", then the process is granted elevated rights. In the context of UAC, a "Local Administrator" does not have the full rights of an "administrator" (as seen by the OS), but, when it asks to do something which requires administrative rights, the UAC intercepts the call and instead of just unceremoniously rejecting the request with an error code, it prompts the user. 
This proves that "Local Administrator" does not cover the full set of rights on the machine.
Then this means that being a "Local Administrator" is not sufficient to run the script.
When they run the script as a Local Administrator, it fails with access denied.
0 kommentar(er)
