So let's talk about the PowerShell job
object model. So let's first talk about
the syntax itself. Well, it's broken down
into specific pieces, so the first thing
is the command that we wish to execute. So
let's say, for example, we're going to use
Start‑Job, so that will be the command
that we execute. We then have the name
that we wish to associate to this command.
So if I'm going to start a job, I can give
the job an actual name that I can use to
retrieve it back later. Now we don't have
to pass that. It'll simply give it a
random name. Then we can pass a script
block, if required, so what other commands
are we going to execute as part of this?
And then an optional one here is to pass
credential and authentication information,
so we may need to pass domain/user. For
example, if we're using an Invoke‑Command
request to remotely connect to something,
we'll want to pass a credential and
authentication. We can then pass an
arguments list of various parameters that
might be needed, and then last one is the
optional one too, where we can pass the
PowerShell version that we wish to use to
execute this PowerShell job. So every
single PowerShell job command will be
based around this same syntax, the
command, the name, the execution block,
any credentials, any arguments, and then
if there's a version that's required. So
if we look at the syntax here for
Start‑Job, you can see that we have a
series of parameters available to us.
We've got the name, which we talked about
as an optional; the ScriptBlock, which is
the execution commands; we've then got
credential, which will be the username,
password, etc.; authentication, we can
specify a mechanism for authentication.
We've then got InitializationScript, so
something that we're going to execute
straightaway. We can then set the
WorkingDirectory. This is important
because if we're referencing, for example,
another ps1 file that we've created, we
may not want to pass the full path. We
could just say, start this job in this
working directory and then from that
point, use everything that's stored there.
We can run it as a 32‑bit process, we can
obviously pass in the PowerShell version,
and then we have InputObjects and
ArgumentLists if they are required. So
some examples of this, if we wanted to
start a standard background job, I'm going
to utilize Start‑Job with a ScriptBlock.
And in this example, I'm going to just
call Get‑Process, which is another regular
PowerShell cmdlet, and I'm going to go and
say get me the PowerShell window. And all
this will do when it executes is return
back the fact that it found the process. I
could also do a similar thing, but this
time I'm going to pass in a script
instead. So I can say Start‑Job, give it a
FilePath and say, create this job, but I
want you to execute whatever's inside this
PowerShell 1 script. If I need to pass
arguments to this, so for example, I could
say Start‑Job ‑ScriptBlock again, which is
a kind of common code here. Then in my
Get‑Process, I'm going to say ‑Name and
then I've got this new variable called
args, and args will be the arguments list
of things that I want to pass. And then we
can populate the ArgumentList property, or
parameter, with the values. So in this
instance, it's going to look for
PowerShell, the pwsh version of
PowerShell, and then notepad processes
that are executing. Our last example here
is to actually set the WorkingDirectory.
And as I talked about previously, this is
about defining the directory where you
wish this to run, and then it means I can
map that to something like a FilePath. So
I'm going to say, start a job in my
C:\Scripts folder and then execute
Script.ps1. Instead of me having to put
the full path in the filePath, I can just
make sure that the WorkingDirectory has been set to where those files are.