I'd like to walk you through the management of PowerShell scheduled jobs. The concept of PowerShell jobs is not familiar territory for many PowerShell users. At first glance, the benefits of running any kind of job from the command line may not be obvious. Let's peel back the covers on managing scheduled jobs and the benefits that come with them.

I'll be focusing on managing existing jobs and scheduled jobs. If you are unfamiliar with the basics of creating PowerShell jobs, then I suggest you read "PowerShell Background Job Basics" by Tim Warner. I also recommend reading my article, "Create PowerShell Scheduled Jobs," to get up to speed on creating scheduled jobs. I'll cover some basics here, but both articles dive deeper into job creation.

What are jobs? ^

PowerShell jobs are background tasks. Jobs run in the background instead of interactively in your PowerShell session. The benefit is that jobs run unattended, which allows you to do other work. Because jobs run in the background, you can submit a job and go on to other things. This is especially useful for long-running queries or information you need to gather but don't need the results right away.

Jobs do not send any results to the console. Instead, the results of the PowerShell code submitted are saved to a job queue for later retrieval. You can submit many jobs to be run and then retrieve the job results at a later time.

What are scheduled jobs? ^

Scheduled jobs are jobs that are scheduled to run at a predetermined date and time, either once or on a repetitive schedule. Scheduled jobs are the PowerShell equivalent of scheduled tasks, but better. Scheduled jobs are managed from the command line and scheduled tasks are managed from the GUI. The management portion of scheduled jobs relates to enabling, disabling, and removing scheduled jobs and getting the job results for completed jobs.

Let's look at the cmdlets available for jobs and scheduled jobs:

Most of these cmdlets are easy to understand from their names alone. However, let's dive into Receive-Job for a moment because the purpose of that command might not be obvious at first glance. To understand its purpose, imagine we've already submitted a query that ran in the background and completed its work. I mentioned earlier that when a job is submitted, there are no output results to the console. Receive-Job is the cmdlet you use to get the results from the job queue and pass them to your current session. It is named Receive-Job because you are literally receiving the job results from the job queue.

Let's show a simple example of this. I've run the Get-Date cmdlet as a job. The information returned is the job summary and not the actual cmdlet output. Notice it says the cmdlet's state is "Running," meaning the job hadn't finished completely when the status was returned.

At some point, I will want to retrieve the results of Get-Date. I use Receive-Job to take the results from the job queue and transfer them to the console output. I can specify the ID or the job name. In this example, I specify the job ID.

You should also know about the -Keep parameter. When you transfer jobs from the queue, the results are permanently removed. The -Keep parameter tells PowerShell to keep the data in the job queue for later usage. By using -Keep, I can retrieve the results again later on.

Managing scheduled jobs ^

Once you understand submitting and retrieving jobs and their results, the jump to using and managing scheduled jobs is easy.

Let's create a scheduled job.

I now have a scheduled job that will run every two minutes on my computer. Creating this job on multiple computers only requires you to add the -computer parameter. You can also create PSSessions for multiple computers and add the scheduled job with Invoke-Command.

I have let this scheduled job run a few times. Let's see what's in the job queue:

You can see the scheduled job has run four times and we can now pull the job results as we need them.

There is more information about the job as well:

Now let's get additional job results. This time I will leave the -Keep parameter off:

There is no difference in the output. However, when I go back and look at the job queue, notice the HasMoreData column now shows False for Job ID 3. Earlier, I mentioned that the -Keep parameter instructs PowerShell to leave the data in the job queue. If I were to attempt to retrieve the job results for Job ID 3 in the future, it would not return results. I could still see the data about when the job ran, but I wouldn't see the job results.

I can also perform maintenance tasks. Let's remove Job ID 3 completely from the job queue:

I can also perform maintenance tasks on the scheduled job I created earlier. First, I'll get a list of scheduled jobs on my PC. Notice the Enabled column:

Let's disable the scheduled job. Notice the Enabled column has changed to False:

Finally, let's delete the scheduled job. When I run Get-ScheduledJob afterwards, there is no data to display.

There a few gotchas to watch out for. First, job results persist even if sessions are ended. I closed my PowerShell session after my scheduled job ran a few times and then launched a new session (that is, I closed the PowerShell console and opened a new console). The job results were still available to me in the new session. However, once a scheduled job is deleted, the job results are deleted as well. If you plan to delete scheduled jobs, then make sure you grab the job results first!

Another caveat is that we cannot rename scheduled jobs. If you don't like the name you assigned to a job, delete the old job and create a new job with a different name. Please keep in mind that when you delete the old job, the job history will be deleted with the job.

Scheduled jobs vs scheduled tasks ^

The interface for managing scheduled tasks from the command line is limited and hard to manage at scale. Viewing the results of scheduled tasks involves opening the task scheduler GUI and clicking through multiple tabs to get results. If you are managing tasks on multiple machines, then you have to RDP to each machine to see those results. There are cmdlets available to manage scheduled tasks from the command line, but they only provide a limited set of actions for enabling and disabling tasks. You cannot retrieve the task results with PowerShell.

Managing tasks in the GUI

Managing tasks in the GUI

In contrast, creating and managing scheduled jobs is easy to do from the command line. You can create, delete, enable, disable, run, and pause scheduled jobs on multiple machines, all from one console. It's also an easy task to retrieve and manage job result data. Requesting information from multiple computers is straightforward once you are comfortable with the syntax. The -computer or -session parameters can be added to any of the Job and ScheduledJob cmdlets.

PowerShell is very popular because it is a powerful tool for gathering data and the syntax of PowerShell commands is easy to understand. The same principles hold true for PowerShell jobs and scheduled jobs. The simple syntax makes it easy to set up and retrieve jobs across multiple computers with little effort. It's the reason I believe that scheduled jobs are far superior to scheduled tasks.

Join the 4sysops PowerShell group!

Your question was not answered? Ask in the forum!


Users who have LIKED this post:

  • avatar
  1. Hey Mike,

    nice post there.

    Just one note regarding the last section - jobs vs tasks. I think it is important to mention, that registering scheduled job in Powershell does nothing more than actually creating a scheduled task in Task scheduler with action of running powershell.exe with specified scriptblock or ps1 file. In the end, it is Task Scheduler service that is responsible for executing the job. Without task, there is no job :))

    Cheers L


    • Author

      That's a good point! 

      The engine behind the scenes is the same: Task Scheduler. The interface and the tools for Scheduled Tasks and Scheduled Jobs are where the difference lies. Thanks for pointing that out. It's something I called out in the article I wrote last year on creating scheduled jobs, but neglected to mention in this write-up. 


  2. Scott Wilson 4 months ago

    I was gonna ask what Leos said above! I’m glad there isn’t another repository for the scheduled powershell jobs because that’d be yet another place to hide malware! 

    Another question; using these cmdlets, can you see other tasks that were scheduled through the Task Scheduler GUI? 


  3. Author


    There are separate cmdlets for scheduled jobs and scheduled tasks. The support for scheduled tasks is pretty good. But you need to understand that tasks and jobs are different at their core. The task scheduler interface can display both but that gives you a false idea that they are similar. 

    First off, here are the cmdlets for each:

    They look similar. However, they're not. 

    • ScheduledTasks can run all your old-school file types: CMD, BAT, VBS, EXE, etc. 
    • ScheduledJobs run PowerShell code and as such treat everything as objects

    From a GUI task scheduler perspective, they are exactly the same thing.

    The PowerShell team provided a toolset for creating a special type of job that would be stored in the Task scheduler library.

    The Scheduled Jobs cmdlets will not allow you to interact with regular scheduled tasks. The (GUI) Task Scheduler will let you interact with regular tasks and scheduled jobs interchangeably.

    If you want to run code in a scheduled fashion, then ScheduledJobs are the way to go because that's how you run PS code on a schedule.

    Also, remember that you can jobs at anytime in PowerShell. Scheduled jobs are the same thing as jobs but on a schedule. So once you get familiar with jobs, switching to scheduled jobs is really easy. 

    The syntax for scheduled tasks is different than the syntax for scheduled jobs. 

    You asked about seeing all the tasks and jobs.... Here's an example:

    Notice that Get-ScheduledTasks show all entries from the Task Scheduler, including the task I created for this article. But Get-ScheduledJobs only shows single PowerShell job. 

    The takeaway here is that Microsoft did what they always do: support the old way of doing things (Scheduled Tasks), while also introducing the future (Scheduled Jobs) in the same GUI interface. Unfortunately, that makes it confusing to understand which to use. Stick with scheduled and let the legacy scheduled tasks die off. 

    Hope this really short answer cleared that up. laugh

    - MK


    Users who have LIKED this comment:

    • avatar
  4. If you're looking for the scheduled job in the task scheduler GUI, it's down under Microsoft, Windows, Powershell, ScheduledJobs.


  5. Craig 4 weeks ago

    I love how PowerShell schedule jobs work, but I struggle to use them because the job definition and output are stored in the user profile of the person that created the job.  If I create a job on a server then my co-workers can't see the job with Get-ScheduledJob and can't enjoy the results using Receive-Job.  Scheduled jobs seem to diverge from scheduled tasks in this regard because if I create a scheduled task it can be seen by other users on that computer.



Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2020


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


Log in with your credentials


Forgot your details?

Create Account