In the context of PowerShell, a 'Job' is simply a package containing the
results of running one or more cmdlets. This article shows you
two techniques for creating the PowerShell Job, then explains how you can extract the information
stored in the job.
Large complex PowerShell script blocks could take ages to complete,
consequently this
processing could tie-up your command line. Thus it's better to have a
'Job' run in
the background and free-up your keyboard so that you can issue other instructions.
Another benefit of creating a job is that thanks to the -keep
parameter you can review the results again and again.
There are two strategies for employing 'Jobs'; either append the parameter
-asJob to a cmdlet such as Invoke-Command, or else create a new job id with
start-Job followed by a PowerShell instruction in a scriptBlock.
This strategy relies on appending -asJob
to a cmdlet such as invoke-Command, the results of the scriptBlock are
stored as a job. The PowerShell commands between the scriptBlock
{braces} run in the background
on the remote machine, however, the results are automatically saved locally as a new job
ID. All that you see on-screen is a
record that the job is running, however, you can check the state of all jobs
with Get-Job. Remember that you do not see the actual data until you
run a sister command receive-Job.
Note: In real-life you may want to modify the cmdlet with a 'where-Object' clause,
for example, {Get-Service | where{$_.status -eq "Running"}}
I rarely pay attention to the object nature of PowerShell,
however, when it comes to jobs, it really helps to think of each item as an object,
which we can then recall and manipulate, for example, we can pipe the output
to format-table and select just the
properties we are most interested in.
Thanks to the -computer parameter, asJob runs the command on the remote
machine, even though the job object
itself is stored on the local computer. Incidentally, -asJob
works not only with invoke-Command, but also with Get-WmiObect.
Guy
Recommends: WMI Monitor and It's Free!
Windows Management Instrumentation (WMI) is one of the hidden
treasures of Microsoft operating systems. Fortunately, SolarWinds
have created a
Free WMI Monitor so that you can discover these gems of performance
information, and thus improve your PowerShell scripts. Take the guess work out of which WMI counters to use when scripting the
operating system, Active Directory or Exchange Server.
While there is a PowerShell cmdlet called 'Stop-Job' you don't normally
need to issue this command, PowerShell's intelligence automatically
stops the job when all the instructions have completed. Thus the
only need for Stop-Job is when you have made a mistake in a very long
script, for instance, it's looping.
The only puzzle with Start-Job is how do you access the data? Get-Job
merely lists the
objects, it does not show their contents. To solve that mystery
we employ the 'Receive' verb as you will see in the next example.
Receive-Job is the crucial member of the job family because it enables us to
check the results of running the scriptBlock with start-Job. As a
preliminary I always run Get-Job so that I can make a note of the job name
or unique ID number. All things considered, it's essential that
receive-Job has a name or number so that it can decide which object to read,
and then write the results to your screen.
Get-Job receive-job job19 -keep
The first time I ran receive-Job the command completed successfully but it
removed all the data from the object (HasMoreData - False). This is
why I now append the -keep parameter, so that I can run the command again
and the data is still in the object.
More good news, because each job is an object, you pipe can the results into
format-table, and thus control the output.
* Since your 'job' is different from mine, you need to research the names
of its properties. If you cannot remember then refer back to the
scriptBlock in the original Start-Job instruction.
Guy Recommends: A Free Trial of the Network Performance Monitor
(NPM)
SolarWinds'
Orion performance monitor
will help you discover what's happening on your network. This
utility will also guide you through troubleshooting; the dashboard will
indicate whether the root cause is a broken link, faulty equipment or
resource overload.
Perhaps the NPM's best feature is the way it suggests solutions to network
problems. Its
second best feature is the ability to monitor the health of individual VMware
virtual machines. If you are interested in troubleshooting, and creating network maps, then I recommend that you take advantage of SolarWinds' offer.
One side effect of experimenting is creating lots of failed jobs, thus it's useful to have a
clean-up, and for this task run Remove-Job *. The famous * wildcard
zaps all jobs in the cache. If you preferred you could just remove a
named job. Even better, try the -state switch.
Get-Job remove-Job -state failed Get-Job
Incidentally, note that PowerShell is consistent, it always employs the 'Remove'
verb and never delete, erase, zap, kill or other synonyms for remove.
Summary of PowerShell Jobs and AsJob
The creators of Microsoft PowerShell seem to anticipate every need, and every
problem with running scripts. What members of the
Job family bring is the ability to run scripts in the background.
Furthermore these commands enable you to run scripts on remote
computers and collate them on the local machine. Finally, working with
'Jobs' reinforces the benefits and the nature of object based scripting.
If you like this page then please share it with your friends
Please email me if you have a better example script. Also please report any factual mistakes, grammatical errors or broken links, I will be happy to correct the fault.
Windows Management Instrumentation (WMI) is one of the hidden
treasures of Microsoft operating systems.
Fortunately, SolarWinds
have created the
Free WMI Monitor so that you can actually see and understand these gems of
performance information. Take the guess work out of which
WMI counters to use for applications like Microsoft Active Directory,
SQL or Exchange Server.
