So let's go back onto the machine, and
we'll look at how we wait for remote
background jobs to complete. Okay, so one
of the last things that we want to focus
on is, what about if you're trying to
execute a fairly large job on multiple
machines and you want to kind of wait for
those to kind of be completed? Well, we
talked about this previously about waiting
for jobs using the Wait‑Job command, and
kind of what does the Wait‑Job do? It
stops the user interface from kind of, it
kind of locks it up, so you can't actually
do anything else. We also talked about,
for example, using things like if we're
debugging different things as ways to kind
of intercept that. So let's have a look at
how this works. So, first off, what I want
to do is just look at, and make sure our
PS session is still live, which it is.
Okay, so I have my session. So let me
invoke a command, and we're going to drop
that into the same session, and in my
script block, I'm going to start a new
job. So start a new job. I'm going to give
it a name this time, and we'll just call
this Job1, because I want a reference it
by name. And then once we have that kind
of job set up, I want to put a script
block into that, and we'll just use this
Standard‑Get process. I do that just
because I know it's going to take some
time to execute. Okay, so this is going to
go ahead on and invoke a specific job
that's being started on the remote
machine. So let's just execute there. I'm
now going to create a new variable and
initiate a new command ‑Session Session,
and my command is actually going to be
Wait‑Job ‑name and Job1, and Enter there.
And let's have a look here. Now, of
course, timing is everything here. So what
we ended up with is the job ran, and then,
of course, I then went through the invoke
one to wait for the job to actually
execute, but of course, it had completed
in between then. So what we can do is if
we do the same thing, I can then do that
one, and you'll see it now locks the
interface for the remote job that's
running on the other machine. When that
job completes, it will then come back and
release the interface to me while that,
after that remote job is now finished. So
the same principle that we use for doing
local jobs that when we have a local job
that runs, obviously, depending on the
size of the job and the scripts that we're
running, there we go; it's never been
released. I can do the same thing for a
remote background job as well. So fairly
straightforward to understand there. It's
still the same syntax as a local one,
except we can start to nest things
together, and run something against a
machine, and then know for sure that it's
been completed, because it releases the user interface at that point.