To run a PowerShell script on multiple computers via Group Policy, you can work with an Immediate Scheduled Task. The main advantage over logon scripts is that you can execute your script with admin rights.

Other useful features are that the PowerShell script runs right after applying the Group Policy. In addition, the script only runs once because each time Group Policy refreshes, it will remove the task.

To work with Immediate Scheduled Tasks, you must join your endpoints to your Active Directory (AD) domain. You will also need Remote Server Administration Tools (RSAT) installed on your workstation (please do not do this on your Domain Controller).

After fulfilling these prerequisites, you will need to open up your Group Policy Management Console (GPMC). Navigate to the location in your AD forest that contains the systems to which you would like to apply this Immediate Scheduled Task. Then right-click and select "Create a GPO in this domain, and Link it here." When prompted, assign a descriptive name to this GPO:

Immediate Scheduled Task to run PowerShell script

Immediate Scheduled Task to run PowerShell script

Once you have created that GPO and linked it to your selected organizational unit (OU) or root domain, right-click it and select Edit.

Edit GPO to add settings

Edit GPO to add settings

This will bring up your Group Policy Object for which we will set this policy's conditions. With this policy open, we should navigate to the following location:

Computer Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks

On the right-hand side, you will have a blank area in the Scheduled Tasks pane. You should either right-click in the blank area or right-click on the Scheduled Tasks tree item on the left-hand side. Next, we will then select:

New -> Immediate Task (At least Windows 7)

Create Immediate Scheduled Task (At least Windows 7)

Create Immediate Scheduled Task (At least Windows 7)

Once you have selected the Immediate Task (At least Windows 7), a New Task pane prompts us to configure our task. These settings include a Name, Description, Account to run from, Run with highest privileges checkbox, and the Configure For: drop-down menu. First, we will need to give your new task a Name and Description (recommended).

Next, let's go to the bottom and select "Windows 7, Windows Server 2008R2" in the Configure For: drop-down list. This will make sure this task will work on Windows 7 and higher systems (Windows 7's Task Scheduler has significantly changed since Windows XP). Additionally, we will need to make sure that we select the Run with highest privileges checkbox.

Next, we will select the Change User or Group button. For this example, I am going to use the built-in NT Authority/System account on the local machine that will run this Immediate Task. You can, and the recommended approach is to use a separate account that has this right/authorization on your endpoint systems since the SYSTEM account has what I like to call "god" permissions. To select this account, simply type out SYSTEM in the "Enter the object name to select:" pane and click OK.

Configure an Immediate Task to run on workstations or systems

Configure an Immediate Task to run on workstations or systems

We will now move on to the Actions tab on the New Task (At least Windows 7) Properties pane. We will make sure that the following pane has these values:

  • Action = "Start a program"
  • Program/Script = C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
  • Add Arguments (optional) = -ExecutionPolicy Bypass -command "& C:\Path\To\Script.ps1"

We will keep the Start a program action and include the path to the Windows PowerShell executable in the Program/Script field. The Add Arguments (Optional) we will include a few things here that will make sure that our script runs. The first is the -ExecutionPolicy Bypass string. This will ensure your PowerShell execution policy doesn't prevent your script from running.

The second piece here is the -command "& C:\Path\To\Script.ps1" string. We are using the Command parameter to run our actual script. The "&" symbol inside the quotes ensures that our script runs and does not simply open or just load into memory. Your Add Arguments (Optional) field should look like the string above with all the hyphens and spaces.

Next, we will move to the Common tab and select the Apply once and do not reapply option since we want our Immediate Task to apply only once and not continually (unless you would like that).

Close out of all open windows in the GPMC. The next time your systems reboot, your Immediate Task will run. In my example, I am referencing a location on the individual endpoint systems, but you could also use a network share like \\networkshare01\scripts\scripts.ps1 in the -command “&” string.

If the desired script does not reside on the local system, we can add another setting to our Group Policy Object that can copy the intended script to our local machines. To do this, Edit our existing Immediate Task Group Policy Object and navigate to:

Computer Configuration -> Preferences -> Windows Settings -> Files

Right-click in the Files pane and select New -> File. We will first select Create in the Action drop-down menu. Then we will select our Source file (either on a network share or our local machine), and then for the Destination File, we will either type in or select the file path:


Copy a file to the local machine for the Immediate Task to run

Copy a file to the local machine for the Immediate Task to run

If we look at one of our workstations, we can see that the system copies the file to the C:\Path\To\Script.ps1 location.

Script.ps1 on the endpoint system

Script.ps1 on the endpoint system

I have added the following code inside my C:\Path\To\Script.ps1 file so that I can see if it works as expected:

New-Item -Path C:\Path\To\ -ItemType File -Name log.log
Add-Content -Path C:\Path\To\log.log -Value "$(Get-Date) - C:\Path\To\Script.ps1 has run as an Immediate Scheduled Task"

With this code, I should see the creation of a C:\Path\To\log.log file created with some simple text.

Log file created to identify that the Immediate Scheduled Task ran

Log file created to identify that the Immediate Scheduled Task ran

Additionally, if you are working with Windows 10, you can see that your Immediate Task ran by looking at the Event Viewer under Applications and Services Logs -> Windows PowerShell

Subscribe to 4sysops newsletter!

On Windows 10 you can see if the script ran

On Windows 10 you can see if the script ran

With Immediate Scheduled Tasks you can run scripts on your endpoints quickly and resolve any configuration issues to help both yourself and your end users.

  1. DeployGuy 5 years ago

    Since the GPO runs under the local system account and that local account has no network rights to access off the local machine it seems you cannot send information back to yourself. But there is a way for that to happen and to omit the file copy of the script to the local machine.

    How? The key is to know that the local system account is by default a member of the Authorized User group which exist on every machine.

    So create a share with permissions with full control for Authorized User group, don’t worry, we will control and restrict permissions using NTFS permissions.

    Create a folder structure, Example, these are all folder names.


    Put your script in this folder and give modify rights only to your administrators so they can review and/or modify the script when needed. Regular uses must NOT have the ability to modify files in this folder.

    Now create another folder under Get-FlashVersion\Reports

    And now here is the magic, Give the  the Authenticated users group modify NTFS permissions to the reports folder.

    Now your script can use $PSSCRIPTROOT for relative addressing for your script to write a file back to the reports folder.


    As group policy updates on each machine the task will run and gather what ever information your script gathers and write it to the share identified by the computer name.

    Then in the \\servername\Sharename\Get-FlashVersion folder you write a powershell script or simple batch file that concatenate the information of all the files in the report folder into a single file in the Get-FlashVersion folder. I add time information into the name of the report file created so that I can run the report again and not a have  file in use issue if I am still looking at the last report.

    Typically my report for each machine is information in a single line in comma delimited format.

    The concatenated file uses the .csv extension and the resultant file opens in excel automatically for sorting for analysis.

    The reason I gather only a single line of info is that you want the script to run quickly.

    I have run scripts like this for about 3 years. Usually I want to know what the version of a file is on all machines, or registry setting or pretty much anything you want to know.

    I only use query scripts, that is READ ONLY. I don’t change or write values to the workstations as I consider that activity much better done by SCCM because of the success or failure reporting of that system.

    I use this as a near real-time check to compare the results of my SCCM queries to the powershell task scheduled query and get the greatest accuracy possible and to validate or NOT the results from the queries.

    Remember these are reports that arrive within about 2 hours from just about every system you target that is on line. (REAL LIVE MACHINES), that is as close to real-time reporting as you can get, if you absolutely, positively need to know a small bit information from all your machines right away, this is the best method that I have ever found and that Josh has so well documented.

    ALWAYS link your new GPO to an OU that is a test OU with test machines and make sure it works as you intended before linking to  larger amounts of machines.

    Consider this, within 5 minutes of enabling this GPO your machines will begin to report. On a network of 5000 or less workstations the load should not be felt and can be run continuously for days or weeks if needed. Although as short as possible is best. Remember always test, test,test and remember to TURN IT OFF when you have what you need.

    Remember this technique that Josh has shared is very powerful and with GREAT POWER comes GREAT RESPONSIBILITY.  Do it wrong and you may experience a CEV. (Career Ending Event)

    Use at your own and your networks risk.



    • Author
      Josh Rickard 5 years ago

      DeployGuy, thank you for commenting!  Yes, you hit the nail on the head!  I have definitely seen this in the wild and it works great for gathering system inventory without SCCM or another inventory tool.  Thanks again for commenting, and sorry for the late reply (was on vacation for a bit. 🙂 )

    • Preguntón Cojonero (@preguntoncabron) 4 years ago

      real world samples ps1 scripts for gathers info of computers and powershell script for concatenate the information of all the files? computers inventory ?.

  2. Luc Fullenwarth 5 years ago

    I’m using this method since while also.

    On my side I prefer
    -File ‘C:\Path\To\Script.ps1’
    -Command “& C:\Path\To\Script.ps1”

    Usually, I also use -Noninteractive and -Noprofile parameters.

    Very good tutorial Josh!


    • Author
      Josh Rickard 5 years ago

      Luc, thanks for commenting!  Yeah, I have used -File but -Command seems to work better in some (weird) situations.  Also, I actually choose NOT to use -Noninteractive and -Noprofile parameters.  This is because I actually use these to alert for malicious activity.  These parameters are typically ( used by malicious actors, so when my workstation logs are forwarded to my SIEM then I can setup alerts for specific keywords. 🙂

      I wonder if this would be interested to anyone as blog post?


  3. Boaz 5 years ago

    Hi Josh,

    Thanks for a very nice article.

    I encounter a problem with immediate tasks and Windows 10 (1703).

    Apparently the task is not deleting itself after expiration which causing the creation of the task in the next refresh fail.

    If I manually delete the task it will be created in the next GPO refresh.

    Did you encounter similar problem? If yes, do you have a solution?


  4. mhumphries 5 years ago

    Thank you so much i was able to complete a project that i have been working on for a couple of days, because of this article. well written.

  5. DeployGuy 5 years ago

    This addendum to my previous post is for those with SCCM build 1610 or newer.

    In SCCM 1610 and above Microsoft added a “Run Script” function, using the same scripts as you use for group policy with the location for your report hard coded in the script with modify rights for “Authenticated Users” as noted above you can deploy the script against a collection of machines and the result come back incredibly fast. And I mean”blazing faxt” 5 minutes for 1600 reports.

    Now is this better than using group policy, that depends if you need complete and constant updates to the data, the answer is no, because the scripts function will only return results from on-line machines, while group policy will keep reporting every 2 hours or so.

    To use the scripts function safely my scripts are very quick and read only, I then target a collection that reports only on-line machines, I refresh it just before activtivation.  Then I deploy the script to the collection to 1500 machines and get results in 5 minutes, multiple location across the US!

    So to summarize, use the script with Group policy for continuously updated results and use SCCM Script function for quick results against machines in an SCCM collection.

    Remember this technique that has been shared here is very powerful and with GREAT POWER comes GREAT RESPONSIBILITY.  Do it wrong and you may experience a CEV. (Career Ending Event)

    Use at your own and your networks risk.



  6. Phatmandrake 4 years ago

    To clarify this is intended to “run once” per GPO refresh. Not Run once per system.

  7. Mark 3 years ago

    I would like to create a GPO and run a powershell script through the task schedule on specific group of computers for all users who log onto the computer (domain joined Windows 10 machine).

    I have followed all your suggestion, but I cannot get any powershell script to run on the endpoint computer. The task is there, it says it runs successfully, but in reality the script does not execute.

    I have created a simple powershell script to test that just writes the same word over and over again. I have also tried a script that maps a network drive.


    None of the scripts execute.


    I am using the system account, with run at highest privileges as  well run whether user is logged in or not.

    The only way I have had a powershell script run successfully through task scheduler is to create a task with a domain admin account while logged in with domain admin account using domain account to execute. If I change to system account, it does not run, or if I change logged on user it does not run.


    Any suggestions?





    • Leos Marek 3 years ago

      Hi Mark,

      please open a topic in the Forums, we will be happy to help you. 

  8. Fritz 3 years ago


    thanks for this very helpful article. I used an immediate scheduled task to deploy a task with a powershell script which personalizes the template paths of Office 2013 for our users. The task runs in the user's context to be able to write to HKCU. It all worked well but every time the policy was pulled, the script window popped up and flashed for a second for every user, every 90 minutes. I tried “powershell.exe -WindowStyle Hidden”, “| Out-Null”, “>$nul 2&>1” and the task's hidden flag but none worked.

    Reason is that powershell.exe has a parameter -WindowStyle with a possible value Hidden which obviously doesn’t work as expected / is broken. The official issue:

    The workaround I found while reading the Github thread is:

    Set objShell = CreateObject("Wscript.Shell")
    Set args = Wscript.Arguments
    For Each arg In args
    	objShell.Run("powershell -windowstyle hidden -executionpolicy bypass -noninteractive ""&"" ""'" & arg & "'"""),0

    … and then call the powershell script you want to execute like this:

    wscript "C:\Path\To\ps-run.vbs" "C:\Other\Path\To\your-script.ps1"

    Now I can run my script using the immediate scheduled task in my GPO without disturbing any user and config their session settings. Yay! Tested with Win10 x64 Build 1809, Win7 x86, Win7 x64.


  9. DeployGuy 3 years ago

    Thanks for sharing that, very nice.  There is one circumstance that you should be aware of. That is if you have implemented Microsoft AppLocker, and specifically the MSI -Script policy.  We found that if we implemented this, that any user, even and administrator would be unable to run jscript, vbscript, and batch files and PowerShell would operate only in PowerShell Constrained Language mode, a mode that is essentially useless for any meaning full script. In our case we used AppLockers Policy mechanism to exclude local administrators, but even then you had to make sure you open the process elevated, unless the script was in one of the allowed folder structures.  So the bottom line is that the running any scripts under the user context for a non-admin no longer works.  

    So what do you do when you need to get user information?  Well, the only way that I have found so far  is to operate as the System account and find ways to get the user information, extra work for sure. Fortunatley there are folks smarter than I. The makers of the "PowerShell Application Toolkit"  An open source installation wrapper system that leverages the POWER of PowerShell, that contains functions that let your read all the user profiles among other things.  So you can still get what you want if you are willing to work a little harder, actually a lot harder.  But it is, what it is.  

  10. Shiraz 3 years ago

    I have been trying to setup a scheduled task for a couple weeks now but i keep getting the same warning in event viewer on my endpoints. The warning states GPO did not apply because it failed with error code '0x8007007b the filename, directory name or volume label syntax is incorrect.' The error was suppressed. 

    My script is on a NW share so my argument is as follows: 

    -ExecutionPolicy Bypass -Command "& \\FS01\server\scripts\drivespace.ps1"

    -ExecutionPolicy Bypass -File "\\FS01\server\scripts\drivespace.ps1"

    I have tried both these ways and still getting the same warning in EventViewer. 

    I have also tried configuring it for win2008 and 2008R2 but neither seem to do the trick. I am running out of ideas. Please HELP!!:)

  11. Andy Davies 2 years ago

    This works beautifully and it has really helped with a dificult problem – except the immediate task does not delete itself after running (in WIndows 10 at least). Is there something additional that needs to be done since this guide was written?

  12. Stefan 1 week ago

    I have tested these powershell arguments to prevent any powershell pop-ups:

    -file “C:\DeployFolder\xyz.ps1” -NoLogo -WindowStyle Hidden

  13. Stefan 1 week ago

    the -ExecutionPolicy should not be used at all in a company environment!!
    Just make sure you have that option disabled by GPO and use code-signing to guarantee the security of the code.

Leave a reply

Your email address will not be published.


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account