So let's go back and look at how we
retrieve background job information about
local jobs and also other jobs that we
create. Okay, so once we have jobs
running, we obviously want to get details
about what took place with the job. So
what I'm going to do here is I'm just
going to start a new job. So we'll just do
the standard ‑ScriptBlock that we had
before. We'll choose Get‑Process, and
we'll close that off, and then what we'll
do is we'll give it a name, and I'll call
it Job1. So that kicks off the job. Now
what I can do here is I can say $job. I
can then use what's called Get‑Job and
specify that by ‑Name. And then I can say
job1, and I should then get the details of
that job, which is what gets returned
every time we execute a job. So you can
see we get the ID, the name, the job type,
the state, and whether it has more data.
We can also then go one step further
because, remember, whenever we execute a
job, it has more than one job that takes
place. So you can see we've got this whole
host of things that have come down now, so
I can go back here and say my job that I'm
getting is this one. So I can say Get‑Job
‑Name, and then I can choose the
‑IncludeChildJob, and this narrows it down
to that one specific job that we
initiated. You'll notice that the
background job is the initiation piece,
and then any commands that were executed
underneath that become a child job. What
we can do at any point, so if I do this, I
get the ‑State option, and then I can say
Completed or I could say NotStarted, so if
I type Not, it'll say NotStarted, and then
it will return. Of course, I don't have
anything here because there are no values
for me to return back. But the Get‑Job
option will return basic details about
what took place with the job. Now what it
doesn't do is return the value results
from the job itself. So, for example, if I
had done, for example, like we did the
Get‑Process, so let me just choose
Get‑Job, and we can see my list here. And
if we look at number 52 which was our
Job1, so let me just go job and ‑Id 52, we
get the basic details. But what I don't
see is what the end result was. So this is
where we can utilize a different command
called Receive‑Job. And I can then pass an
‑Id. And then, of course, at this point,
let's say it was 48, I could say retrieve
job 48. That does not retrieve the job
itself, you can see as I scrolled,
because, remember, we issued a Get‑Process
command, so the process will come back and
give me all the processes of everything
that's running on my machine, and that's
what it returns. So the Receive‑Job
command returns the values or the results
from that. So let's do a simplistic one
here. So I'm going to say $job =
Start‑Job. I'm going to do a ‑ScriptBlock,
and in here, I'm just going to use
standard environment variables,
COMPUTERNAME, and we'll do that. So my
job's created. Now this one's not going to
take long to actually execute, so I'm
going to say Receive‑Job, and I'll do
$job, and sure enough, it returns my value
straightaway. So we can use this receive
to get the results back. Now, if you think
that through, if we're trying to retrieve
information from other devices, so maybe I
have a PS session, then we can do the same
thing also, so we can actually go and get
the job that was initiated, and we can
receive the job. So let's think that
process through. So let me just
double‑check that we have my session.
Okay, we still do. So what I'll do here is
I'll say $job. I'm going to Invoke‑Command
using my existing $session, which is the
remote one, my ‑ScriptBlock. I'm actually
going to start a job with a ‑ScriptBlock
in there, and I'm going to use that same
one that we just did, COMPUTERNAME, oops,
I can't spell COMPUTERNAME properly today,
so let's execute this. I now end up with a
new job that's being created, so I can say
$job, and you'll see it's a background job
called Job5. Now, remember, it has
different numbers to the ones that are
locally when I choose Get‑Job because
Get‑Job is local to the specific instance.
So now that we have this, how do I get the
results back from that? I mean, I can keep
executing job until it has a status of
whatever it would be. This is where we
obviously issue another command which will
retrieve the value that we're looking for.
So, first off, I'm going to say
Invoke‑Command into the current $session,
and then I'm going to pass my
‑ScriptBlock. And in my ‑ScriptBlock here,
what we're going to do differently is I'm
going to say Receive‑Job. And then, of
course, what we get is the instance and
the ID. I know that it was 5 because that
was the one that was just created. So I
now have my Invoke‑Session, and I can
execute that. And, sure enough, it
instantly gives me the name, which is
OFFICE, which is my machine name. So I've
now interrogated a remote job that's
running on a machine and then received the
data that came back. So if we go back
through this process again, but this time,
let's use something a bit more
complicated. So let's go back to our
Get‑Process. So I'm going to initiate that
job. I'm going to go and get $job, which
is ID of number 7. I'm then going to go
and initiate another command here with 7.
And now I get that information from the
remote machine. So the Receive‑Job option
allows you to retrieve the information
results from that job irrelevant of whether it's local or remote.