So what are PowerShell jobs? Well a
PowerShell job is a background job that
runs a command without interacting with
that specific session. While that's
running, you can continue to work in the
same PowerShell session without
interruption while the job runs in the
background. There were two different types
of PowerShell jobs that can be ran. The
first is the default, which is a
PowerShell 7 version of that. We simply
just say start job, and it initiates that
job. We can also run a backwards
compatibility version of that, which is
PowerShell 5.1. Now to execute these types
of jobs, let's say that we first wanted to
retrieve the version of the PowerShell
that we have. So to do this, we'll use
PSVersionTable and then get the PSVersion
property from the response. If I wanted to
execute this using PowerShell version 5.1,
I would call Start‑Job. ScriptBlock is the
property or at least the parameter that we
use to pass in specific syntax we wish to
execute. So we're going to call the
PSVersion. And then there's a property
called PSVersion, and I can pass in 5.1,
7.0, etc. So we can specifically tell this
command to run using 5.1. Then, of course,
if I want to execute in the native
PowerShell 7, I don't need to pass the
PSVersion. I can say Start‑Job ScriptBlock
and then pass in the code that we wish to
execute. So this just provides us a way of
backwards compatibility. For example, you
may have scripts that don't support some
of the features in PowerShell 7. or you
may have something that uses a method that
doesn't exist in PowerShell 7 anymore. So
we can at least backwards compat that
PowerShell script that we execute. There
are two core PowerShell job types. The
first one is a background job. This is
only available within the current
PowerShell session. So what I mean by that
is when you launch the PowerShell window,
initiate Start‑Job, you can retrieve
information about that job within that
same window. If I was to launch a new
PowerShell window, I have no access to
that existing background job because it
doesn't exist in the same session. The
second option that we're not going to
speak about at all during this course is
scheduled jobs. This was a process that we
could utilize in previous versions of
PowerShell where this creates a scheduled
background job that's independent of the
current PowerShell session. So that means
the same example is before, I kick off
something in one PowerShell window, I can
open the second PowerShell window, and I
can communicate between the two. Now if we
look at the job types, they're broken down
even further. So the first one we've
talked about is the background job. This
is how you initiate it by using Start‑Job
cmdlet, and that will create whatever
script block or task that you've created
and push it to a background job. The other
one is what's referred to was a remote
job. So this means I can use what's called
Invoke‑Command, which says invoke this
specific thing, whether it's another
PowerShell script or a command. And then I
use a property called AsJob. When I use
‑AsJob, it pushes that to become a
background job. So you'll utilize this,
for example, if we're trying to execute
commands on remote servers or
workstations, and you wanted to run it as
a job. We then have what's called a
PSWorkflowJob. So this is started again by
using the AsJob parameter of a specific
PowerShell workflow job. We also then have
CIMJobs and WMIJobs, which also can take
the AsJob parameter, and that gets bundled
into the CD XML or the WMI modules that
might be utilized. We then also have
PSEventJobs, and this is where you can use
Register‑ObjectEvent, and then you add an
action parameter. An event job, for
example, can be used when you kick
something off. I want an event to happen,
and then I want this to happen too. So
those are the different types of PowerShell jobs that we have.