I am running a Script in task scheduler and need powershell to run as admin RRS feed

  • Question

  • I am running a script that I know for a fact works when I run it in an administrator window. When I run it without being elevated it doesn't work. I added this into a task to run everyday at 11:00 but I cant figure out how to run this script as admin. I tried to go to properties and run as admin but its grayed out and I looked under UAC and its on medium. This is running on server 2008R2. I was hoping maybe I could do like a powershell.exe -verb runas C:\users\XXX\script.ps1 but that didn't work.

    Please help
    Wednesday, January 29, 2014 10:59 PM


All replies

  • When you create the task in Task Scheduler there should be a "Run with highest privileges" option on the General tab:

    Creating a task in Task Scheduler, select the Run with highest privileges option to run the task elevated

    You need to select this option and make sure the user you run the task with is a local administrator on the machine. Now when the task runs it will be in an elevated process.

    Check out this previous thread for more information about Run with highest privileges: How does "Run with the highest privileges" really work in Task Scheduler ?

    • Edited by Jason Warren Wednesday, January 29, 2014 11:11 PM
    • Proposed as answer by jrv Wednesday, January 29, 2014 11:15 PM
    • Marked as answer by bohlingj Thursday, January 30, 2014 1:49 PM
    Wednesday, January 29, 2014 11:11 PM
  • I have that box checked but the script is running on a domain controller. any ideas?
    Wednesday, January 29, 2014 11:41 PM
  • Is the user account a member of the Domain Admins group?

    Thursday, January 30, 2014 12:08 AM
  • I wrote this script a while back so I could launch PS under a differnet account a while back with Admins right on my laptop. You might be able to change a bit to get your script to work. A while back I also had a problem with getting a schedule task to run how i wanted it to. It ended that the schedule task wasn't the issue but that the script used something that was profile specific (an ssh key) and I needed to modify my script to include that to get it to work. Hope

    # Admin / Alternative account name
    $Diff_Acct = “domain\UserName”
    # Load theAdmin / Alternative account Creds
    $cred = Get-Credential $Diff_Acct
    # Create a new process with UAC elevation 
    Start-Process powershell.exe -Credential $cred -ArgumentList “-Command Start-Process powershell_ise.exe -Verb Runas“ -Wait
    # Test to make sure you PS running under the right account by running the following cmd in the new PS_ISE window
    # [Security.Principal.WindowsIdentity]::GetCurrent().Name

    fully this will help, if not best of luck

    Thanks in Adavance

    • Edited by John-Barrett Thursday, January 30, 2014 12:41 AM
    Thursday, January 30, 2014 12:40 AM
  • I don't really want that user to have that high of rights. I wanted it to have the lowest rights possible.
    Thursday, January 30, 2014 1:10 PM
  • Hi bohlingj,

    you are trying to run a script as a task and having trouble, soooo, did you ...

    1. Verify the user account that is running the task has local admin rights and is run using the highest permissions?
    2. Verify that the script actually way executed and failed? Or did it never run at all? (Example: Have it write a logfile-entry as very first action)
    3. If the script uses network resources, will the executing account have access to those?
    4. Did you remember to set the task so it will execute, even if the user is not logged in (see image above for wrong configuration)

    If the script never ran, you better get configuring the task again, something is missing.
    If it did run, start debugging your script. Dump errors to logfiles, dump step-by-step output to logfiles, or anything else to debug it.

    Here from remote, given the information you have provided, we really can't help you much beyond general advice on setting up tasks or debugging scripts.

    Cheers and good luck,

    Ps.: If it turns out it doesn't run at all, maybe screenshoting all windows in the task config and posting them (with judicious editing to remove security relevant information ofc.) will make it easier for us to recognize the problem.

    There's no place like

    Thursday, January 30, 2014 1:26 PM
  • When I run powershell as administrator and then run the script in it, it works fine. I am running PSv2. This is a DC so I do not want to put v3 on it. I don't want the user to have domain admin rights because I think that is a security problem. Is their a way around this?
    Thursday, January 30, 2014 1:33 PM
  • Hi,

    As FWN said, we can provide only general guidance about the task scheduler. If the script works when you run it from a command line, then you don't have a scripting problem. This forum isn't really for scheduler issues.


    Thursday, January 30, 2014 1:36 PM
  • Hi Bohlingj,

    as far as user accounts are concerned, you have no other choice on a DC. There simply are no local user accounts. It might be possible to run it as System (though it'll be still a DC System, so I really can't tell whether that's any better from your perspective. I have to admit it simply never came up for me, but frankly, if you are wondering about security risks, running it as DC System strikes me as not much of an improvement over Domain Admin).


    There's no place like

    Thursday, January 30, 2014 1:55 PM
  • I dont understand this:

    One the one hand the script should run on a domain controller. On the other hand the account, the script is executed with, should not have domain admin rights (or builtin administrator rights).

    If the script user should not have such high privileges then it should/must not run on a domain controller. -> Use a member server.
    Be aware of what a domain controller is! Only tasks that need domain admin rights should run here.

    If it is just about connection to this dc within the script you can surely use parameters like  "-Computername" or "-Server".


    • Edited by WalterFMB Thursday, January 30, 2014 3:05 PM
    Thursday, January 30, 2014 3:04 PM
  • Run with highest privileges didn't work for me.  My script works when I run as administrator, but when I run in TaskScheduler with the run with highest privileges checked, the start/stop vm part isn't working, like when I don't run as administrator in powershell.

    Michele Cleary

    Friday, February 21, 2014 7:33 PM
  • In the task you have the option to specify the user to run as. Is this user a local administrator on the machine?

    Friday, February 21, 2014 8:25 PM
  • The user is a member of Administrators and has full control of the directories the script copies from/to.  

    I figured it out just now.  I was executing the version of powerShell in %SystemRoot%\SysWow64\WindowsPowerShell\v1.0\powershell.exe.  When I changed it to system32, it worked!  I found all running VM's!


    Michele Cleary

    Friday, February 21, 2014 8:54 PM
  • Does not work.  I'm running Server 2016, domain controller.  Defining a scheduled task to run under the domain admin account, whether logged in or not, and with "run with highest privileges" set, the started powershell instance to run a script still does not run as admin.
    Sunday, January 26, 2020 5:31 PM
  • Does not work.  I'm running Server 2016, domain controller.  Defining a scheduled task to run under the domain admin account, whether logged in or not, and with "run with highest privileges" set, the started powershell instance to run a script still does not run as admin.

    Again - please do add new questions to ancient threads already marked as answered years ago. If you have a quesiton create a new post and link the threads you think are related to your issue if needed.


    Live long and prosper!


    • Edited by BOfH-666 Sunday, January 26, 2020 10:52 PM
    Sunday, January 26, 2020 10:50 PM
  • My bad, I guess I was under the mistaken impression that one of the purposes of this forum was to help people find working solutions to problems, no matter how "old" they might be.  I didn't realize that incorrect information was to be deemed as sacrosanct after a certain period of time.
    Monday, January 27, 2020 3:33 PM
  • ... purposes of this forum was to help people find working solutions ...
    Of course ... but that does not mean there are no rules to follow.  And it should be enough to get an advice once. ;-)

    Live long and prosper!


    Monday, January 27, 2020 4:06 PM