With the US Government attempting to stimulate the economy, and the productivity of this blog down by 66%, I thought I would do my part by creating jobs. Ed and Hal were off causing trouble last week at SANS 2010, so I'm by myself for this episode. Hal and Ed have already done a similar episode a while ago, so I thought I would do the PowerShell version.
To create a job in PowerShell we use the cmdlet Start-Job.
PS C:\> Start-Job -ScriptBlock { Get-EventLog -Log System }
Id Name State HasMoreData Location Command
-- ---- ----- ----------- -------- -------
1 Job1 Running True localhost Get-EventLog...The script block is where we specify the command to be run. Pretty easy, right?
One of the things I haven't explicitly mentioned before is positional parameters. These parameters do not require that the parameter name be used and are defined by their position in the command. As an example, this command does the same thing as the one above, but without the parameter name being used.
PS C:\> Start-Job { Get-EventLog System }We've touched on the ScriptBlock parameter, now let's check out some of the others we have available to us with this command:
PS C:\> Start-Job -FilePath C:\TestScript1.ps1
-Name Mine
-ArgumentList "jdoe"
-InitializationScript { Add-PSSnapin Quest.ActiveRoles.ADManagement }
-Credential mydomain\tim
The Name parameter is used to specify the name of the job so we can reference it. The FilePath parameter is used to specify a script to be run. The ArgumentList parameter specifies the arguments (parameter values) for the script that is specified by the FilePath parameter. InitializationScript specifies commands that run before the job starts and is useful for loading Snap-ins or modules that are required by our script or command. Finally, the Credential parameter is used to run the command as a different user. In this case the user will be prompted for the password. There are other ways to pass credentials or to authenticate, but we'll leave that for an episode of its own. Back to jobs...
Some commands have a parameter (AsJob) that allow the command to be run as a job. This is handy for commands that take a long time. One such cmdlet is Get-WmiObject.
PS C:\> Get-WmiObject -query "Select * from
CIM_DataFile Where Extension = 'pst'"
-ComputerName (Get-Content C:\computers.txt)
-asJob -ThrottleLimit 10
This command will query a list of computers specified in the computers.txt file for pst files on each computer. The ThrottleLimit command specifies that we should only run 10 simultaneous queries at the same time. Obviously, this command will take a long time to run, so we run it as a job.
Now that we have created so many jobs, what do we do with them? We can get a list of the jobs by using the aptly named Get-Job cmdlet.
PS C:\> Get-Job
Id Name State HasMoreData Location Command
-- ---- ----- ----------- -------- -------
1 Job1 Completed True localhost Get-EventLog -Log Sys...
3 Mine Completed True localhost Get-Process
5 Job5 Running True localhost Get-WmiObject -query ...
Notice that the jobs are not numbered sequentially. That is because the main job does not perform any of the work. Each job has at least one child job because the child job actually performs the work. It is a little odd, but it really doesn't have much impact.
The fifth job will take a while, say we want to wait for that job to finish.
PS C:\> Wait-Job 5; Write-Host "`aAll Done"
This command will wait until Job #5 has completed, beep, and then echo "All Done" to the console. The "back-tick a" makes the beep. All of these commands can reference a specific job by number (5) or by name (Job5).
Getting tired of waiting for that job to finish?
PS C:\> Stop-Job 5
Really want that job done? Delete it.
PS C:\> Remove-Job 5
We have stopped the fifth job and deleted it. Now, let's find out what happened with the first job.
PS C:\> Get-Job 1 | fl
HasMoreData : True
StatusMessage :
Location : localhost
Command : Get-EventLog -Log System
JobStateInfo : Completed
Finished : System.Threading.ManualResetEvent
InstanceId : 69e9bd34-87c8-4492-a6af-af6f2fa4a77f
Id : 1
Name : Job1
ChildJobs : {Job2}
Output : {}
Error : {}
Progress : {}
Verbose : {}
Debug : {}
Warning : {}
State : Completed
As you can see the job has completed. If our command had bombed then the State would have been "Failed". As you can see above, the HasMoreData property is true so we know there is output that we can look at. How do we do that?
PS C:\> Receive-Job 1
[Get-EventLog Ouptut follows]
The Receive-Job cmdlet retrieves the results from the job. One thing to note after using the Receive-Job cmdlet, the job is deleted unless the Keep parameter is used. This is handy so you don't have to do the cleanup after you get the results since most of the time you only deal with the results one time.
The results of Receive-Job are exactly the same as running the orginal command out side of a job. To better illustrate this, these two commands would have the same output:
PS C:\> Receive-Job 1 | ? { $_.EntryType -eq "Error" }
PS C:\> Get-EventLog -Log System | ? { $_.EntryType -eq "Error" }Hopefully I will have stimulated the economy (and Hal and Ed) enough to get some help next week.