Chapter 14: Multitasking with background jobs

Introduction

Introduces PowerShell’s ability to do more than one thing at a time, especially for long-running work involving multiple computers.

• PowerShell multitasking use cases: Explain that PowerShell can do more than one thing at a time and why that is useful for longer-running tasks involving multiple target computers.
  Why it matters: This gives you a reason to use PowerShell multitasking when a task would otherwise keep you waiting.

Key terms: multitask, longer-running tasks, multiple target computers

14.1 Making PowerShell do multiple things at the same time

This section explains why ordinary PowerShell commands block the shell and how background jobs let work continue while the shell remains available.

• Foreground command sequence: Explain why a second command cannot be run in the shell while an ordinary command is still executing.
  Why it matters: This is the limitation that background jobs address.
• Background job execution choice: Describe how a background job lets a command run while the shell remains available, and when that choice must be made.
  Why it matters: Starting a command as a job lets you keep using the shell instead of waiting for it to finish.

Key terms: single-threaded, background jobs, background thread, background PowerShell process

14.2 Synchronous vs. asynchronous

This section contrasts foreground commands with background jobs, explains the practical limits of running commands asynchronously, and recommends testing commands before backgrounding them.

• Synchronous and asynchronous execution: Distinguish a normal synchronous command from a background job in terms of whether the shell is available while the command runs.
  Why it matters: This distinction explains why a background job lets you keep working in the shell.
• Background job interaction and results: Explain how background execution changes input prompts, error visibility, and access to results.
  Why it matters: A job needs to run without interactive help, and you must retrieve its results rather than expect immediate output.
• Testing before background execution: Justify running a command synchronously to test it before running it as a background job.
  Why it matters: Testing first helps catch problems that would be harder to notice or resolve in a background job.
• Scope of native jobs: State why the chapter’s description of jobs may not apply to every PowerShell job.
  Why it matters: It prevents you from assuming every feature called a job behaves exactly like the jobs described here.

Key terms: synchronously, asynchronously, background, jobs, input requests, required parameter, errors, cached results, debugged, extension point

14.3 Creating a process job

This section explains how to start a local process job, identify it, and avoid file-path problems when it runs in the background.

• Process job creation: Explain that a process job runs in another PowerShell process on the local machine and describe how Start-Job launches commands or a script file in the background.
  Why it matters: It lets you start work in the background while keeping your PowerShell session available.
• Job identity and start: Describe what Start-Job creates and how a process job gets its name and ID.
  Why it matters: The job object, name, and ID help you recognize the work you started.
• Job working directory: Explain where a process job starts on the filesystem and how to make file references reliable.
  Why it matters: A job may otherwise look for a file in a different directory than you expected.
• Child jobs and remoting: Explain why process job names or IDs can appear to skip numbers, and state the prerequisite for running local process jobs.
  Why it matters: These details explain a surprising ID sequence and a requirement that may affect whether a local job runs.

Key terms: process job, Start-Job, -ScriptBlock, -FilePath, job object, job name, job ID, -Name, -WorkingDirectory, home directory

14.4 Creating a thread job

This section explains how thread jobs run within the current PowerShell process, when they are useful compared with process jobs, and how their concurrency is limited.

• Thread job execution and use: Explain that a thread job runs on another thread in the current PowerShell process, rather than in a separate process. Describe why its faster startup makes it useful for short background commands, while process jobs can suit long-running scripts.
  Why it matters: The difference helps you choose a job type that fits the work.
• Thread job concurrency limit: Explain that PowerShell limits concurrent thread jobs to 10 by default to avoid slowing the process, and that -ThrottleLimit can change that limit. Describe why raising it substantially can produce diminishing returns.
  Why it matters: Starting more jobs at once does not necessarily make the work finish faster.

Key terms: thread job, process job, thread, process, throttle limit, -ThrottleLimit, thread jobs, diminishing returns

14.5 Remoting, as a job

This section explains how to run a PowerShell remoting command as a background job across multiple computers.

• Parallel remote job execution: Explain how a remoting job sends a command to multiple computers, how the throttle limit affects when they start, and when the top-level job completes.
  Why it matters: This lets you predict when work starts across many targets and when the overall job is done.
• Remote workload and results: Describe what the target computers need, where the command runs, and where its results remain until reviewed.
  Why it matters: The setup requirements and execution location determine whether a remote job can run and why it may help with long-running work.
• Custom job naming: State what the -JobName parameter changes.
  Why it matters: A chosen name can make the job easier to recognize.

Key terms: -scriptblock, -command, -throttleLimit, top-level job, PowerShell v6, remoting over SSH, computing workload, results, -JobName

14.6 Jobs in the wild

Shows how a module command can expose a PowerShell job through an -AsJob parameter.

• Module Jobs Through AsJob: Explain that New-AzVM’s -AsJob parameter makes the command return a Job, and that this job can be managed like one returned by Start-Job or Start-ThreadJob.
  Why it matters: Spotting -AsJob helps you recognize jobs exposed by commands outside the job cmdlets.

Key terms: -AsJob, New-AzVM, Job, Start-Job, Start-ThreadJob

14.7 Getting job results

This section shows how to check a job’s status, retrieve its results, and decide whether to retain or process them.

• Job Status and Available Results: Describe how Get-Job shows defined jobs and their status, how to inspect a particular job, and what HasMoreData indicates.
  Why it matters: Checking a job tells you whether it has finished and whether its output is still available.
• Receiving Parent and Child Results: Explain how to select a job for Receive-Job and distinguish the results received from a parent job from those received from child jobs.
  Why it matters: Choosing the right job determines whether you receive all its output or only selected child-job output.
• Job Result Cache Retention: Explain what normally happens to cached output after Receive-Job and how to keep a copy for later use.
  Why it matters: Without retaining or saving results, receiving them once may leave nothing to retrieve again.
• Processing Received Job Objects: Describe how received job results can be piped to other cmdlets, including the limitation of deserialized results and the source information on remote-job output.
  Why it matters: You can sort, format, or export job output while still recognizing which remote computer produced it.

Key terms: Get-Job, HasMoreData, job ID, job name, Receive-Job, parent job, child jobs, job output cache, -keep, CLIXML

14.8 Working with child jobs

This section shows how to find a parent job’s child jobs and receive results from an individual child job.

• Finding a job’s children: Explain that a job can have a top-level parent and child jobs, and describe why listing the children in a table can help when there are many of them.
  Why it matters: Finding the child jobs lets you choose which one to inspect.
• Receiving individual child results: Describe how to receive results from a particular child job using Receive-Job and that child job’s name or ID.
  Why it matters: You can request the results of the specific child job you care about.

Key terms: parent job, child job, Receive-Job, name, ID

14.9 Commands for managing jobs

This section explains how to remove, stop, or wait for PowerShell jobs and how to inspect failed jobs and their child jobs.

• Job management commands: Distinguish Remove-Job, Stop-Job, and Wait-Job by what each does, and describe how to specify the job they act on.
  Why it matters: Choosing the right command lets you clean up a job, end a stuck one, or make a script wait for its work to finish.
• Failed job diagnostics: Explain how a failed job’s status, child jobs, and Receive-Job results help identify what went wrong.
  Why it matters: Checking the errors and individual child jobs helps you diagnose a failure rather than treating the whole job as one unexplained result.

Key terms: Remove-Job, Stop-Job, Wait-Job, job ID, job name, failed job, child jobs, Receive-Job, job status

14.10 Common points of confusion

This section warns against confusing ways of starting background jobs and explains who can see jobs and how long they last.

• Choosing a Job Starting Method: Explain why mixing job-starting methods can make results inaccessible or add unnecessary steps, and describe the recommended use of Invoke-Command -AsJob for background remoting.
  Why it matters: Choosing one appropriate job method helps you avoid losing access to results or adding redundant commands.
• Visibility of Other Users Jobs: Explain why one PowerShell user cannot see another user's jobs or thread jobs.
  Why it matters: Process boundaries explain why another user's jobs do not appear among yours.
• PowerShell Session Job Lifetime: Explain what happens to jobs when the PowerShell session that contains them closes.
  Why it matters: Knowing a job's lifetime helps you avoid assuming it will remain available after you close PowerShell.

Key terms: local job, Invoke-Command, -AsJob, jobs, thread jobs, PowerShell process, PowerShell session

14.11 Lab

14.12 Lab answers