Powershell Script with Arguments as a Scheduled Task

This guide explains how to run a Powershell script with arguments as a scheduled task and how to deploy it with group policy.

I created this blog post as I got several questions how to set up my client health script. Some of the checks it does requires it to run in the system context, and it is also recommended to run it as a startup script. I also run it once a day on my customers. A scheduled task deployed with group policy is the best way to set this up and fulfill all these requirements.

 

Powershell Script with Arguments as a Scheduled Task

Local machine: Start “Task Scheduler” and create a new task.

Group Policy: Computer Configuration -> Preferences -> Control Panel Settings – Scheduled Tasks. Create a scheduled task (at least Windows 7).

 

Selecting replace as the actions ensures that this scheduled tasked is created if not found, and any changes made to it later will be applied when group policy is renewed on the clients. I also specify “NT AUTHORITY\SYSTEM” as the user account. (Click Change User or Group, type in System and click Check Names). Also select “Run with highest privileges” to make sure this task is run under the system context.

 

Create a new trigger and set “at logon” as the trigger. This ensures that our Powershell script will run when the computer starts. You can configure additional triggers if you like, say for the script to run every day on a specific time.

 

The actions pane. This is where we configure what our scheduled task will run. In our case its a Powershell script so we create new action and chose start a program.

Action: Start a program

Program/script: Powershell.exe

Add arguments (optional):

-ExecutionPolicy Bypass -File "\\sccm\clienthealth$\ConfigMgrClientHealth.ps1" -Config "\\sccm\clienthealth$\config.xml"

Start in (optional): This is the directory you want the script to run in. I leave it blank in this case as it’s not needed for my script.

 

Our Powershell script that requires arguments is now set up as a scheduled task. Remeber to deploy the group policy object to an organization unit containing your computers if you’r deploying this scheduled task with group policy. I did that and this is how my test computer looked like after running gpupdate /force on it.

We now have a Powershell script with arguments running as a scheduled task, deployed with group policy. ConfigMgr Client Health is there.

 

Troubleshooting

Scheduled tasks last run result codes

  • 0xfffd0000: Verify the path and filename of the file you try to run.
  • 0x8007005: Access is denied. Verify that your task is running as “NT AUTHORITY\SYSTEM”. Builtin\System is not the same.

Anders Rødland

Anders Rødland started his IT career in 2006. My main focus is MS Configuration Manager and client management, and I currently hold active 15 Microsoft certifications. Certified on Windows Server, Windows Client, SQL, Exchange and System Center Configuration Manager. Anders Rødland also holds an ITIL Foundation certification.This is my private blog and do not represent my employer. I use this to share information that I find useful. Sharing is caring.

6 thoughts to “Powershell Script with Arguments as a Scheduled Task”

  1. Hopefully someone has some insight as this is extremely frustrating. I have setup this Scheduled Task via GPO, the GPO is applying and creating the Scheduled Task without any issues at all. But when attempting to run it, getting the ‘dreaded’ 0xfffd0000 error. The path is fully accessible, and I can manually run the same exact command without any errors directly from any computer via Powershell. I’ve confirmed the account being used “NT AUTHORITYSYSTEM”, as well as all Syntax (manually typed so as to avoid copy/paste issues). Despite all of this, nothing I have changed/updated will allow this to actually run as a Scheduled Task. I was very excited to get this working but if we’re not able to deploy this via GPO I am really not sure what to do….

    Thanks in advance,
    Kyle

    1. You must check to make sure your system has permissions to the share. Make sure that you have “Domain Computers” configured for access at the share level, AS WELL AS the folder level.

      A great way to troubleshoot something like this is using PSexec to run CMD as System and trying to run the script.

  2. Hi, This is a great tool. I just set up the db, webservice, and testing just running the powershell manually and get db test failures. My sql 2017 doesn’t use the default port and edited the config to use 52272; Server=server.domain.local:52272;Database=ClientHealth;Trusted_Connection=True; it still fails. it fails to test and fails to update sql. any debugging info you can tell me on how to fix this?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.