{"id":8351,"date":"2012-08-10T00:01:00","date_gmt":"2012-08-10T00:01:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/2012\/08\/10\/use-background-jobs-to-run-a-powershell-server-uptime-report\/"},"modified":"2012-08-10T00:01:00","modified_gmt":"2012-08-10T00:01:00","slug":"use-background-jobs-to-run-a-powershell-server-uptime-report","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/use-background-jobs-to-run-a-powershell-server-uptime-report\/","title":{"rendered":"Use Background Jobs to Run a PowerShell Server Uptime Report"},"content":{"rendered":"

Summary<\/b>: Microsoft Scripting Guy, Ed Wilson, shows how to use background jobs to run a Windows PowerShell script that produces a server uptime report.<\/p>\n

\"Hey, Hey, Scripting Guy! I like your script to get uptime and to get free disk space, but I cannot be responsible for running it on a regular basis. In addition, keep in mind we have a very large network, and the script will take a long time to run. Is there a command to make this run in the background?<\/p>\n

—RE<\/p>\n

\"Hey, Hello RE,<\/p>\n

Microsoft Scripting Guy, Ed Wilson, is here. PowerShell Saturday in Charlotte, North Carolina<\/a> is a little more than a month away (September 15, 2012), and we have all the sponsors and all the speakers lined up, the agendas posted, and nearly half of the tickets are already sold. If you want to attend, you need to get your reservations placed before the tickets are all gone. There will be 200 people attending, and it will be a tremendous day of learning delivered by some “rock star” trainers!  There are three different tracks (Beginner, Advanced, and Applied), so there will be something for anyone who uses or anticipates using Windows PowerShell.<\/p>\n

Use Start-Job to run the report<\/h2>\n

Note<\/b>   This is the fourth blog in a series about using the Convertto-HTML<\/b> cmdlet and creating a HTML server uptime report. The first blog talked about creating an HTML uptime report<\/a>, the second one used Windows PowerShell to create a report that displays disk space in addition to uptime<\/a>, the third discusses adding color and stuff to the uptime report<\/a>. You should read the three previous blogs prior to reading today’s.<\/p>\n

If you have a large network, it can take a very long time to reach out and touch every server on the network and to bring back the information to a central location. One thing that can help is to run the script as a background job. Using jobs, Windows PowerShell will run the script in the background. You then have the option of using the Wait-Job<\/b> cmdlet to pause the Windows PowerShell console until the script completes, or you can allow the job to complete. At any rate, it is not really necessary to use the Receive-Job<\/b> cmdlet to receive the job because the HTML page creates it as part of the script, and not as part of the job itself. The command shown here creates a job and runs the script.<\/p>\n

Start-Job -FilePath C:\\fso\\HTML_Uptime_FreespaceReport.ps1<\/p>\n

To receive the job, use the following commands.<\/p>\n

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

When you have done this, you may want to remove the job. This command accomplishes that task.<\/p>\n

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

Use Invoke-Command to multithread the job<\/h2>\n

Using Start-Job<\/b> on the local computer does not really do much in the way of speeding up things—it simply hides how long the script takes by placing it in the background. If you have a large network, use the Invoke-Command<\/b> to run the commands against remote machines. Windows PowerShell automatically determines the best number of concurrent connections (by default 32). To use the Invoke-Command<\/b> cmdlet effectively requires a few changes to the HTML_UptimeReport.ps1 script. The changes involve removing the hard-coded list of servers in the param<\/b> <\/i>portion of the script. This first change is shown here.<\/p>\n

Param([string]$path = “c:\\fso\\uptime.html”)<\/p>\n

The next change involves removing the servers<\/b> <\/i>parameter from the call to the Get-UpTime<\/b> function as shown here.<\/p>\n

Get-UpTime |<\/p>\n

The next change I make changes the servers<\/b> <\/i>parameter on the Get-UpTime<\/b> function. This change is shown here.<\/p>\n

Function Get-UpTime<\/p>\n

{ Param ([string]$servers = $env:COMPUTERNAME)<\/p>\n

The last change removes the Invoke-Item<\/b> command that displayed the completed HTML report. This will not work remotely anyway, and it is therefore unnecessary.<\/p>\n

I leave the foreach<\/b> <\/i>command because I do not want to make more changes to the function than required. The revised HTML_UptimeReport.ps1 is shown here as Invoke_HTML_UptimeReport.ps1.<\/p>\n

Invoke_HTML_UptimeReport.ps1<\/b><\/p>\n

Param([string]$path = “c:\\fso\\uptime.html”)<\/p>\n

 <\/p>\n

Function Get-UpTime<\/p>\n

{ Param ([string]$servers = $env:COMPUTERNAME)<\/p>\n

  Foreach ($s in $servers)<\/p>\n

   {<\/p>\n

     $os = Get-WmiObject -class win32_OperatingSystem -cn $s<\/p>\n

     New-Object psobject -Property @{computer=$s;<\/p>\n

       uptime = (get-date) – $os.converttodatetime($os.lastbootuptime)}}}<\/p>\n

 <\/p>\n

# Entry Point ***<\/p>\n

 <\/p>\n

Get-UpTime |<\/p>\n

ConvertTo-Html -As Table -body “<\/p>\n

  <h1>Server Uptime Report<\/h1><\/p>\n

  The following report was run on $(get-date)” >> $path <\/p>\n

I now open my Windows PowerShell console, and I retrieve and store a credential object to be used when making the remote connections. Next, I provide an array of server names. Finally, I call the Invoke-Command<\/b> cmdlet and specify the computer names and the credentials. I use the FilePath<\/b> <\/i>parameter to point to a script that exists on my local computer. Next I use the AsJob<\/b> <\/i>parameter to run the command as a job. Finally, I specify a friendly name for the job. This command permits up to 32 simultaneous remote connections to obtain the information. The commands I type are shown here.<\/p>\n

$credential = Get-Credential -Credential iammred\\administrator<\/p>\n

$servers = @(“dc1″,”dc3″,”ex1″,”sql1”)<\/p>\n

Invoke-Command -ComputerName $servers -Credential $credential -FilePath C:\\fso\\Invoke_HTML_UptimeReport.ps1 -AsJob -JobName uptime<\/p>\n

There is one problem with this command. The c:\\fso\\uptime.html command refers to a folder (c:\\fso), which must exist on the remote server. Actually, several of my remote servers have a c:\\fso folder, but the ones that do not will generate an error when I receive the job. The commands and associated output are shown in the following image.<\/p>\n

\"Image<\/a><\/p>\n

To override the default value that is contained in the script, I supply a value for the args<\/b> <\/i>parameter of the Invoke-Command<\/b> cmdlet. The values for the args<\/b> <\/i>parameter must appear in the same order that the script declares the parameters.<\/p>\n

If I run the command and do not make provisions for multiple file access, file locking issues arise. There are two easy ways to deal with this issue. The first is to dial down the ThrottleLimit<\/b> <\/i>value to 1. Doing this, however, does no more than allow for a single connection at a time. This is the same thing the original script accomplished; and therefore, it is not a great solution. A better approach is to modify the output file name, to include the server name. Doing this permits simultaneous file access. Here is a modification to the code.<\/p>\n

>> (“{0}{1}_Uptime.html” -f $path, $env:COMPUTERNAME) <\/p>\n

When I use Invoke-Command<\/b> now, I do not include the file name, but only the \\\\dc1\\share<\/b> path. This command is shown here.<\/p>\n

Invoke-Command -ComputerName $servers -Credential $credential -FilePath C:\\fso\\Invoke_HTML_UptimeReport.ps1 -AsJob -JobName uptime -args “\\\\dc1\\share\\”<\/p>\n

RE, that is all there is to using jobs to run a Windows PowerShell script and produce an uptime report. Join me tomorrow for more Windows PowerShell cool stuff.<\/p>\n

I 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.<\/p>\n

Ed Wilson, Microsoft Scripting Guy<\/b> <\/p>\n","protected":false},"excerpt":{"rendered":"

Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use background jobs to run a Windows PowerShell script that produces a server uptime report.  Hey, Scripting Guy! I like your script to get uptime and to get free disk space, but I cannot be responsible for running it on a regular basis. In addition, keep […]<\/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,3,4,45],"class_list":["post-8351","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scripting","tag-background-jobs","tag-scripting-guy","tag-scripting-techniques","tag-windows-powershell"],"acf":[],"blog_post_summary":"

Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use background jobs to run a Windows PowerShell script that produces a server uptime report.  Hey, Scripting Guy! I like your script to get uptime and to get free disk space, but I cannot be responsible for running it on a regular basis. In addition, keep […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/8351","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=8351"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/posts\/8351\/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=8351"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/categories?post=8351"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/scripting\/wp-json\/wp\/v2\/tags?post=8351"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}