{"id":1862,"date":"2014-03-07T00:01:00","date_gmt":"2014-03-07T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2014\/03\/07\/powershell-jobs-week-job-processes\/"},"modified":"2014-03-07T00:01:00","modified_gmt":"2014-03-07T00:01:00","slug":"powershell-jobs-week-job-processes","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/powershell-jobs-week-job-processes\/","title":{"rendered":"PowerShell Jobs Week: Job Processes"},"content":{"rendered":"

Summary<\/b>: Richard Siddaway looks at how Windows PowerShell jobs actually run.\nHonorary Scripting Guy, Richard Siddaway, here today filling in for my good friend, The Scripting Guy. This is the sixth in a series of posts that, hopefully, will shine the spotlight on Windows PowerShell jobs, remind people of their capabilities, and encourage their greater adoption. The full series comprises:<\/p>\n

    \n
  1. Introduction to PowerShell Jobs<\/a><\/li>\n
  2. WMI and CIM Jobs<\/a><\/li>\n
  3. Remote Jobs<\/a><\/li>\n
  4. Scheduled Jobs<\/a><\/li>\n
  5. Jobs and Workflows<\/a><\/li>\n
  6. Job Processes (this post)<\/li>\n
  7. Jobs in the Enterprise<\/li>\n<\/ol>\n

    The focus on this series has been on Windows PowerShell jobs, including learning about the core job cmdlets, using the
    –AsJob<\/b> parameter, running jobs on remote machines, and figuring out how scheduled jobs work. Today, we are going to go under the hood a bit more and look at how jobs actually run.\nI’ve stated in passing several times in this series that jobs don’t run in the context of your current Windows PowerShell session—whether that’s the Windows PowerShell console, ISE, or another Windows PowerShell host. Try this:<\/p>\n

    $proc = “p*”<\/p>\n

    Get-Process -Name $proc\nThe commands will run and you will see list of processes with names that start with the letter “p.” In my environment, I got a single instance of the Windows PowerShell process. Now try this:<\/p>\n

    Start-Job -ScriptBlock {Get-Process -Name $proc}\nYour job will start and apparently complete. However, when you look at the data from the job, you’ll get something like this:<\/p>\n

    £> Receive-Job -Id 4\nCannot validate argument on parameter ‘Name’. The argument is null or empty. Provide an argument that is not null or empty, and then try the command again.<\/p>\n

        + CategoryInfo          : InvalidData: (:) [Get-Process], ParameterBindingValidationException<\/p>\n

        + FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.GetProcessCommand<\/p>\n

        + PSComputerName        : localhost\nThe error message is telling you in a very roundabout way that the job didn’t know anything about the $proc<\/b> variable. If you want your job to be able to use the contents of the $pr<\/b>oc variable, you need to pass it into the job:<\/p>\n

    Start-Job -ScriptBlock {param ([string]$proc ) Get-Process -Name $proc} -ArgumentList $proc\nA param<\/b> block has been added to the script block defining the proc<\/b> parameter. The –ArgumentList<\/b> parameter of Start-Job<\/b> is used to pass the parameter. If you need to pass multiple parameters into the script block, list them in the order they are defined. You don’t have to use the same name for the variable that is associated with the script block’s parameter inside and outside the script block. I’ve just done it to reduce confusion.\nThe job will run, and when you use Receive-Job<\/b>, you will receive the expected results. Or are they what you expected?\nWhen I ran Get-Process<\/b> at the beginning of this explanation, I deliberately chose “p*”<\/b> so that I got the Windows PowerShell process (I’m running all of this in a Windows PowerShell console). I got one Windows PowerShell process. When I ran the second job (the one that worked), I got two Windows PowerShell processes. But if I run Get-Process<\/b> now, I’ll only see my original Windows PowerShell process.\nThe extra Windows PowerShell process appeared because a standard background job spawns a new, separate Windows PowerShell process in which it runs the script block. That’s why the variable we defined couldn’t be found when we ran the first job. The work is being done in a separate instance of PowerShell that is brand new and clean.<\/p>\n

    Note<\/b>  Your profile won’t be run in the Windows PowerShell instance that the job starts, so you won’t have any aliases or functions that you define in your profile. You won’t have any snap-ins or modules that your profile loads available either. You’ll have to load them within your job’s script block.\nYou’ve now discovered why you get the Windows PowerShell prompt back as soon as your job starts—the work is being done in separate process so the Windows PowerShell job engine can give back the prompt.\nDoes that mean that we know how all jobs run? Unfortunately, not! Each job type has its own behavior pattern as far the process, or processes, it requires.\nThe easiest way to dig into this is to open three Windows PowerShell consoles.  In the first one, run Get-Process<\/b> and keep the results visible. In the second, run:<\/p>\n

    Get-WmiObject -Class Cim_datafile –AsJob\nThat will create a very long running WMI job.\nIn your third Windows PowerShell console, run Get-Process<\/b> again. Compare the results, and you will discover a process called unsecapp<\/b> is now running:<\/p>\n

    Get-Process unsecapp | fl *\nIt shows the following details. (I’m picking out only the interesting bits):<\/p>\n

    Path                       : C:windowssystem32wbemunsecapp.exe<\/p>\n

    Company                    : Microsoft Corporation<\/p>\n

    Description                : Sink to receive asynchronous callbacks for WMI client application\nThe wbem folder is where Windows keeps all of the WMI related tools.\nStop and remove the job with:<\/p>\n

    Get-Job | Stop-Job<\/p>\n

    Get-Job | Remove-Job\nIf you wait a little while and then run…<\/p>\n

    Get-Process u*\n…You’ll see that unsecapp.exe has closed.\nIf you repeat the exercise, but use Get-CimInstance -ClassName CIM_datafile –AsJob<\/b>, you can discover where CIM jobs run.\nOh. You can’t because the CIM cmdlets don’t have an –AsJob <\/b>parameter. If you want to run the CIM cmdlets as a job, you have to use Start-Job<\/b>. If you try that experiment, you’ll see that another instance of Windows PowerShell is started for the background job as you would expect.\nCommands that are created by using CDXML get an –AsJob<\/b> parameter added automatically. Create a simple CDXML module by using the CIM_Datafile<\/b> class:<\/p>\n

    <?xml version=’1.0′ encoding=’utf-8′?><\/p>\n

    <PowerShellMetadata xmlns=’http:\/\/schemas.microsoft.com\/cmdlets-over-objects\/2009\/11′><\/p>\n

      <Class ClassName=’ROOTcimv2Cim_DataFile’><\/p>\n

        <Version>1.0<\/Version><\/p>\n

        <DefaultNoun>CimDataFile<\/DefaultNoun><\/p>\n

        <InstanceCmdlets><\/p>\n

          <GetCmdletParameters DefaultCmdletParameterSet=’DefaultSet’>             <\/p>\n

          <\/GetCmdletParameters><\/p>\n

        <\/InstanceCmdlets> <\/p>\n

      <\/Class> <\/p>\n

    <\/PowerShellMetadata>\nNow save it as datafile.cdxml.\nImport the module and run the command:<\/p>\n

    Import-Module .datafile.cdxml<\/p>\n

    Get-CimDataFile –AsJob\nYou will see a job of type CimJob<\/b> running. Testing the process as you did previously doesn’t highlight any obvious new processes. So we have to assume that CIM jobs run in an existing process.\nYou will have a similar experience if you try to track down where workflow jobs run. There is no obvious new process started.\nYou’ve seen other job types: RemoteJobs<\/b> and ScheduledJobs<\/b>.\nIf we try our experiment on these, you can simulate a remote job like this:<\/p>\n

    Invoke-Command -ComputerName $env:COMPUTERNAME -ScriptBlock {while($true){sleep -Seconds 10}} –AsJob\nLooking at the running processes, you will discover the wsmprovhost<\/b> process:<\/p>\n

    Get-Process wsmprovhost | fl *\nIt shows these details:<\/p>\n

    Path                       : C:windowssystem32wsmprovhost.exe<\/p>\n

    Company                    : Microsoft Corporation<\/p>\n

    Description                : Host process for WinRM plug-ins\nThat seems sensible because we’re dealing with remoting.\nScheduled jobs are interesting.  If you look at the definition of the scheduled task associated with the scheduled job, you’ll see:<\/p>\n

    powershell.exe -NoLogo -NonInteractive -WindowStyle Hidden -Command “Import-Module PSScheduledJob; $jobDef = [Microsoft.PowerShell.ScheduledJob.ScheduledJobDefinition]::LoadFromStore(‘MyLongJob’, ‘C:UsersRichardAppDataLocalMicrosoftWindowsPowerShellScheduledJobs’); $jobDef.Run()”\nThat means you’re starting Windows PowerShell and then starting a job from that Windows PowerShell process, which starts another Windows PowerShell process—for a total of two new Windows PowerShell processes.\nYou now know that a Windows PowerShell job creates at least one new process in which to run. Each job will create a new process. If you start 30 long-running standard background jobs, you’ll get 30 new instances of Windows PowerShell. This could have a serious impact on your admin machine, depending on its specification.\nYou need to think about how many jobs you start at once. Cmdlets such as Invoke-Command<\/b> and Get-WmiObject<\/b>, which have an –AsJob<\/b> parameter, also have a –ThrottleLimit<\/b> parameter. This accepts an integer value and controls the number of jobs that can be run simultaneously from that command. \nNow run:<\/p>\n

    Invoke-Command –ComputerName (get-content computers.txt) –ScriptBlock {get-process} –AsJob\nThe computers.txt file contains the names of 200 computers, and you don’t want the command starting 200 jobs simultaneously. The –ThrottleLimit<\/b> parameter defaults to 32, so you’ll only get 32 jobs started, and one has to finish before the next one starts.\nBut that’s not 32 running jobs in total on the machine. Its 32 running jobs from that one command. If you have jobs started in other Windows PowerShell sessions, or you started long-running jobs before you used Invoke-Command<\/b>, you could have many more jobs running—all taking resources.\nYou can use the –ThrottleLimit<\/b> parameter to control the number of jobs that start at one time, but don’t make the number too high because your machine will run out of resources and crash.\nThat’s it for today. Tomorrow the series concludes with a look at how and when you can use jobs in your enterprise to the best advantage. Bye for now.\n~Richard\nThanks, Richard.\nI invite you to follow me on Twitter<\/a> and Facebook<\/a>. If you have any questions, send email to me at scripter@microsoft.com<\/a>, or post your questions on the Official Scripting Guys Forum<\/a>. See you tomorrow. Until then, peace.\nEd Wilson, Microsoft Scripting Guy<\/b> <\/p>\n","protected":false},"excerpt":{"rendered":"

    Summary: Richard Siddaway looks at how Windows PowerShell jobs actually run. Honorary Scripting Guy, Richard Siddaway, here today filling in for my good friend, The Scripting Guy. This is the sixth in a series of posts that, hopefully, will shine the spotlight on Windows PowerShell jobs, remind people of their capabilities, and encourage their greater […]<\/p>\n","protected":false},"author":596,"featured_media":87096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[193,189,4,45],"class_list":["post-1862","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-background-jobs","tag-richard-siddaway","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":"

    Summary: Richard Siddaway looks at how Windows PowerShell jobs actually run. Honorary Scripting Guy, Richard Siddaway, here today filling in for my good friend, The Scripting Guy. This is the sixth in a series of posts that, hopefully, will shine the spotlight on Windows PowerShell jobs, remind people of their capabilities, and encourage their greater […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/1862","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/users\/596"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/comments?post=1862"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/1862\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media\/87096"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/media?parent=1862"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=1862"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=1862"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}